Posted by johnreynolds
on April 21, 2005 at 8:27 PM PDT
PD4J didn't turn out to be all that I had hoped for, but I still believe in (Business) Process Driven Design, and JBI might be the next driver.
I am a big advocate for Process Driven Design. I was disappointed that PD4J didnâ€™t turn out to be all that I had hoped for , but I still believe in (Business) Process Driven Design as the key for delivering solutions that are good for both business users and IT departments.
People tend to focus on details. If you approach someone and ask them how to improve an application, they will most likely point out some detail of the application that bugs them. Maybe they have to look at two screens to get all the data that they need:
â€œCould you combine those fields on a single screen?â€
There is nothing wrong with requests like this, but I think the way we deal with these requests is at the heart of softwareâ€™s complexity spiral.
We have to keep in mind the Big Pictureâ€¦ or more precisely the Big Process. The request: â€œCould you combine those fields on a single screen?â€ needs interpretation:
The design of the current screens does not match the Process that the user is engaged in.
When we are asked to make a change to an application, no matter how seemingly trivial, we should evaluate that change in terms of how it will impact the processes that are being aided by the application. Some applications, like wizards, are clearly the embodiment of processes, but others, like your email application, arenâ€™t so clear (especially when email is an integral part of many of your business processes ).
Process Driven Design begins and ends with the process the business wants to accomplish. At each step of design and implementation there is a conscious link between the details and â€œwhyâ€. The answer to: â€œWhy are the fields on two screens instead of oneâ€ should be traceable from the code that implements the screens to the process(es) for which the screens were created.
One of the great things about Process Driven Design is that the requirements phase transitions smoothly into the implementation phase and visa-versa. The business process diagrams, whether UML activity diagrams or process flow diagram, insure that both the users and the developers agree on the big picture. The relationship between implementation details and the big picture requirements are more apparent, making it easier to answer implementation questions. As a bonus, itâ€™s also easier to see the ramifications of changing requirements.
Process Driven Design canâ€™t really succeed without a tailored infrastructure to support it. We need an â€œoperating systemâ€ that portrays the underlying environment as â€œprocess friendlyâ€.
Providing a â€œprocess friendlyâ€ environment is where Service Oriented Architectures come in. Services perform the individual tasks that make up each process. The middleware that routes messages to services, and which enforces loose coupling between those services functions as the â€œoperating systemâ€. One term that is gaining acceptance for these â€œprocess friendly operating systemsâ€ is Enterprise Service Bus (ESB).
So now we have Services and an ESB to expose them for use. The next piece we need is a Process Engine.
Java is a general purpose language suited to a wide variety of tasks. Normally thatâ€™s a good thing, but to keep things clear we need languages tailored for the task. Thatâ€™s where BPEL and UML Activity diagrams come in. Pictures and words together can more effectively define a process then words alone. A Process Engine executes process definitions.
Due to events in the industry beyond the JCP, PD4J morphed into BPELJ. BPELJ provides the specification for implementing a process engine. The â€œnice thingâ€ about BPELJ is that is allows you to combine â€œWeb Servicesâ€ and Java based services in the same process. I donâ€™t like BPELJ because I consider it to be messy to mix BPEL and Java, and the approach is a half-measure (What about C# or COBOL services?).
ESB (Enterprise Service Bus) proponents take a different approach. Instead of modifying the process language to accommodate specific languages, adapters are created to connect between services and the middleware infrastructure. In Java-based ESBs, these connectors are usually implemented using JCA (the J2EE Connector Architecture) and messaging within the ESB is handled via JMS (Java Messaging Service).
The JBI (Java Business Integration ) specification is the closest thing we have to a "standard Java ESB".
JBI combines "pluggable SOA Integration components with a SOA infrastructure layer, JSR 208 provides the essential building block for implementing a standards-based ESB. It also paves the path for Java middleware vendors to leverage emerging technologies such as BPEL in their ESB offerings using consistent, standard interfaces ."
It's too early to tell if JBI is going to catch on, but I'm very hopeful. PD4J and JBI may not be perfect, but they're getting us closer to an infrastructure where Process Driven Design can thrive.
Update: Here's a good article by Shyam Kumar Doddavula and Sandeep Karamongikar
on the elements of frameworks that support SOA .