Designing distributed application RRS feed

  • Question

  • Hi,

    We have developed an enterprise application which is is production now. To make it scalable, I want to make it one of its components distributed using Remoting. However, during analysis, I have realized that this distributed component would require a lot of business/entity classes from core framework which means that this distributed component is dependantant on its caller. To execute its functions, caller assembly (containing business classes) must be shipped to this distributed component. Now my questions are

    1- Would it be a good design to ship caller assemblies to the remote component. This would also mean that when we introduce any change in domain classes, updated assembly should be deoployed to remote component.

    2- Does it seem cyclic dependacy? As framework (caller) needs data from remote componets to accomplish its task. While on the other hand, remote component also need assembly of caller (containing business classes) to provide the required functionality.



    Tuesday, March 30, 2010 12:20 PM

All replies

  • I usually like to refactor out shared concepts into a domain assembly. This could then be used to house classes and interfaces used across other assemblies. With this I can then use a tool like structuremap to get an instance of an object defined by an interface and configured at runtime. This way I can run a piece of my app layer on my local app server and I can run another piece through wcf from a distributed app server. And the configuration of what runs where is totally configurable. This also means I can keep my concerns where they need to be. There shouldn't be a reason to have business logic performing service classes accessed by data layer repository classes.
    Andrew Siemer www.andrewsiemer.com blog.andrewsiemer.com www.socialnetworkingin.net
    Tuesday, March 30, 2010 1:51 PM
  • hi zohooo,

    first some questions. you mentioned scalable and [.net] remoting, sadly remoting is not as scaleable as we would like since it is basically a RPC technology. the calls from a certain perspective are synchronous though you could arguably place the method call in a different thread but that's a tad expensive.  consider messaging model communications such as raw MSMQ or better yet MSMQ via WCF as a better alternative.

    having said that, lets get back to your questions:

    there's nothing wrong with deploying relevant assemblies that will be used by the remote component.

    • contracts - yes its better to use a separate assembly to merely define types and contracts (interfaces) that all other parts of your program refer to. this is also important when you need to define an event so that the server can call back into the client
    • service - define an assembly that implements your remoted types (the service)
    • host - define a host exe/assembly that will create an instance of the service (from prior step) that clients call into.

    check out this article WCF the Manual Way .  It talks about WCF but the pattern described here is most applicable to remoting too



    MickyD | http://mickyd.wordpress.com/ Help others by voting my post as 'Helpful' if you think it is so.
    Thursday, April 1, 2010 10:35 PM