10 Replies Latest reply on May 23, 2008 5:07 AM by Mark Little

    Homogenous service connected by ESB



      I am currenlty (quite a long time:-))working on thesis. Its theme used to be connection of heterogenous services. The thesis has a practical part as well. When I was looking for a task at some company, I got following challenge - speed up a business process several times by processing it in a distributed way. The business process reads some data from database and then it writes another data to database. The business process took several hours. When I heard this task, I got an idea that this is ideal for usage of esb.

      I have split the business process into 4 distinct java services. I have created cluster of computers connected by jboss esb. I have deployed these services to each computer in a cluster (and increased maxthreads attribute in jboss-esb.xml as well).

      There was a necessity that whole business process runs in one distributed transaction, so I have created action classes that work with distributed transactions, http://www.jboss.com/index.html?module=bb&op=viewtopic&t=129260 (begin transaction, terminate transaction, associate transaction with current thread, etc.). Because my logic is in EJBs, I have adjusted J.Hallidays's transaction bridging and integrated it to those action classes. The result is, that performance is better multipletimes, the more computers, the better performance. Communication load is minimal. Distributed transaction (WS-Transaction) works perfectlly. Unfortunately transaction recovery has not been done so far
      http://www.jboss.com/index.html?module=bb&op=viewtopic&t=134357. The process lasts 3 hours with one computer and 1h30min with two computers. I can share these action class if you want, I think that distributed transaction integration into esb is desirable.

      I would like to ask, what you think about usage of esb with primary goal - to boost performance. When I read articles about esb, I read that esb is suitable for connecting heterogenous services. In my case I connect homogenous services and I am persuaded that esb is ideal means for doing that, I just use esb with another goal in mind....

      Thank you for your comments,

        • 1. Re: Homogenous service connected by ESB
          Martin Vecera Novice

          Hello Pavel,

          I'm glad to see that you continue to use JBoss projects.

          What you described here is definitely a great job! I would appreciate your sources as well as the business process definition. The more information you could provide the better.


          • 2. Re: Homogenous service connected by ESB
            Mark Little Master

            This is certainly interesting work and I hope you get your thesis as a result :-)

            I'm not sure why you think ESB should be more suited to high performance than, say, a vanilla JMS implementation.

            Without being able to see the code, it's hard to know how this might fit within the rest of the transactional aspects of the ESB. It should, fairly obviously.

            • 3. Re: Homogenous service connected by ESB

              For the sake of simplicity, let's say that business process processes customer accounts.
              There are several types of accounts (silver, gold, extra, ...). There is totally 30 types of customer accounts.

              In the beginning of each month the process must be started.

              Following code describes all business logic in two for cycles:-).

              Transaction tx = null;
              try {
               tx = transactionManager.begin();
               List<AccountType> accountTypes = accountTypesDAO.getScheduledAccountTypes();
               for (AccountType accountType : accountTypes) {
               List<Account> accounts = accountsDAO.getAccountsByType(accountType) // out of memory exception is thrown
               for (Account account : accounts) {
               AccountResult accountResult = processAccount(account); // makes some computation
               accountResultsDAO.persist(accountResult); // persists result of computation
              } catch (Exception e) {
               if (tx != null)

              This implemenation of BP does not work in reality, because total number of accounts of particular type
              can be up to 1 000 000, so out of memory exception is thrown. The workaround could be following: I read only
              ids of accounts (it's ok with memory). I split selected ids into sets of fixed size (let's say 250), and then
              I read and process only acounts which have id in the set. Garbage collector frees memory transparently after
              each set of ids is completely processed.

              As I have written, the challenge was to use more computers to process the BP. That could save memory,
              CPU load of single computers, scalability, load balancing etc... Primarily the performance could be much better.

              I wanted to use JBoss ESB, because
              1. I want to use messaging (I want to use parallel execution, but I do not want to create own threads in session beans, which is discouraged in J2EE. Messaging (MDB) is the ideal means for parallel execution in J2EE)
              2. I want to make use of added value of ESB that gives to JMS, resp. MDB (routing,
              action processing pipeline, splitters, aggregators, separation! of application logic and communication logic (I can not see this separation in MDB),....)
              3. I have studied esb, transactions, distributed transactions, ws-transactions, jBPM,... a lot (more then half an year), I do not want to throw that time away.
              4. I needed to integrate distributed transactions, I have a plan to create action classes that works with transaction. Action classes are ideal to place to put transaction logic. Distributed transaction support in JBoss-4.2.1 is ehmmm, poor (I can not see any distributed transaction support at all).

              I have created following esb services.

              1. ReadScheduledAccountTypes - The service begins distributed transaction. It is a splitter that reads
              scheduled account types. Each type is inserted into a single esb message. The service then routes all created
              messages to service ReadAccountIds.

              2. ReadAccountIds - It's a splitter, that reads accounts ids of particular account type. It creates a lot of smaller
              lists of ids from the one big list. The size of smaller list is configurable from jboss-esb.xml.
              Each smaller list of ids is inserted into single esb message. The service then routes all created messages to
              service ProcessAccounts.

              3. ProcessAccounts - The service processes input message containing one set of accounts ids. It reads accounts of
              particular ids from database. Then it processes these accounts and persists accounts results to database.
              The service sends esb message to aggregator AccountAggregator.

              4. AccountAggregator - The service aggregates results from service ProcessAccounts. When all
              accounts of particular type are processed, it sends aggregated message to AccountTypeAggregator.

              5. AccountTypeAggregator - It aggregates results from AccountAggregator. When all account types are processed,
              I can commit distributed transaction and end whole business process. The service aggregates "aggregated messages".

              As you can see, I use nested splitters and aggregators. To ensure that all acounts of particular type are aggregated in
              one AccountAggregator, the ReadAccountIds splitter must choose one concrete AccountAggregator in a cluster. The service
              ProcessAccounts uses special action RouteToAggregator that routes the result message to chosen aggregator.
              The same applies to ReadScheduledAccountTypes and AccountTypeAggregator.

              I have solve exception handling as well. I use faultTo in messages. For example if ProcessAccounts fails, it automatically sends message to chosen AccountAggregator, so no messages are lost.

              Now I will write stuff about distributed transactions....
              I am looking forward for your comments!

              • 4. Re: Homogenous service connected by ESB
                Mark Little Master

                OK, so when you say "high performance" you're not really talking about throughput, but more about the efficiency savings you get as a developer: you don't have to worry about doing all of these things manually as many of them are handled for you by the ESB. If that's the case then I think we're in agreement. But I wouldn't call it "high performance" ;-)

                • 5. Re: Homogenous service connected by ESB

                  I may use bad terminology, pleas correct me.....

                  I mean that we can achieve higher performance when BP runs in a distributed environment. If the process runs only on one computer the performance is limited by speed and available memory of the computer. If we can scale the system out (term from http://en.wikipedia.org/wiki/Scalability), we can increate performance.....

                  • 6. Re: Homogenous service connected by ESB

                    > you don't have to worry about doing all of these things manually as many of them are handled for you by the ESB

                    1. I have created action class Splitter - from one message it creates more another messages (it's not standard StaticRouter - one message copies to more messages). The splitter (at least two months ago was not in standard release, I have to make my own.).
                    2. I have created action class Aggregator - It's built on standard Aggregator, but I need to adjust it, because of copying transaction context, and some other help field from message to aggregated message. Then I add some functionality to my aggregator related to distributed transactions. But it mostly comes from original aggregator.

                    • 7. Re: Homogenous service connected by ESB

                      But that's ok, I like very much that ESB enables me to add whatever action class I want. I like JBoss ESB structure.

                      • 8. Re: Homogenous service connected by ESB
                        Mark Little Master

                        I think we agree on the benefits. We can fix terminology later :-)

                        • 9. Re: Homogenous service connected by ESB

                          I have added my code to sansbox. It shows action class that works with distributed transaction. Please be tolerant, comments should be better. I have not include test case as well.


                          • 10. Re: Homogenous service connected by ESB
                            Mark Little Master

                            Thanks. I'll take a look.