.Net Remoting Design Decisions

As much as I'd like to jump straight into the typical "hello world" example of .Net Remoting ,you ned to make a few fundamental choices before you even start to implement an architecture that incorporates .Net Remoting.These choices concern the type of activation,the object lifetime,and the message format and network transport used for communication.

Activation Modes:
.Net Remoting supports three types of objects:

1.Single Call:

These stateless objects are automatically created with every method invocaton and live for only the duration of that method.The client can keep and use the same reference,but every call results the creation of a new object.

2.Client-activated:

These objects are most similar to ordinary objects.They retain state,and each client receives a separate instance.

3.Singleton:

This type of object retains state but shares it between every client.No matter how many clients connect,there is only ever one remote object instance.

The inevitable question is which activation type represents best design practices? single call objects are usually ideal because they have a very low and overhead.They don't consume any server resources when they are not working,and they can easily be hosted on multiple servers with clustering because of their stateless design.

Client-activated objects,on the other hand,are often easier to program with because they resemble ordinary objects.The problem is that this false sense of familiarity can lead developers to use them in disastrous ways.Because client-activated objects retain state ,for example,you might be used to tempted to use property procedures,member variables, and other object oriented practices to simplify coding.Because of the nontrivial overhead required to make a network call, however,setting and retrieving properties individually can greatly slow down your application.

Singleton objects are probably the most difficult to manage properly. Because multiple clients can call methods at the same time,there is the potential for concurrency error - subtle but serious problems that occure when data is modified simultaneously.Unfortunately concurrency errors often don't appear in developing testing and are difficult to repeat and diagnose.In addition,because of their state,singleton objects can't be used in load-balancing scenarios with multiple servers.Generally,you shouldn't use a singleton object unless you need to.

Object Lifetime:

Singleton and client-activated objects have state,but they can't be allowed to live forever.Consider what would happen if the client were to forgot to release the object or just disappear from view due to network problems.In these cases, the server-side object they created would linger on in a useless zomable state,wasting valuable server resources.Multiplied by hundreds of clients over the period of several days,the server might be choked to a standstill by memory that was nevr properly released.


Comments

No responses found. Be the first to comment...


  • Do not include your name, "with regards" etc in the comment. Write detailed comment, relevant to the topic.
  • No HTML formatting and links to other web sites are allowed.
  • This is a strictly moderated site. Absolutely no spam allowed.
  • Name:
    Email: