 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Component Services / October 2004COM+ acessing databases
Hi. We are considering two diferent architectures for an application. The first one does not use .NET serviced components. It uses a simple NET component for centralized data access. This component resides on the bin folder of the asp.net application and reads some parameters defined on the web.config file. The asp.net application calls this component and access the database server directly. The second one uses a .NET serviced component for centralized data access, installed on a different server. The asp.net application calls this component every time it needs to deal with the database, so that the application does not reaches the database server directly. A consultant is recommending this architecture based on security issues. I would like to know if this is really a good design, since it is considering only security factors. I am not experienced with COM+ and fear that this design can impact performance. Is it a common design for asp.net applications? Regards, Chris Leffer > Hi. > [quoted text clipped - 5 lines] > defined on the web.config file. The asp.net application calls this > component and access the database server directly. This is a common design methodology. It could be speeded-up a little by installing the component in the GAC. > The second one uses a .NET serviced component for centralized data > access, installed on a different server. The asp.net application calls > this component every time it needs to deal with the database, so that > the application does not reaches the database server directly. A > consultant is recommending this architecture based on security issues. You pay a price for crossing the boundary between managed and unmanged code when you use COM+. The question becomes: do you need any functionality of COM+, and is the benefit worth more than the cost? 1) the idea of separating database access to another computer is obviously attractive from a security viewpoint 2) the role-based security options of COM+ might be beneficial in some cases, but I don't see much benefit here for a web application > I would like to know if this is really a good design, since it is > considering only security factors. I am not experienced with COM+ and > fear that this design can impact performance. You are wise to ask this question. The performance ramifications of using COM+ accross machine boundaries are clearly evident. You pay twice here: you have the managed-to-unmanged cost, and then you have the remoting cost. My personal view is to mitigate the cost by doing the remoting with managed code - consider using a MBR remotable object hosted in IIS. By you'd need to do some benchmark comparisons to be sure which is the better solution. Eric Hi Eric. Thanks for your answer. I have another question, if you don't mind. I have read some articles and posts about the port 135. It appears that COM+ always uses this port and that this can be a potential security problem. Suppose I adopt the second architecture, using COM+. As my app is a web app, should I really be carefull about this port? What are exactly the risks I must to consider? Regards, Chris Leffer > I have another question, if you don't mind. I have read some articles > and posts about the port 135. I might not be the best person to ask about this. It's my understanding that accessing COM+ objects on remote computers will use the DCOM mechanism. I sure hope this is not true, because DCOM uses a wide range of ports - not just a single port. I know you can do a registry hack to restrict the port range somewhat, but they still recommend that you open around 1000 ports for DCOM (to be fair, DCOM was architected before the days of security-awareness). I hope I'm wrong. Does anyone know if this is right? Can you restrict a remote COM+ component to use just one port? I only recommend using DCOM within a security zone, like your web DMZ. You could have your DB objects on another server in the same zone, but that's not going to help you much. I think your ojective is to avoid any DB access from within the mostly-untrusted web zone. .NET remoting and Web Services can both use only a single port, and this is a less risky way of doing business. The DB servers can be in a trusted zone, and you only open 1 port to the web zone. The new SOA (Service Oriented Architecture) that is popular lately is based on this model - they keep sensitive components isolated to a separate zone, and use a tightly controlled set of ports to move data between zones. Eric The range of ports that DCOM uses can be controlled precisely, actually.using configuration settings of COM+. See KB 300083 for details (http://support.microsoft.com/default.aspx?scid=kb;en-us;300083). You can allow as many port ranges open as you want. If you expect to have a lot of objects active at the same time and/or you expect your clients to maintain long-lived sessions with your objects (eg they addref them then don't release them for a long time and you weren't using JIT), you would allow for more ports to be open at once. If clients weren't expected to hold on to objects for long, then you would need fewer ports. You can expect that in many scenarios, DCOM will provide a higher throughput and a higher level of security than .Net Remoting. Messages on the wire can be signed and encrypted using DCOM, for example. I don't believe that .Net remoting supports this. COM+ and DCOM also provide built in access control and administration of apps and components via scripting or UI. If you're web app accesses databases directly, then you will need to open ports on firewalls for communication with the database unless the database is on the same machine as the web app. Another thing to consider is your transaction requirements. If you are doing all your work in the same database and I assume that this work needs to be atomic, then you don't need the Transaction features of ServicedComponents and COM+. If you need to do atomic work accross multiple databases or resource managers, then you may want to enlist all resource managers in a distributed transaction so they can all participate in the transaction. If you don't already know, doing atomic work means that either all work done succeeds or no work is done at all. An example. If my web app is an order processing app and processing an order means I need to write to the Orders table on a database on machine A, write to a billing table on a database on machine b, and post an MSMQ work order message to a queue on machine C and all these operations either need to complete successfully or none of them should occur, I could accomplish this type of atomic operation guarantee using a single, distributed transaction between the three machines. COM+ gives me this functionality. Really, the technology you use depends on the type of work you expect your app to do. You should consider your security requirements, your manageability requirements and robustness and performance requirements when making technology decisions. >> I have another question, if you don't mind. I have read some articles >> and posts about the port 135. [quoted text clipped - 23 lines] > > Eric Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.