JBossDeveloper

 

OK, I think the flow is starting to become a bit clearer to me now (I hope) :-) I updated the http://milyn.org/images/jbossesb-transsd.jpg with my current understanding. Is this any more accurate Mark?

That looks like it corresponds well with the text in my previous posting, with the caveats: the interaction with the transformation service should (at least logically) look exactly the same as any other service invocation, i.e., MOMAbstraction->Dispatcher Hierarchy->MOM Implementation.

Questions from the sequence diagram:
1. Is the MOMDispatcher sequence between the transformation dispatcher and service required??

One of the things that's missing from the diagram (and probably only implied in the architecture document) is the interface/stub that sits above the MOMAbstraction. Although clients can talk to services "raw", typically what they'll do is interact via some client stub that may be auto-generated from the WSDL or contract that came from the service registry lookup (similar to the client stubs that RMI produces). So in that case, all services that a client uses may be abstracted above the ESB such that the ultimate user doesn't have to see the ESB at all. And in which case, since the transformation is a service, even the dispatcher may be using it via a stub.

Does that help? If not, let me try to knock up a diagram later today.

Also remember that colocation optimisations should come afterwards: if the transformation service is in the same address space as the client, then some of this may be bipassed. But let's concentrate on the architectural details first.

2. Can the contract definition cope with this or will it require some form of contract definition hierarchy, one for the contract between the transformation dispacther and transformation service nested inside a second contract defintion for the higher level contract between client c and service s? This would seem nuts!

No, the way I envisioned it the contract definition information that the client got for the first service (S) would have to contain information about the transformation service needed to talk to S. This may be explicit, or it may be implicit (implicit: the format of the vocabulary S talks will be mentioned in the contract and if it's not the same as the one the client talks then the client will need to find out where an appropriate translation service resides). The contract for the transformation service would be looked up in the registry in the same way as any other service. However, there is no reason why this lookup couldn't be done by the registry and returned within the first lookup response, as part of the contract for S. In fact, WS-A provides hooks for that if necessary.

So, from this, do we still need a "special interface" for transfomation services? I still can't see why we would!!

We need language level bindings (c.f. Java interfaces) - these may be generated automatically from WSDL (as an example), but ultimately they are the things that the developer will program against. Sure some developers may want to work directly at the ESB API level and we won't prevent that, but it's not necessarily the most natural fit for the majority of users: we need to make the glue between endpoints as simple as possible and many pre-existing services that will want to plug in to the ESB will already have interfaces defined.

Then we need the message exchange pattern, which is essentially what something like WSDL describes: what's the format of the messages that the service will accept, are they request/response or one way, etc. This is another level of interface.