Yes, I know it's corny, but I've had a few things on my mind regarding service-oriented architecture, component-based development, and even the infamous enterprise service bus. (Hey, at least the title isn't "Get on the Bus"). All of these have something to do with Web services. None of them are "Web services," at least not entirely. And yes, you guessed it, they're all part of this month's focus

So what's the difference between SOA, ESB, and Web services? For starters, Web services is mainly about technology. Service-oriented architecture is mainly about design (although it has to be based on some technology, and Web services is a very good fit for SOA). Enterprise service bus is halfway between technology and design, and focuses on the transmission of messages between applications within an enterprise. Sometimes it uses Web services, but just as often you see people talking about ESB while speaking of protocols such as JMS, without the use of WSDL or UDDI, or even XML.

The enterprise service bus concept hinges on the passing of messages, so it's not surprising that the leading message service software providers are the strongest advocates of an enterprise service bus. It ties into Web services in the sense that Web services provide the ideal API layer for describing messages without binding them to a particular transport (that gets done under the covers by the messaging software, of course). Frequently, ESB discussions will also include some form of business process management product, either a true BPM capability, a workflow engine, or even some sort of sophisticated routing and tracking mechanism. Or even a combination of all of the above.

Enterprise service bus concepts diverge from Web services in that they don't truly adopt the Web services standards throughout, and they have a message-centric approach to interaction that largely rules out the RPC style of communication that is also a part of Web services. You'll see the use of WSDL, but perhaps not SOAP. You may see BPEL, or you may see some proprietary BPM tool. You probably won't see WS-Transaction, or WS-Orchestration. A lot depends on the vendor. As I said, it's a similar idea, but it's not quite Web services.

Service-oriented architecture is even more divergent from Web services. In theory, you could create an SOA without any Web services technology. In fact, that's been done several times, with technologies such as DCE and CORBA. Service-oriented architecture is about software design centered on services. The goal is to reduce redundancy, increase software reuse, and loosely couple applications (the things the end user interacts with) to services (the things programs and computers interact with). SOA is not nearly as focused on interoperability and intercommunication, except as needed by the enterprise. For example, in an all Java shop there's no need to do SOAP and WSDL. Granted, those shops are few and far between - it's much more common to have a mixed environment, which usually leads to the adoption of Web services as the underlying technologies for implementation of a service-oriented architecture.

Service-oriented architecture provides an overall design philosophy that can be layered on top of Web services, to the benefit of all users. It leverages best practices and experiences from past attempts at distributed computing, and integrates the technologies of Web services into an overall design methodology that can be employed at the enterprise level.

Component-based development is the concept of assembling applications from pre-designed components rather than monolithic programs, or even from objects. Remarkably similar to the concept of services, but with the limitation of being bound to a particular platform, and possibly even language. In many cases, components can become the building blocks from which Web services are created.

So they all tie together in a nice little package. Build your components, put a Web services interface on them. Create the services based on a service-oriented architecture and utilize an enterprise service bus to ensure communication. Add water, stir, and simmer for several hours. Then let cool and serve.