The article is "A quick intro to WebSphere Business Process Management."
As you know, IBM has disseminated a flurry of SOA announcements. We're educating management about SOA, talking about the new SOA products, the new SOA programming model, and so on. But does it all really fit together? And if so, how?
I'm pleased to say that our various SOA marketing messages fit together surprisingly well. Whereas each message tends to be a discussion aimed at a horizontal level of a customer's organization--such as management, architects, or developers--this article takes a vertical spike through it to show how it all fits together--from enterprise goals to implementation details. The article doesn't have all the details; that's in the other materials; the article just reviews the major points. But in doing so, you start to see the same points in the different levels, and hopefully how they fit together.
I hit four main points:
- What (we're saying) SOA is -- Why does an enterprise need SOA?
- Our SOA reference architecture -- What you need to do SOA
- WebSphere Process Server -- Provides the main features specified in the ref arch
- Service component architecture -- Implement components that use the WPS features
SOA reference architecture
For example, take workflow: You see that SOA needs business service choreography, that the ref arch calls for process services, that WPS provides a BPEL business process component, and that an SCA (in WPS) can be implemented as a BPEL business process. So a BPEL service component maps directly back to one of the main requirements for SOA, service choreography.
Likewise, take ESB: The parts of an SOA composite application can be integrated much more easily using an ESB, which is central to the ref arch, and WESB is the foundation for WPS. (A detail that the article doesn't get into is that ESB mediations are also SCA components in WID/WESB/WPS.)
So hopefully you can see how it all carries through, from what we're telling your management, to those of you who are architects, to you developers. It even carries through to the business analysts; with SOA, the way you model your business is also the way you should model your apps.
Pretty neat, huh? (I hope you agree.) So check out the article.