In an ESB, you can have one end-point exposed which receives a request, and calls several downstream services. For example, the end-point provided by the ESB could be "ProcessOrder". A WAS server could host an Internet site that is a shopping boutique. A customer can add several items to his or her cart. When done shopping, the customer fills in payment details and submits. The WAS server then calls the ESB "ProcessOrder" service. ProcessOrder can do several things, like validate the credit card with the CC network, tokenize the payment details in support of PCI controls, establish warehouse pick-pack-ship actions, etc. Eventually the ESB returns a "thumbs-up" or "thumbs-down" to WAS.
There is a fine line between service aggregation done in an ESB and Business Process Service Orchestration. A business process that would be more likely to adopt BPEL would be a life insurance service underwriting function. ESB would fit underneath the BPEL product, actually responsible for making the down-stream calls to various service providers on behalf of the BPEL product. Managers who do not understand how the component parts of SOA fit together should not embark on an IT infrastructure modernization effort lightly. It takes more than casual knowledge to be successful in SOA. You have to have the insight, skill and expertise to determine when to use a BPEL product and when to implement an aggregate service in an ESB. You also have to be skilled in Web Services. Queues are nice and have their place, but Web Services are absolutely essential to the long-term success of any SOA implementation.
We noticed he had no friends. So we gave him this tiny ad:
a bit of art, as a gift, that will fit in a stocking