Where does defining a choreography fit in a service oriented design methodology?
It depends I guess whether it is a new project, or enhancing an existing SOA.
In a new project, it would be possible to use a choreography in a contract/model driven approach, to design the observable interactions between all services. These can then be used to guide the development and testing of each service.
In an existing project, it may be useful to 'reverse engineer' a choreography of an existing architecture (representing your 'AS IS' architecture) and then produce a modified choreography representing your target architecture. This could then be used to understand the impact of changes and manage the modification of existing services, and creation of new services to meet additional requirements.
Who would create a CDL model (what type of a user)? From what sort of requirements?
Generally I think it would be an architecture. As part of the pi4soa project, we are using scenarios (UML sequence diagrams++) as a means of capturing behavioural requirements, which can then be tested against a choreography description, to ensure that it means the requirements.
What is the relationship between choreography and orchestration in terms of the SOA Platform (i.e., how would a CDL based choreography relate to a jBPM process definition)? Or BPEL process?
The easiest way to answer this is to think of the choreography as the 'blueprint' for the architecture, and orchestration (BPEL or jBPM) as an implementation technology used to implement services within that architecture.
How is the jboss-esb.xml created? By hand, or generated from CDL model? I think from other forum posts the intention is to generate it but was not sure. If it is, how would the user add additional actions to the services, and not have them lost when re-generating?
At present we are not generating, but it will be a natural next step. As WS-CDL is not executable, it can only be used to generate a template containing the 'observable' activities for a service. Therefore any additional non-observable activities, such as custom ESB actions in this case, would be added directly to the jboss-esb.xml.
It would also be possible for a user to add other 'observable' conversation based activities into the xml - which would then be checked for conformance against the choreography. However, as you have pointed out, it may be necessary to re-generate a service if significant changes have been made to the choreography.
In this situation, the intention would be to merge the user changes with the newly generated service. How this would actually be implemented is not defined yet.
The examples need a readme that explains what is going on with them, what are the requirements that resulted in the CDL model. How the jboss-esb.xml was created, etc.
Yes, much more documentation is required. We are still at the early stages of implementation - but hopefully it will all be fully explained by the first release.
Is there an enhance pi4soa plugin that supports jboss-esb integration? I am using pi4soa1.7.0.?
pi4soa1.7.0 has a basic mechanism for generating and deploying Java endpoints into a JBossESB environment. However pi4soa2.0.0 is the release that is targetted to have the conformance checking against conversation based ESB actions, as well as monitoring of the JBossESB deployed services against a choreography.
I see all these ESB actions that correspond to CDL activities. Is there any thought to map these to a jBPM process? Would that be a different generation target?
We do eventually plan to generate to jBPM and do conformance checking. Overlord plans to provide this functionality across a number of target platforms, not just JBossESB.
What is a ReceiveMessageAction supposed to do? The current implementation does nothing really. In particular the message operation property is not used.
Normally the action pipeline would silently consume an inbound message, and it would not indicate what type of message it was, or whether it was associated with an operation name, or any information that would help to correlate it to a conversation session.
From a runtime perspective, the ReceiveMessageAction could be considered redundant. However from a governance point of view it has two benefits - statically it enables us to understand information about the message to be received, to compare this against the choreography description. Dynamically it also means that a received message can be validated at runtime to ensure that it was the expected type, identity, etc.
Message operation is not currently used as we have only been testing with async message interactions. At some point we will also be looking to deal with rpc style examples, to handle web services etc.
What would the action chain look like if the services were web services? Where is that level of detail specified? In the CDL tool or in the jboss-esb.xml?
I have not yet modelled a web service based action pipeline, so I cannot answer this with authority at present. However from examples that I have seen, I believe the fact that an action pipeline is associated with a web service has no reflection on the action pipeline configuration - only on the providers.
Therefore I don't think the choreography or deriving behaviour from the conversation based ESB actions would be affected. The only area that may be affected is the runtime validation (e.g. ReceiveMessageAction) which may be able to get access to the operation associated with the web service invocation, to validate it against the property.
Great set of questions :-)
Gary answered pretty much of the questions. here is the design document link for conversation based ESB actions, For Your Reference: http://anonsvn.jboss.org/repos/soag/trunk/docs/conversation/
Any comments are welcome.
Jeff, thanks for the questions. Sorry I couldn't get to them myself, but Gary has taken the words out of my mouth (more than I would have said too).
In general we've got to move away from the traditional way of developing distributed systems when looking at SOA, otherwise we lose many of the benefits it can bring. As I've said on a separate forum posting (and in copious emails over the years), SOA is not just technology, but a change in the way human processes work. That inevitably has a knock-on effect on the way in which people have to approach development of, and subsequent deployment of, SOA based applications (and even individual services). Yes, it's no longer encouraged to just take a POJO and "expose it on the bus", but that's a good thing. The other route (which has been exemplified by MSFT and others) leads you morphing SOA (or Web Services as a specific development technology) into distributed objects, aka "CORBA with angle brackets" (or "JavaRMI with angle brackets"). Developers won't get the benefits, as I said before.
So what we're doing here is an important part of the change of mind-set that has to happen in order to deliver on SOA. But we do have to figure out how this can be targeted at existing services and infrastructure, otherwise it'll have a limited reach.