3 Replies Latest reply on Nov 20, 2008 6:16 AM by Mark Little

    Summary of CDL conversational ESB actions.

    Jeff Yu Master

      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?


        • 1. Re: Summary of CDL conversational ESB actions.
          Jeff Yu Master

          This thread is for summary purpose, if you have answers to specific issue, please start a new thread, because it will be easier to track and more focused. Thanks!


          • 2. Re: Summary of CDL conversational ESB actions.
            Gary Brown Master

            My initial comments are also fairly general, so will just comment on this thread - but if we want to explore in more detail then we can start a separate thread.

            On the concurrent issue (1), using the database is really the only way - as it is possible the session may receive multiple messages anyway, so these have to be dealt with in a synchronized manner. I imagine it may also be possible for the same service to be deployed in different clustered JBossESB environments, and therefore different events could be processed in different JBossESB environments - but synchronized through a central db. For simplicity, touching on your issue (3), wouldn't it be possible to use an in-memory database configuration with Hibernate?

            I agree with the issues you have raised. The "stateful fragments" work is still in the concept phase, but will let you know as soon as I think this may be practical - and I believe it would solve most of these problems.

            In terms of your comments on CDL, I agree - I am currently working on a "getting started" guide for pi4soa, which will hopefully help. But we may need to consider what else can be done. Steve Ross-Talbot has been working on a book, which may also help.

            • 3. Re: Summary of CDL conversational ESB actions.
              Mark Little Master

              Yes, I agree that the database is the easiest solution to the concurrency issue. Doing replicated updates to state is possible, but it's extremely complex particularly when you factor in failures.