| Groups | Blog | Home |
dotnet remoting : Need some advice on architectural design and remoting.
I'm quite new to remoting, with few real world implementations. But since i
started reading about remoting I'm hooked up on this topic, really interesting. I had a lot of book reading on this. I have the following scenario: - Central SQL Server with a quite big database. - Complete (and tested) LLBLGenPro DAL of my relational domain. - Lot of custom BLL components. - ASP.NET/C# web site consuming all the underlying components. It's a corporate web application used by about 500 people all around the country. The application works really well, with good performance. Right now... I have a requirement of creating a "WinForm client" with all the functionality of the actual website and a bunch of new features (some of them almost possible just with rich clients). Since I'm using the "Adapter" scenario of LLBLGen (a "factory design")... it 's quite easy for me to right a wrapper component for the DAL and the BLL, make that component remotable, and create a host (possible IIS or windows service) for it. The clients will access the component over the Internet. So... imagine a WinForm client that needs to access the "remote object", firstly with login information and with all subsequent method calls accessing specific data for THAT client. My first thought was a CAO scenario, with every client creating an instance of the main object. The idea was... letting the client create the instance, and have that instance alive all the time while the user have the client "connected" (the connection periods can be 10 hours per client or even more). The instance could store client information, login, client-specific parameters and have every method using that state data to perform the actions. So, my first (easy) question is...: it's even close to reality having a remoting object instantiated so long? There is any serious limitation related with server capacity, threads, and that kind of stuff? I now CAO take down scalability seriously, but I'm assuming that my actual hardware can handle easily all the possible "rich clients". The other possible way is: having a SingleCall scenario, when the first login method returns a "token" (and the host persisting that token on the DB, or something like that)... and every subsequent method call will send that token among the other parameters. Every single comment on this will be REALLY appreciated. Tnx in advance.
[quoted text, click to view]
>So, my first (easy) question is...: it's even close to reali=ADty having a >remoting object instantiated so long? There is any serious l=ADimitation >related with server capacity, threads, and that kind of stuf=ADf? Yes. You could practically allow the CAO to live as long as the client application's alive... but with bandwith and memory costs. When implementing CAO, the server determines the lifetime of the cao, and according to your implementation the cao should live as long as the client is alive. This involves regsitering a client side sponsor that the server can ping at reggular intervals to see if it should discard the cao object at the server side... When dealing with a relatively high transacted environment, the pinging between the server and client slows the system network considerably.. and over the internet is a complete different thing. Coming to scalability, you can forget it with CAO. CAO's serious limitation is that once it is created it binds to the specific end point to the server. That means out goes load balancing. You cant take any load balancing or web farm advantages of IIS when you host CAO services. The same above is valid for marshalled SAO services. [quoted text, click to view] >The other possible way is: having a SingleCall scenario, whe=ADn the first >login method returns a "token" (and the host persisting that=AD token on the >DB, or something like that)... and every subsequent method c=ADall will send >that token among the other parameters. SingleCall's are the best when it comes down enterprise level distributed apps. They dont take up that much memory (they are gc'd at the next garbage collection cycle), you can use IIS load balancing and web farms to scale your application, and dont consume excess network bandwith if the interfaces arnt chatty. I would suggest using the SingleCall scenario. Admited its a litle more complex and required more plumbing than the CAO approach, but the result will a more responsive and scallable application. Thats my 2c. NuTcAsE
I would agree with this as we are in the process of performance tuning /
scaling our application and IIS Hosted SingleCall (binary formatter) seems to be the best. It may not be the ultimate performer but when the load begins to get heavy, it scales gracefully especially with the Web Garden feature of IIS 6 (IIS5 has a simular thing when you use the High (Isolated) process for the IIS Application in COM+). FYI... I also did some testing with compression (with datasets I was getting 300K to 30K) but for us the connection between the servers was high and so saw little to no improvement with it in place. If there was a slower connection it would likely be of benefit (internet vs intranet). Fred [quoted text, click to view] "NuTcAsE" <rao.ritesh@gmail.com> wrote in message news:1107284463.651878.51620@c13g2000cwb.googlegroups.com... >So, my first (easy) question is...: it's even close to reality having a >remoting object instantiated so long? There is any serious limitation >related with server capacity, threads, and that kind of stuff? Yes. You could practically allow the CAO to live as long as the client application's alive... but with bandwith and memory costs. When implementing CAO, the server determines the lifetime of the cao, and according to your implementation the cao should live as long as the client is alive. This involves regsitering a client side sponsor that the server can ping at reggular intervals to see if it should discard the cao object at the server side... When dealing with a relatively high transacted environment, the pinging between the server and client slows the system network considerably.. and over the internet is a complete different thing. Coming to scalability, you can forget it with CAO. CAO's serious limitation is that once it is created it binds to the specific end point to the server. That means out goes load balancing. You cant take any load balancing or web farm advantages of IIS when you host CAO services. The same above is valid for marshalled SAO services. [quoted text, click to view] >The other possible way is: having a SingleCall scenario, when the first >login method returns a "token" (and the host persisting that token on the >DB, or something like that)... and every subsequent method call will send >that token among the other parameters. SingleCall's are the best when it comes down enterprise level distributed apps. They dont take up that much memory (they are gc'd at the next garbage collection cycle), you can use IIS load balancing and web farms to scale your application, and dont consume excess network bandwith if the interfaces arnt chatty. I would suggest using the SingleCall scenario. Admited its a litle more complex and required more plumbing than the CAO approach, but the result will a more responsive and scallable application. Thats my 2c. NuTcAsE
The idea you're proposing is certainly very valid and one I've used before
(using a CAO as a "Session" object essentially o cache the client's credentials and act as an entry point for all requests from the client). It's just important that you understand the ramifications of this choice and the possible issues you can run into down the road. Here are the ones I think are most significant for your situation: 1) The number one issue with using CAOs in this manner is scalability, particulary if you need to go to a web farm envrionment. You should be 110% sure that you can handle the load on your one server before you move ahead with this type of architecture. 2) The CAO lifetime issue is especially a problem in a WAN environment where, even if you use Sponsors, the server probably cannot connect back to the client to see if the object's still in use. One alternative to sponsors is to solely depend on the RenewOnCall feature and set the timeout to be fairly long. This, of course, can cause a buildup of dead CAOs that will hog memory. Another option (and one I've used) is to buy a third-party product such as GenuineChannels (www.genuinechannels.com) that allows you to track the connection state of clients so your server can proeprly dispose of CAOs when the client disconnects. Then you can simply set every CAO's lifetime to infinite and forget sponsors altogether. Good luck - Ken [quoted text, click to view] "Toble Rone" <toble5@yahoo.com.ar> wrote in message news:eExPrn$BFHA.1524@TK2MSFTNGP09.phx.gbl... > I'm quite new to remoting, with few real world implementations. But since i > started reading about remoting I'm hooked up on this topic, really > interesting. I had a lot of book reading on this. > > > > I have the following scenario: > > > > - Central SQL Server with a quite big database. > > - Complete (and tested) LLBLGenPro DAL of my relational domain. > > - Lot of custom BLL components. > > - ASP.NET/C# web site consuming all the underlying components. > > > > It's a corporate web application used by about 500 people all around the > country. The application works really well, with good performance. > > > > Right now... I have a requirement of creating a "WinForm client" with all > the functionality of the actual website and a bunch of new features (some of > them almost possible just with rich clients). > > > > Since I'm using the "Adapter" scenario of LLBLGen (a "factory design")... it > 's quite easy for me to right a wrapper component for the DAL and the BLL, > make that component remotable, and create a host (possible IIS or windows > service) for it. The clients will access the component over the Internet. > > > > So... imagine a WinForm client that needs to access the "remote object", > firstly with login information and with all subsequent method calls > accessing specific data for THAT client. My first thought was a CAO > scenario, with every client creating an instance of the main object. The > idea was... letting the client create the instance, and have that instance > alive all the time while the user have the client "connected" (the > connection periods can be 10 hours per client or even more). The instance > could store client information, login, client-specific parameters and have > every method using that state data to perform the actions. > > > > So, my first (easy) question is...: it's even close to reality having a > remoting object instantiated so long? There is any serious limitation > related with server capacity, threads, and that kind of stuff? I now CAO > take down scalability seriously, but I'm assuming that my actual hardware > can handle easily all the possible "rich clients". > > > > The other possible way is: having a SingleCall scenario, when the first > login method returns a "token" (and the host persisting that token on the > DB, or something like that)... and every subsequent method call will send > that token among the other parameters. > > > > Every single comment on this will be REALLY appreciated. > > > > Tnx in advance. > > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |