Mariano Benitez of BEA (part of the original Fuego team that built what is now ALBPM) and Bhaskar Rayavaram of Bear Stearns (who was with Fuego before joining Bear Stearns) presented a unified view of BPM and SOA.
Benitez started with some pretty basic stuff about how BPM consumes services, either system-level or presentation-level, and how services can be introspected for easy integration. He then discussed ALBPM as producing services, that is, it can create services that can be consumed by other applications. This was much more interesting and comprehensive; however, overly dense with jargon and acronyms, and obviously dependent on us having attended the session immediately prior in that track (which I didn’t). There’s a number of mechanisms for producing services using ALBPM:
- Web service front-end to a small set of process API (PAPI) functionality, such as instantiating processes, that’s part of Workspace; it appears that all PAPI-based web services use a common WSDL that expose the methods of PAPI.
- Process web services, which are similar to the PAPI web services in functionality, but are implemented in the execution engine rather than Workspace. This can only be used to create instances and send notifications, but is designed as part of the process and provides a unique WSDL for each process.
- Extended web services, which provides a component-level service; obviously I’m missing some key piece of information because I really have no idea what he’s talking about here. 🙂
- HTML API framework (formerly WAPI), which allows for the creation of simple HTML forms that can be called as services in order to call Workspace operations.
- JSR168 portlets, to provide portlet functionality to render Workspace operations.
- And if you really want to beat yourself up, you can create plain Java wrappers for PAPI in order to create custom services, or JMS for asynchronous services.
All of this reinforces my impression that BEA’s BPM product focus is still too much on hard-core developers — the same ones that are writing services at the SOA level — and not enough on the business side. If I think about this morning’s presentation by PG&E, he placed BPM on the IT side of the house, with a process modelling layer as being the business side’s participation point. Whatever happened to that lovely zero-code BPM that I saw in Fuego?
Rayavaram talked about how Bear Stearns is using BPM in an SOA environment: how processes identify candidates for service enablement, rather than implementing services then looking for processes that might use them. They’re also accessing Fair Isaac’s Blaze business rules management system via web services calls from the processes. They have a loose coupling of processes and services, with services deployed separately now but with a view to migrating to an ESB and a full event-driven architecture.
Sandy, thanks for your report on my session, I would like to share with you my comments on it, I wrote them in my blog.
Thanks Mariano. It was great to meet you in Atlanta, and I appreciate your follow-up comments in your blog.
Although I agree with you that BPM tools are targeted at multiple audiences spanning both business and IT, I find that BEA’s offering (and I’m not sure whether it’s the technology itself or the marketing spin) is more clearly aimed at IT — even parts that I think should be creeping into the business side of the house. I made a comment in <a href=”https://www.column2.com/2007/05/beaparticipate-and-tucon-wrapups/” rel=”nofollow”>my wrap-up post</a>, where I reviewed both the TIBCO and BEA conferences since I attended them back to back, which I feel holds true for your session and others that I attended:
“Since both of these vendors are from the more technical integration space, and gained their BPM products by fairly recent acquisitions rather than organic growth (Staffware in the case of TIBCO, and Fuego in the case of BEA), the conferences were still quite focussed on technical rather than business attendees.”