 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Component Services / January 2004Confused about library applications
Hi. I am reading about .net serviced components right now, but have a doubt about library applications. The documentation says that library applications run in the client`s process. So, if my user has a windows application installed on his machine and that application calls a serviced component configured as a library application on a server, will my serviced component runs on the client machine? Who is the client in this situation? TIA, Erik Cruz Erik, A Library Application is only callable on the same machine, you can't call Library Apps cross-machine. You can only do that with Server Applications (either through an exported Application Proxy, or now with .Net Remoting (with the Server App as an endpoint), etc.). Library Applications run in the same process as the caller, and because of that are very fast -- almost as fast as non-configured components (not derived from ServicedComponent and not installed into the COM+ Catalog). The other downside to Library Apps, because they run in-process, they also run with the same security context as the caller -- there is no way to establish a separate identity to run the Library App. So, in your situation, if you have a windows app running on one box, the only way to run the Library App is to install it on the same box, or install an Application Proxy to a Server App which in turn calls the Library App, or use something like .Net Remoting to make a remote call to the Server App which in turn calls the Library App. Hope that clears it up. Robert Hurlbut > Hi. > [quoted text clipped - 7 lines] > TIA, > Erik Cruz Hi Robert. > Hope that clears it up. yes, you explanation helped me a lot, thanks. Erik Cruz you can expose to remote calls a class residing in a library app through .net remoting (this is actually my favourite approach), you don't need to host the class in a server app .. calling a class hosted in a server app through .net remoting is quite nonsense actually (unless you have cpu clock cycles to waste or other reasons to host in a server app). IMO > Erik, > [quoted text clipped - 33 lines] > > TIA, > > Erik Cruz Enrico, My mistake, that you can't reference Library apps directly through .Net Remoting, but as Tim Ewald points out in his excellent article (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/h tml/entserv.asp): A .NET remoting channel (for instance, a TCP or custom channel). To use the TCP channel you need a process listening on a socket. In general, a custom process is used to listen on a socket and then host serviced components either as a COM+ library or server application. Alternatively, Dllhost can be used as the listener. Either approach is least likely to be used and would require writing a custom socket listener with proven performance, scalability and security. Therefore, the ASP.NET or DCOM solutions are the best approaches for most projects. The key issue there for .Net Remoting (always has been) is security, scalability, and ultimately performance. Are you writing custom sinks that fulfill all these requirements? Robert Hurlbut > you can expose to remote calls a class residing in a library app through > .net remoting (this is actually my favourite approach), you don't need to [quoted text clipped - 45 lines] > > > TIA, > > > Erik Cruz inline .. > Enrico, > > My mistake, that you can't reference Library apps directly through .Net > Remoting, but as Tim Ewald points out in his excellent article (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/h > tml/entserv.asp): > > A .NET remoting channel (for instance, a TCP or custom channel). To use the > TCP channel you need a process listening on a socket. In general, a custom > process is used to listen on a socket and then host serviced components > either as a COM+ library or server application. I didn't say that the .net remoting host (custom or IIS) - > com+ server app doesn't work , I just thing it's nonsense from the architectural point of view. >Alternatively, Dllhost can > be used as the listener. yes, you just have to hook somehow in the dllhost startup to register remoting types (using iprocessinitializer) >Either approach is least likely to be used and > would require writing a custom socket listener with proven performance, > scalability and security. Therefore, the ASP.NET or DCOM solutions are the > best approaches for most projects. humm .. .net remoting in a custom host has prons and cons , I know it doesn't scale well , but i still haven't understood if it's a .net remoting or a thread pool issue. and about security .. as far as i know, you can pick up this : http://msdn.microsoft.com/library/?url=/library/en-us/dndotnet/html/remsspi.asp > The key issue there for .Net Remoting (always has been) is security, > scalability, and ultimately performance. Are you writing custom sinks that > fulfill all these requirements? nope, but i was told the Indigo guys are :) > Robert Hurlbut > [quoted text clipped - 54 lines] > > > > TIA, > > > > Erik Cruz Inline .. "enrico sabbadin @ infinito" <sabbadin@infinito_xyz.it> wrote in message news:<e94cTCu0DHA.484 > I didn't say that the .net remoting host (custom or IIS) - > com+ > server app doesn't work , I just thing it's nonsense from the > architectural point of view. Granted. I checked out your article on this subject regarding chosing "remote object call" methods, and it appeared you mentioned library apps as the only choice there as well. I agree though, that if I can call a Library app because it is derived from MarshalByRef, then why not (instead of a bloated Server app)? > humm .. .net remoting in a custom host has prons and cons , I know it > doesn't scale well , but i still haven't understood if it's a .net > remoting or a thread pool issue. > and about security .. as far as i know, you can pick up this : > http://msdn.microsoft.com/library/?url=/library/en-us/dndotnet/html/re > msspi.asp Yes, everyone points to this sample, but it still has issues (hard-baked into the system (there goes x-copy), possibly some issues with 1.1 configuration as it was originally written for 1.0, etc.). By the time you do all that, you might as well use what ES gives you -- even Ingo Rammer admits that: http://www.ingorammer.com/RemotingFAQ/RemotingUseCases.html. To me, it all comes down to your requirements, as you did point out in your article. > > The key issue there for .Net Remoting (always has been) is security, > > scalability, and ultimately performance. Are you writing custom > > sinks > that > > fulfill all these requirements? > nope, but i was told the Indigo guys are :) True, but Indigo isn't here today. Good discussion. These are issues I deal with daily, and my concerns regarding use of 1.1 technology versus waiting for Indigo. Robert Hurlbut the point is that what we have now is a totally un-unified model/technology for distributed computing (DCOM, .net remoting, web services) .. indigo will solve this .. in the while .. just weight prons and cons, test & cross you fingers :) > Inline .. > [quoted text clipped - 52 lines] > > Robert Hurlbut FYI on a previous point someone made about having dllhost as your remoting endpoint... 322627 INFO: Exposing ServicedComponents As a Remoting Endpoint from a COM+ http://support.microsoft.com/?id=322627 - Brad
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.