This isn't necessarily ColdFusion related, but what I want to discuss in this post does have the potential to impact how we as ColdFusion developers think about our applications. I'm going to ramble a bit here as I've got a lot of thoughts floating around in my head, and I want to get this out without all of the structure I usually put around my writing.

I just finished a three day proof of technology lab with IBM where we explored their soon to be released WPS (WebSphere Process Server 6.0). It was three days of serious acronym overload coupled with lots of hands on work with their WebSphere Business Modeler and WID (WebSphere Integration Developer) tools, both of which are built on the Eclipse platform.

I'm sure you've all head of Service Oriented Architecture (SOA) by now. It's a term that's been around for a few years, the idea being that you can assemble entire systems from components. Actually, SOA isn't really that new at all. It has roots in CORBA, DCOM, RMI, and other distributed computing technologies. These days, SOA tends to be associated with Web Services. It's important to note, though, that SOA does not equal Web Services. Web Services are but one way you can create a SOA.

Most organizations get their start with SOA by isolating discreet functionality within monolithic applications, decoupling it, and exposing it as a service (most often as a Web Service). The end result is a bunch of services scattered around the enterprise. The next step in the evolution of SOA tends to be an attempt to cobble together two or more services to construct crude processes. The problems with this approach become evident almost immediately. As the number of services grows, it becomes increasingly difficult to find them within an organization. For the discovery problem, we have UDDI (Universal Description, Discovery and Integration protocol), which allows us to catalog Web Services for search and discovery. Depending on whom you talk to, or which vendor's implementation of UDDI you have, your mileage may vary.

An even larger problem is that there's no easy way to choreograph services into a coherent process, let alone ensure reliability or continuity. This is where the WebSphere Process Server comes in. Simply put, it's a server based technology that provides a single programming model for SOA. It allows you to automate business processes by visually describing workflow that includes both automated services and human tasks. It adds support for transactions, exception handling, escalations, etc. to your services based workflow. The server uses WS-BPEL (Web Services-Business Process Execution Language), an XML based language, to model and describe business processes.

What was really cool for me was to see how (relatively) simple IBM has made it to model a business process using WebSphere Process Modeler, export that model as UML, BPEL, or several other formats, then import that process into the WebSphere Integration Developer tool where the model can be further developed into a composite J2EE application, tested, and even deployed to a WebSphere Process Server. Model Driven Architecture (MDA) is gaining traction these days, and with tools like this, I can understand why. With training, a business analyst could be taught to model a business process using the WebSphere tool. That model then serves as the foundation for the integration developer, cutting down on the amount of time the developer needs to spend trying to flesh out the actual business process. The WebSphere tool goes one better than using a tool like Visio because it allows you to easily export your model for use in other tools.

"Development" within WID can be done entirely without code via sophisticated design and mapping tools. The beauty here is that the majority of the real coding happens at the service level. That is, those creating the services you are going to consume are the ones doing the heavy duty coding the integration developer is more an expert with the tool. Having knowledge of Java is helpful and certainly allows you to do more with the tool, but it's by no means necessary.

I can't stress enough how tools like this enable enterprises to become more productive by focusing on tool based solutions rather than custom coded applications. The tooling surrounding BPEL in the WebSphere tools is amazing. This doesn't replace the need for skilled developers, but it does solve one of the major problems facing organizations trying to implement SOA – how to cobble together services into solid business processes.

One other interesting note from the lab is IBM's entry into the Enterprise Service Bus (ESB) product space with their WebSphere ESB Server. In simple terms, ESB is middleware that integrates applications, data, and services using a variety of protocols. Until now, IBM has strictly maintained that ESB was an implementation of a pattern and not a product, and has positioned several products around the ESB concept. This, however, didn't stop several other vendors from creating unified products around the notion of ESB. I believe IBM felt the pressure from both the industry and their clients to consolidate their products and fully productize ESB, which lead to the creation of their WebSphere ESB product.