Application Server Architecture and BPEL
Promises and challenges
By: Amlan Debnath
Jul. 2, 2004 12:00 AM
In recent years the application server has greatly evolved, expanding the set of core services provided by the infrastructure. The current Java platform supports XML data handling, scalability, load balancing, and other capabilities that allow application-level services to be developed more easily and deployed more reliably. This progression must now address developers' latest concerns regarding security, distributed transactions, and reliable messaging because applications no longer stand alone - they're deployed into a technology ecosystem that can span departmental and organizational boundaries.
In this environment, a well-behaved application not only needs to interact with external systems and consume services from them, but also needs to be a service provider. This is driven by a need for reuse and adaptability and fuels the current push toward services-oriented architectures (SOA).
However, this leads to the question: How do we get all these services to work together in a heterogeneous, networked environment? The answer is BPEL, the Business Process Execution Language for Web Services. BPEL provides a standard, portable language for orchestrating services into end-to-end business processes and builds upon a decade of progress in the areas of business process management, workflow, and integration technologies. It's built from the ground up around XML and Web services and is supported on both the Microsoft .NET and Java platforms.
What does BPEL add to the existing Web services standards and Java platform? It's clear that the industry must have been hungry for BPEL, given the support it has received from nearly every major technology vendor in the past year - but why? The first driving force is the new class of connected applications, which makes implementing business processes a mainstream problem that most developers must tackle. Surely a second factor was the alphabet soup of earlier proprietary workflow languages, which slowed their adoption and created a standards vacuum that BPEL fit perfectly. And finally, Web services have accelerated the process by providing a standard interface for publishing services and requiring a shift in the way service composition is done. BPEL, then, is just what the doctor ordered. The emergence of BPEL as a standard for describing business processes is a step in the evolution of the application platform (see Figure 1).
Aligning with this shift, many of the major technology vendors in both the Java and .NET camps have announced that they will ship BPEL engines in the future, so why are so few commercially available today? It turns out that the maturity of BPEL as a process language makes it feature rich but complicates the process of building a scalable, reliable BPEL engine. For example, BPEL is designed with asynchronous services at its core, but this means that servers must deal effectively with persisting state for long-running flows, correlating asynchronous messages, and reliably handling the case where an outbound message has been sent but the server crashes before the response is received. The rest of this article examines how these requirements, and the new standards to support them, naturally extend both the Web services standards and the current Java platform.
To make this discussion more interesting - and more comprehensible - let's consider a real-world example: an order management process at a large hardware manufacturer. This manufacturer accepts wholesale orders from many different sources and responds immediately with an order tracking number, but has a long-running flow in the back end to process and track the order and call the client back when an invoice is ready.
As shown in Figure 2, this flow needs to invoke synchronous services, such as looking up payment terms in an Oracle Financials package, as well as asynchronous services, such as submitting the order to a mainframe system, which will compute the invoice as part of a batch process. XML data is exchanged between all the systems and the manufacturer must process millions of these transactions a day at peak loads—tracking them, reporting on them, and handling exceptions, notifications, and manual processing steps as needed.
This process is a typical example of the new class of requirements that developers must address when developing SOA-based applications, including:
Some of the key standards that are being implemented in J2EE application servers around this area include the following.
Extensible WSDL Binding Framework (JSR-208)
Process Flow Coordination (BPEL)
Reliable Web Messaging (WS-Reliability)
XML Data and Transformation (JAXB, XQuery)
User Interactivity (WSRP)
Choreography and Contracts (WS-CDL)
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week