Flylib.com

Books Software

 
 
 

Developing Enterprise Web Services: An Architects Guide: An Architects Guide - page 62


Summary

Workflow is a technique of managing the coordination of resources over time in some business process, ensuring the right resources (people, materials) are in the right place (manufacturing facility, database) at the right time (inventory, just-in-time). With the advent of Web services as the likely means of tying enterprises together in the future, the prospect of creating truly virtual enterprises may become a reality. There is a real requirement for the development of workflow technologies that can bridge enterprises using the underlying Web services-based network as a basis. The current leader in this field, in terms of both heritage and implementation support, is BPEL.

The BPEL model logically consists of two distinct components . The first is a process description language with support for performing computation, synchronous and asynchronous operation invocations, control-flow patterns, structured error handling, and saga-based long-running business transactions. The second is an infrastructure layer that builds on WSDL to capture the relationships between enterprises and processes over a Web services-based infrastructure. Together these two layers allow the orchestration of Web services in a business process where the infrastructure layer exposes Web services to the process layer, which then drives the Web services infrastructure as part of its workflow activities.

The ultimate goal of business process languages is to completely abstract underlying Web services so that a business process language such as BPEL effectively becomes the Web services API. While such an abstract language may not be suitable for every possible Web services-based scenario, it will certainly be useful for many. If tool support evolves, it will be able to deliver on its ambition to provide a business analyst-friendly interface with which to choreograph enterprise Web services.


Architect's Notes

  • BPEL is set to be the dominant Web services choreography language. It may change over time as standards in the area mature, but given the fact that it is a second generation effort, it is more immune to change than the other first-generation contenders in this area.

  • Developing BPEL workflows by hand is difficult and error-prone . Tool support is essential, especially if control of mission-critical workflows is to be given to non-specialist programmers. Writing code in XML does not magically make it simple.

  • If you are modeling an existing process with a view to automation, approach development in three stages. First understand your algorithm (that is, the necessary activities and the control flow dependencies). Then decompose the relationships between your enterprise and your partners into BPEL-friendly interface code ( partners , serviceLinks and so forth). Finally, progress to connecting your workflow to your partner's services.

  • If you are starting from a blank slate, it might be more useful to start from your partner interrelations and work "inward" toward your process script.

  • BPEL will be the "API" for business analysts developing and deploying workflows into enterprises .


Chapter 7. Transactions

Transactions are a fundamental abstraction in dependable computing systems. Put simply, a transaction is a unit of work which either succeeds completely or fails without leaving any side effects. To illustrate , a commonly cited example of a transaction use-case is where an amount of money is to be moved between bank accounts. In this case the goal is to ensure that the money both leaves the sender's account and is received by the recipient's account, or if something fails, for it to appear as if the transaction itself logically never occurred .

This is the inherent value of transactional systems; if something goes wrong, they allow us as programmers to make it appear as if it never happened in the first place. In an inherently unreliable world, transactions can truly be a godsend, especially when we consider the amount of computing infrastructure involved in something apparently as simple as moving money between accounts. Any aspect of that computing system from the network cables through to the software and everything in between has a small yet significant chance of failing -something we'd rather it didn't do while it's processing our money! The point is that using transactions to safeguard against failures allows us to reverse any partial work performed during a failed transaction and, thus, prevent our money from disappearing into a banking black hole.