NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

WebServices, Well Known Objects, Single and Singleton, Client Activated Objects

A WebService can be thought of an entry point into an Application. The entry point is specified by a URL with an object servicing the messages sent to the URL. Logically it can be thought that objects live at the end of URLs. The objects that make up an Application and service message can configured in variety of ways. These are detailed in the topics below.

SingleCall

One popular way, is for each incoming message to be serviced by a new object. When the message arrives a new object is created, the message is processed by the object, an optional reply returned and the object is discarded. In NGWS runtime remoting this is called a “SingleCall WellKnown Object”. Single call objects can use the ASP+ state service to store application and session state if needed. Single call is advantageous in applications where the multiple servers in a serve farm are providing the same application. The incoming messages can be load balanced across the servers in the farm with high scalability being achieved by adding commodity servers to the farm. The load balancing can be performed by simple techniques such as DNS robin or more sophisticated techniques that involve network load balancing at the IP level (NLBS) or application level load balancing.

Figure: WebService Application with single call objects, each message is dispatched to a new object instance

Singleton

Another popular way, is that all message sent to URL in an application are serviced by the same object instance. In NGWS runtime remoting this is called a “Singleton Well Known Object”. Singletons are useful when resources can be “warmed up” and shared across all messages. Singletons also provide the one way to have a conversation of messages with an application.

Figure: WebService with singleton object, all messages are sent to the same object instance

For both SingleCall and Singleton, when the user instances a new object in their application (locally they receive a proxy), no communication occurs until the user calls on the proxy. When the proxy is called, it generates messages that are sent to the channel, which the channel transports to the remote application.

Client Activated Object

Another popular way is for the object to be activated on request from the user. For example when the user instantiates a new object via “new SomeClass()” or Activator.CreateInstance and before the thread returns to the user code, an Activation Message (IConstructionCall message) is sent to the remote application. When the construction message arrives at the remote application it is processed by a Remoting Activator and a new object is created. A message with an Object Reference (ObjRef ) is returned to the Local Application.

One of the useful functions of Client Activated Objects is that constructor arguments can be passed by the Local Application to the constructor of object in the Remote Application. Another useful function is that Client Activated Objects can hold state between messages.

Figure: WebService Application with Client Activated Object, each “new” in the Local Application results in a new object in the Remote Application.

Passing objects between Applications

Objects fall into roughly 3 categories namely Marshal By Value, Marshal By Reference and Not Remotable.

Objects can be passed between applications in a number of ways. The objects may be passed as parameters to or returned from a method call. Likewise an object may be passed between applications are the result of a field or property access. Marshal By Value objects that are embedded as fields within Marshal By Value objects are also that transported By Value. Marshal By Reference objects embedded as fields within Marshal By Value Objects are transported By Reference. Marshal by Value Objects that are embedded in Marshal By Reference Objects as fields or properties are only transported when the user accesses the field or property.

Well Known Objects and Client Activated objects can be specified in the NGWS runtime remoting Configuration or with APIs.

Marshal By Value Objects

For objects that are Marshal By Value (MBV), a complete copy of the object is made when the object is passed from one application to another.

Figure: Passing Marshal By Value Object

Marshal By Reference Objects

For objects that are Marshal By Reference (MBR), a reference to the object is made when passed from one application to another. When the object reference (ObjRef) arrives in the remote application, it is turned into a “proxy” back to the original object.

Figure: Passing Marshal By Reference Object