The enterprise service bus (ESB) is, arguably, emerging as the preeminent platform for building, deploying, and managing Web services. However, once you have created and deployed your Web services, what's the next step? For many developers, it is the orchestration of those services into composite applications and business processes. In the past, this area has proved troublesome. The majority of existing business process tools are vendor specific and proprietary, using adapters and bridges to integrate with open platforms like Web services. However, the emergence of Business Process Execution Language (BPEL), coupled with the growth of Web services and the ESB, is providing a real, native, service-oriented architecture (SOA) based alternative.
This potential was brought home to me when I was working with a high-tech manufacturer who faced the perennial problem of managing old, proprietary software that linked their ERP systems with their partners (primarily contract manufacturers). The existing system was complex, required a lot of maintenance, and was difficult to change. The company identified Web services and SOA as an alternative solution that would enable them to rip out the legacy software while, at the same time, reduce the cost and complexity of linking with their partners.
By adopting a Web services approach, they immediately got cross-platform interoperability, standards-based development, location independence, integration with existing systems, and promotion of future service reuse. They used an ESB to build and deploy the Web services, which provided the necessary policy, transformation, and routing capabilities to enable their services to be exposed. The documents exchanged between the company and its partners were defined in XML; partner interfaces were quickly defined in WSDL.
