These days, I've been thinking about the CDL work we've done, and what we need to do in our next release. But let me summarize the issues in this mail first. I think we need to summarize all the issues/problems that we encountered in our first M1 release, before we starting to think about our next release.

For the conversational ESB actions part, I think we have following issues.

1. parallel actions. (concurrency issue)
In the conversational ESB actions, the JBoss ESB didn't have a built-in concurrency mechanism that we can leverage to support our parallel actions. For example:
We have a message object, which can be called messageA. we want to deliver messageA to two different services simultaneously. Because in the messageA, it has associated its 'session' context. In each service, it probably update the 'session' context. This means we need to guarantee only one thread to update the 'session' context. At present, I didn't see any feature/mechanism that we can use in JBossESB, so we can only try to use the database's concurrency lock.

2. Save the business class as serialization object.
In our current implementation, we need to have a way to associate our inner session with the 'pojo' business class, which will be developed by users. and then we decided that save the 'pojo' business class as serialization object for its simplicity. Otherwise, we need our users to define hibernate mapping files explicitly, which is considered to be complex.
But with the serialization object, I have found that it is very hard to debug if we have an issue, think about the hot deploy issue that Mark reported. Its not an easy job to debug and fix it.

3. Need to have database.
When I say that need to have database, I mean, even in the testing phase, users need to have installed database to test the process. we are using the in-memory database for its simplicity. But I still consider it too heavy. Looked into the jBPM, it has two modes. one is with database, which we expect people use it mostly in production mode. The other is just in memory, without any databases. It is extremely easy for users to verify the process.

4. The action's configuration in jboss-esb.xml is too much.
We all know this. ;-) , I just list here for the summary purpose. I am thinking that the action is just too fine grained from the ESB perspective. It makes more sense for me to see the whole participant process as one big jboss esb service. (like a service engine from the JBI's perspective)

Above the four issues are the main problems that I've had in my mind at the moment. I would say most of issues are related to our 'stateful' concept. It leads us to save a lot of contextual data backend. From our previous email, you said you are thinking a 'stateless' solution, I guess it won't have above issues in that way, but need to wait for your more concrete documents on the stateless solution.

What other issues do you think we've had, but I am missing here?


BTW, today I try myself to be a CDL user, which means an architect/business analyst. and then I find there is very few examples/articles/tutorials on how to build CDL file/use case by using pi4soa tool, or even not much articles on teaching people on WS-CDL spec. I think that is also a challenge we need to face, a gap that we need to fill if we want to make CDL easy to use for users. what do you think?


Thanks
Jeff