Remoting Configuration allows for the various components of NGWS runtime Remoting to be specified external to the user code. This section detailed how Remoting configuration is used and the elements in the configuration file.
Key Points
Key Points
When an application is first started it performs a number of activities. One of these is to register the channels. The channel can use this opportunity to start to listen for requests on the protocols they were designed for. One of the aspects of registering the channels, is when a server object reference returned to the caller as the result of a method call, an ObjRef is created. The ObjRef is populated with the channel data of the registered channels. This allows the caller to make method calls on the remote object using the available server protocols if those protocols are also available on the caller.
Another aspects of registering the channels, is when a server object reference returned to the caller, the ObjRef is populated with the channel data of the remote applications registered channels. This allows the caller to make method calls on the remote application objects using the available remote application protocols if those protocols are also available on the caller.
Channels are registered via ChannelServices.RegisterChannel.
Key Points
In order for incoming calls to reach the server objects, the inbound object identifier (URI) needs to be resolved to the real server object and the first message sink that can be used to communicate with the real server object. Remoting Services uses the entries in the identity table in order to find these items. Entries are place in the identity table when objects are registered (marshaled). Objects are registered (marshaled) when server object references are returned, as the result of a method call. Objects can also be marshaled for WellKnown objects.
Well known objects can use well known names (ObjectURI) and register these into the identity table. There are three types of well known objects:
Well Known objects can only be published / marshaled in the appdomain in which they were created.
When context-bound objects are created a matching context is found or create that meet the context property requirements for the object. See the context section for further details.
When a server object is marshaled the server object sink chain, which leads to the object is built. The stack builder sink is the last sink in the server object chain and communicates with the server object directly. The stack builder sink is provided by the remoting infrastructure. When a server object that is context-bound is marshaled, the reference to the context in which the object was created is stored in the entry in the identity table.
When inbound calls arrive, they are dispatched on the server object. The identity table provides the URI to object, context and message sink chain mapping.