Creating the client/service deployment hierarchy

[marklittle]

This definitely needs a diagram to explain, so check here in conjunction with the current POC code drop.

Firstly, in the POC, some names changed from the diagram (or more accurately were added):

(i) client plugin in the diagram became ClientPlugin.
(ii) the rectangles in the ESBCore are Dispatchers.
(iii) MOM plugin at the client side became SenderPlugin.
(iv) MOM plugin at the service side became ReceiverPlugin.
(v) service plugin became ServicePlugin.

Typically a client hierarchy will match a corresponding service hierarchy. The dispatchers are intended for adding contextual information to the outgoing message and stripping it off incoming messages. For example, transaction or security information. In some deployments they may not be needed.

The intention is that the hierarchies of clients and services can be created dynamically. So for example, consider the case where a service is already deployed and a client discovers it dynamically, via the registry. At this point, the client hierarchy that corresponds to the service hierarchy may then be built up on the fly. Obviously "statically" deployed clients will also exist, i.e., clients where the hierarchy already matches the service-side equivalent. Also once deployed, a hierarchy may change during the course of interactions (e.g., the architecture document illustrates how migration may be accomplished through deploying different dispatchers into an "old"/running service setup).

But irrespective of how the hierarchies are created, we need to convey the right binding information to each layer. How does a client-side application know which ClientPlugin to use? Likewise, how does a ClientPlugin know which Dispatcher(s) to use.

I'm assuming this all happens through an XML deployment descriptor. In the current POC, this is represented programmatically through ContractDefinition instances. There is a top-level contract definition that is passed to the root of the hierarchy and that picks out the necessary information is needs to create the next level down, where it passes the remaining contract information. Eventually we're down to the messaging infrastructure and any additional information needed to deploy that will also be encoded within the contract definition information.

In the absence of the XML, the POC hard codes this into the TCP examples. However, the reasoning is the same.

[marklittle]

One thing that came up during the POC implementation, which actually dates back to ArjunaII days, is whether the service-side heirarchy is built up top-down or bottom-up? Another way of putting this is: is the service responsible for polling/blocking on a receive event, or is it driven by upcalls? Where this really matters (and where the original question came from 10 years ago) is in creating the service-side hierarchy: the client-side hierarchy is always top-down. But if you want to enable dynamic service deployment, then it often makes more sense to model things as being built bottom-up, with the service being driven via received message events.