This pages contains some architectural notes for the design of JBossESB.
WARNING: this page under construction!!
Transformation Service definitions will need to maintain information about the type of transformations that that Transformation Service instance can perform.
Contract definitions may need to maintain info about Transformation Services that need to be performed on a Service Endpoint invocation.
We will attempt to formalise what this information is on this page.
What Transformation Types do we need to support?
SOAP to SOAP
TODO: Are there others? Add them here...
SOAP to SOAP Transformations - Required Data
Breaking it down to its most basic, a SOAP Transformation Service transforms from one SOAPAction to another. So at this level, the Transformation Service simply needs to define the "from" and "to" SOAPActions that it supports transformations on (this includes the action response transformations).
So, based on this, how would we select the "appropriate" Transformation Service for a given invocation/interaction?
Do we want the Service Endpoint to appear as it really is and leave it up to the client to figure out the transformations it needs to perform?
Using contract definitions, could we make SOAPActionX look like SOAPActionY (all on the same service endpoint)? Of course my assumption here is that the contracts define the supported action(s) on a given Service Endpoint!!
So, on option 2 above: from a clients perspective, it doesn't need to worry about how to figure out what transformations are required etc... It has the bindings to construct a SOAPActionY request and there's a contract definition in the Reg that says Service EndpointXXX can service SOAPActionY. In reality Service EndpointXXX can't service SOAPActionY, but the ESB can use a transformation service to perform the SOAPActionY<-->SOAPActionX translations (this is defined in the contract??).
From this, I think the contract definition just needs to define one additional infoset: a list of Action-In-URI to Action-TransTo-URI mappings. This info tells the ESB what transformation to perform (if any) on a given invocation - it can use this info to look up the appropriate Transformation Service from the Reg.