Business Process Management Technologies

BPM Servers and BizTalk (orchestration) BPEL4WS (modelling & execution) ebXML & RosettaNet (discovery & integration)

Service Oriented Applications

BPM Servers

Communication Services allow an orchestration to interact with the various business services a composite application uses. Eventually, the dominant way to do this will be via SOAP-based web services, and so the communication services built into a BPM server today must include support for web services.

Orchestration Runtime Services Executing an Orchestration Managing an Orchestration’s State Handling Transactions Correlating Requests and Responses Exposing an Orchestration as a Web Service

Orchestration Runtime Services Executing an Orchestration orchestrations are typically defined graphically rather than by code. Diagrams aren’t directly executable so a BPM server must provide some way to translate an orchestration’s graphical depiction into an executable form. One approach is to translate an orchestration diagram into a low-level form, such as Java bytecode or the.NET Framework’s Intermediate Language (IL), then execute it like any other program. Another possibility is to transform the logic represented in the diagram into a process oriented language, then execute the resulting program on a specialized process engine. So as to define web services-based interactions between orchestrations that can be executed on any vendor’s BPM server, a group of vendors including Microsoft, IBM, and others have defined the Business Process Execution Language (BPEL4WS). Now being standardized under the auspices of OASIS, BPEL4WS is an XML-based language for defining interactions via web services. - More Later

Orchestration Runtime Services Managing an Orchestration’s State The long-running nature of a process orchestration affects how an orchestration manages the in-memory information it maintains—the state—about a running process. An orchestration may be blocked for a significant period of time. BPM servers provide a way for an orchestration’s state to be automatically written to disk, then restored again when the business process resumes, even if it’s days or weeks later.

Orchestration Runtime Services Handling (all or nothing) Transactions An orchestration driving a business process might need to invoke two business services and ensure that either both requests succeed or both fail. (Commit & Rollback) Atomic transactions require locking data for the life of the transaction, something that isn’t a problem when the transaction is short. Orchestrations rarely are. BPM servers support long-running transactions, which handle errors not by rolling back all updates, but by executing some kind of compensating logic when an error occurs. An imperfect solution!

Orchestration Runtime Services Correlating Requests and Responses Two orchestrations have sent some information into a service, such as a purchase order, and each is waiting for the same response, such as an invoice. How can the correct response, ‘the matching invoice,’ be delivered to the right orchestration? The request and response messages themselves can contain information that is used to correlate them e.g. a purchase order and its matching invoice, will contain identical purchase order numbers. The creator of an orchestration can indicate which values in the request and response should be used to correlate requests and responses, then automatically route responses to the orchestration instance that made the request.

Orchestration Runtime Services Exposing an Orchestration as a Web Service An orchestration acts as a client of services. By providing the central logic for a business process, it drives the operations that make the process go. Also, an orchestration may be used as a service itself. A BPM server can allow an orchestration to ‘expose itself’ as a web service.

Development Tools Are used to define the orchestration logic that drives a composite application, specifying mappings between data used by various business services, and other purposes. Virtually all of today’s BPM platforms provide graphical tools for creating orchestrations.

Orchestration Designer. (Running inside Microsoft’s Visual Studio)

Orchestration Designer for Business Analysts. Runs inside Microsoft Visio. Diagrams can be imported & exported from & to OD in Visual Studio

The BizTalk Editor provides a graphical approach for creating XML schemas, BizTalk Mapper (shown here) creates definitions of mappings and transformations between fields in the messages defined by those schemas.

Management Tools are used for managing an orchestration, its communications, and other aspects of the BPM server.

Health and Activity Tracking (HAT) tool. Provides a range of management functions, including the ability to display current and historical information about executing orchestrations.

Business Rules Services Rules tend to change more frequently than processes so the business rules an orchestration uses are created and managed separately from the process flow. Business rules are stored in a single place, organized into well defined groups, making reuse of rules easier. Less technical people, such as business analysts, can create and modify rules.

Workflow Services allow people to participate in the business process. On its own, an orchestration typically implements the controlling logic for a business process that executes without human intervention - straight-through processing. A BPM server must support workflow, generally now used to mean human involvement in a business process. some BPM servers have roots in this area, others grew from integration-oriented products and add workflow support on top of their existing technologies.

Process monitoring services including both monitoring at a technical level and business activity monitoring (BAM) that provides real- time information about a running process.

A developer can configure an orchestration to make specific information available to the BAM component. Exposed via a web service, this component can be accessed by Excel or other clients.

Web Services are self-contained, modular business process applications that are based on the industry standard technologies of WSDL (to describe), UDDI (to advertise and syndicate), and SOAP (to communicate). They enable users to connect different components even across organizational boundaries in a platform- and language-independent manner. However, none of these standards allow defining the business semantics of Web services.

BPEL4WS Business Process Execution Language For Web Services (BPEL4WS or BPEL, for short) specifies business processes and how they relate to Web services. BPEL supports the specification of business protocols between partners. A BPEL business process interoperates with the Web services of its partners, whether or not these Web services are implemented based on BPEL.

Web Service Standards

Business Processes and Web Services A BPEL business process specifies the potential execution order of operations from a collection of Web services, the data shared between these Web services, which partners are involved, how they are involved in the business process and joint exception handling for collections of Web services. BPEL combines (and superceeds) IBM's Web Services Flow Language and Microsoft's XLANG specifications.

A simple Business Process

Partners Containers Receive an Itinerary from a Customer Request tickets from Airline Receive tickets from Airline

What Makes Web Services Possible? A fundamental requirement for Web Services is interoperability & consistency across platforms, applications & programming languages requiring: –A common framework for Web service interactions based on open standards. –An agreed set of vocabularies and interactions for specific industries and common functions.

What Makes Web Services Possible? Reliable & Transparent Interconnectivity –Web Protocols Structured Information –XML Schemas & validation Application Interface Standards –UDDI, WSDL, SOAP Business Process Interface Standards –ebXML, RosettaNet

ebXML (electronic business XML) Provides an open framework for global e-commerce Replaces (but is compatible with) EDI Is based on XML and other open standards Specifications: –Business Process –Registry Model and Services –Trading Partner Collaboration –Messaging Services

ebXML Architecture Concepts Business Processes and associated Core Components (in XML) A mechanism for registering and storing them (Registry) A mechanism for describing a Trading Partners capabilities (TPP). A mechanism for describing a Trading Partner Agreement (TPA). A standardized messaging service (ebXML MS) A standardized methodology/process for modeling the real world business and translating it into XML.

Functional Service View (FSV) Architecture

ebXML Architecture in Practice

RosettaNet Is a non-profit consortium of more than 500 industry- recognized organizations which works to create, promote and implement open e-business standards and services that improve efficiencies across the global supply chain. RosettaNet standards prescribe how networked applications interoperate to execute collaborative business process. e.g. RosettaNet Partner Interface Processes (PIPs) are specialized system-to-system XML-based dialogs that define business processes between trading partners. Each PIP specification includes a business document with the vocabulary, and a business process with the choreography of the message dialog.