System architectures beyond client/server

System architectures beyond client/server

Old forum URL: forums.lhotka.net/forums/t/4112.aspx

JHemminger posted on Thursday, January 03, 2008

Fellow CSLAers -

We are looking to use CSLA in our product which is predominantly a client/server environment, which CSLA shines happily in.  I however work with an ancillary product that allows our client to see their data over the web.  Our architecture for this has 3 points of communication.  The web pages are hosted in house, our clients install our "weblink" software which is required to be on a separate server than the DB/application server and in a DMZ, the weblink machine then communicates to the application server.  So in order for CSLA to work with our full product line we need it to be able to scale beyond just a client server architecture.  Currently if I were to configure my web pages to get data from the server it would try to instantiate and use the objects on the weblink machine.  I need the weblink machine to NOT do this, but rather pass the call to the "real" server.
 
My Solution:  I have modified the DataPortalClient, and the RemotingProxy classes to basically look to see if the config file has a setting for CslaDataPortalUrl when a call comes in through the remoting channel.  If it finds a setting it then acts just like a client and passes the call to the configured server.  This code change provides a solution to our problem.  I have ran some performance tests and have not seen any adverse affects due this extra check.
 
Has anyone else ran into this problem?  If so, what was your solution?
 
Questions?  Comments?  Suggestions?
 
I can post my changes to the two classes if anyone is interested.
 
Thanks,
Joel

RockfordLhotka replied on Thursday, January 03, 2008

You should be able to do this without modifying CSLA itself.

The data portal is interface-based, and so it should be possible to create a "relay" application that includes a custom host class. Probably start with a copy of Csla.Hosts.RemotingPortal, perhaps called RemotingRelayPortal.

You'd then change RemotingRelayPortal to not delegate the call to Csla.Server.DataPortal, but instead to delegate the call to an instance of RemotingProxy. For example, the Create() method would look something like this:

    Public Function Create( _
      ByVal objectType As System.Type, _
      ByVal criteria As Object, _
      ByVal context As Server.DataPortalContext) As Server.DataPortalResult _
      Implements Server.IDataPortalServer.Create

      Dim proxy As DataPortalClient.IDataPortalProxy = New RemotingProxy
      Return proxy.Create(objectType, criteria, context)
    End Function

On your relay server, your web.config would route inbound remoting calls to this RemotingRelayPortal class, which would simply re-route them to the real server.

There will be a performance hit though, because Remoting will deserialize the inbound message before invoking your relay method, and then the parameters are serialized again as they are sent to the real app server. The same with data going the other way.

But if the perf hit isn't troublesome to you, then it doesn't really matter Smile [:)]

The only way I know of to avoid this perf hit is to use WCF and implement the relay at the transport or maybe at the message layers - before deserialization/serialization occurs.

ajj3085 replied on Friday, January 04, 2008

In addition I think a forum search would be a good idea because, IIRC, someone has already implemented such a remoting proxy. 

mr_lasseter replied on Friday, January 04, 2008

Maybe I didn't understand the architecture of the original post, but it was my understanding that the following would work out of the box with CSLA:

DMZ - (Contains web pages ) -> App Server (contains the business objects) -> Database (contains the database server)

I am guessing the original poster couldn't do this since the object weblink server was really just a proxy to the dmz server?  Am I missing something?

Thanks,

Mike

 

JHemminger replied on Friday, January 04, 2008

Thanks for the info Rocky.  I will change what I currently have and try that new class.

In response to this:
"Maybe I didn't understand the architecture of the original post, but it was my understanding that the following would work out of the box with CSLA:

DMZ - (Contains web pages ) -> App Server (contains the business objects) -> Database (contains the database server)"

You are correct and CSLA would work right out of the box for this.  But this is not my scenario, there is another machine between the App Server, it would in a sense look like this:

DMZ - (Contains web pages ) -> DMZ - (Link to App Server From Web ) -> App Server (contains the business objects) -> Database (contains the database server)

Thanks all,
Joel

RockfordLhotka replied on Friday, January 04, 2008

That was my understanding. That for external clients he has:

client->relay->app server->database

While for internal clients he has

client->app server->database

So the trick is to write a data portal host/proxy combo to act as a relay.

JHemminger replied on Friday, January 04, 2008

RockfordLhotka:

That was my understanding. That for external clients he has:

client->relay->app server->database

While for internal clients he has

client->app server->database

So the trick is to write a data portal host/proxy combo to act as a relay.



Correct.

JHemminger replied on Friday, January 04, 2008

If anyone is interested here are the classes I made/well copied and hacked!  And remember to change your config files accordingly.

Thanks Rocky.

~Joel

JoeFallon1 replied on Friday, January 04, 2008

I use the architecture Mike describes "out of the box". So there must be something different about the poster's app.

Joe

 

Copyright (c) Marimer LLC