Promising process servers ease Web-services integration complexities
See correction at end of review
Breaking down business processes into Web services components was the easy part. Weaving them together into manageable, useful services has proved more ambitious.
XML-based business process languages have emerged to manage these event-driven architectures. Now IBM and Oracle have elevated the standing of BPEL4WS (Business Process Execution Language for Web Services, or BPEL for short), granting the language a seat in the core of both companies’ new process servers: the Oracle BPEL-PM (BPEL Process Manager) 2.0 and the WBISF (WebSphere Business Integration Server Foundation) 5.1.
These servers are designed for coordinating process interaction and event governance using BPEL. The products integrate into the companies’ respective traditional product lines.
For IBM, the integration is a bit clearer. The company has folded WAS (WebSphere Application Server) Enterprise into its WBISF. Although performance was slightly sluggish in my tests, WBISF offers solid capabilities and brings with it a rich variety of resource adaptors to back-end systems and transactional technologies that can’t be beat.
Oracle’s foray into BPEL comes by way of the recent acquisition and rebranding of Collaxa, a pioneer in process management for SOAs (service-oriented architectures). BPEL-PM runs on Oracle’s application server line, but is not tied to it; it supports any J2EE application server, including JBoss and WebSphere. Oracle’s performance was good, but adapter support is light and integration of the product into Oracle’s own stack remains limited.
Each vendor has an Eclipse-based toolset for visually modeling BPEL process flows. Oracle’s BPEL Designer is included with the offering. IBM requires that you purchase its WSAD-IE (WebSphere Studio Application Developer, Integration Edition) 5.1. This add-on sports a number of advanced capabilities and wizards that help compensate for the extra expense.
Both products still have room to grow with regard to improving usability and mitigating complexity. This is an evolving science, to be sure. Yet many of these shortcomings stem from the complexity of XML and the still-ripening state of BPEL more than the underdeveloped status of these products.
As such, I find both vendors here providing smart, solid means of advancing business process integration in a way that includes Web services most fundamentally.
Getting started with Oracle’s BPEL-PM was nearly effortless. With only minor configuration, the refined install routine managed installation of the complete system, including the process engine, visual designer, embedded Oracle Lite Database, and the administration and monitoring console.
IBM’s WBISF was slightly more difficult and time-consuming to piece together before I could get started, requiring a number of tweaks and secondary scripts to be run in order to set up all the components, such as the process choreographer, containers, and queue managers. This is the stuff of which IBM’s consultant-service-based revenue dreams are made.
When configured, WBISF was easy enough to work with. It sports fully functioning versions of the WAS, as well as DB2 Enterprise Edition and WebSphere MQ for use by the process engine.
In both cases, I found the process engines supported advanced BPEL capabilities, including asynchronous message handoff and transaction compensation, which is the rolling back of a transaction to an earlier state due to, for example, a processing error.
Each engine handled dehydration well with a persistent state-management store for long-running transactions. Recovery agents awakened (or rehydrated) my dormant transactions after a specific lapse in time or upon receipt of a completed transaction and moved the process to the next stage.
Via JCA (Java Connector Architecture) adaptors, both products do a good job at extending their reach to orchestrate more than just Web services. The well-integrated support of WBISF extends it to include J2C and WBI application, technology, and mainframe adaptors, such as CICS support, as well. Because Oracle’s acquisition of Collaxa is relatively recent, similar functionality should eventually find its way into BPEL-PM.
I found the BPEL-PM administration console easy to use, allowing me to deploy my BPEL processes, test and debug flows, collect data on transactions, and trace both completed histories and those in progress. I liked the ability to visually inspect a business flow and drill down to the underlying XML that encapsulated my transaction.
BPEL language is wordy and awkward to manage in volume. The process map-design tools from both vendors address the shortcoming, offering good graphical cues and inspectors to streamline setup of processes, partner links, and variables. I was able to quickly construct complex, parallel branching flow logic based on run-time conditions and variables. I was also able to manage the partner services, roles, and port types that were participating in my services interactions without ever touching XML directly.
In general, the tools were smart enough to promote efficiency and build maps directly from my WSDL data. Building exception-handling into design was also easy.
I found both tools allowed good XML manipulation: Oracle by way of a visual XPath Editor, and IBM with a graphical WSDL editor and XSLT mapper.
WSAD-IE has user tasks that can be added to integrate the human element of a transaction -- although workflow is not yet part of the BPEL specification -- and has even adopted good provisions for directory services to enhance form routing and approval, for example.
Pop and hiss
I experienced some interface difficulty with the WSAD-IE designer, such as the inability to scroll a zoomed-in process map. Additionally, I was unable to print my flow diagrams from the WSAD-IE interface, which is an absolute necessity because working in the graphical interface can quickly become unwieldy during complex flows. There was too much paging back and forth with unreadable icon tags.
BPEL-PM would benefit from sprucing up its XML source editor by adding tools to streamline productivity, such as source code completion, and by providing a more developer-friendly environment.
Analytics, too, still need some work. Although I was able to extrapolate basics from BPEL-PM, such as time to completion of a process, I would like to see more advanced analytics eventually built into the tools to sift metrics and improve decision-making abilities.
In all, these packages continue to be mired in complexity, making them too green to let business analysts in on the process. Integrating business processes remains a systems integrator’s game.
But BPEL-PM has come a long way from the first time I looked at Collaxa’s scripted ScenarioBean approach back in 2002. And, for IBM, the addition of the Process Choreographer to its application server architecture is a sign of its continued commitment to BPEL.
Both of these products represent the existing cream-of-the-crop for SOA transactional process integration, and it would serve you well to take a look at the future of collaborative business process management.
This review should originally have stated that IBM has folded WAS (WebSphere Application Server) Enterprise into WBISF (WebSphere Business Integration Server Foundation) 5.1. The error has been corrected.
Developer tools (20.0%)
Overall Score (100%)
|IBM WebSphere Business Integration Server Foundation 5.1||8.0||9.0||7.0||8.0||7.0||9.0|
|Oracle BPEL Process Manager 2.0||9.0||8.0||8.0||9.0||9.0||7.0|
This weekend's Windows 10 upgrade has users angry, and it's unclear if the ploy will continue
Here’s the best of the best for Windows 10. Sometimes good things come in free packages
Speaking at the O'Reilly Fluent conference, Eich also endorsed the Service Workers mobile app...
Sponsored by Intel
Spoiler alert: There probably isn't. But that shouldn't cause anyone to panic aside from Wall Street...
Oracle says Java EE 8 will be equipped for cloud deployments, microservices, containers, and...
IoT will soon permeate every aspect of our lives -- the very definition of sprawl. How will we derive...
Git was made for distributed teams, but long distances introduce special challenges