Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

October 30, 2003

SOA: The Process Development Paradigm

Leaving software development's dysfunctional legacy behind, service-oriented architecture (SOA) is gathering momentum as the paradigm for developing process management applications. Using Microsoft's BizTalk Server 2004 as an example, here's a look at how SOA works

by Ira Fuchs

Continued from Page 2

BPEL and Web Services

BizTalk enables the creation of a process orchestration diagram through dragging, dropping, and linking object shapes found in the Orchestration Toolbox (displayed on the left side of Figure 1 and Figure 3). These objects are high-level abstractions of business process functionality as defined in the business process execution language (BPEL) specification. BPEL was developed through a collaboration of BEA, IBM, and Microsoft and combines XLANG and Web services flow language, the previous generation of process languages created by Microsoft and IBM, respectively. The BPEL specification's fundamental purpose is to orchestrate Web services so that they can engage in coordinated and collaborative behavior.

BPEL is a precise language and grammar, written in XML schema, that represents business process activities and behavior. A process described in BPEL is a readable and understandable set of instructions that definitively documents process elements, activity, and behavior. I couldn't overstate the value of this documentation: Historically, poor documentation has been a major impediment to modifying and adapting software and processes. The Orchestration Toolbox shapes are direct representations of the basic and structured BPEL elements, such as receive, invoke, sequence, flow, switch, scope, partners, role, link, and source.

By dragging, dropping, and then modifying the following shapes from the Toolbox, developers can diagram process steps using the following steps (see Figure 3):

A Receive shape is placed at the top of the design surface and named Receive_Req.
A Decision shape is placed directly beneath the Receive shape and named CheckQuantity. The Decision shape automatically creates two activity branch shapes (If and Else). The If shape is renamed Decline. The Decline shape is linked to an expression editor in which the expression "RequestInstance.Item.Quantity > 500" is created. This XPath expression will function as the "If" rule that specifies the denial criteria for the order request.
A Construct Message shape is placed below the Decline shape and named Construct_ReqDenied. A Transform shape is placed within the Construct_ReqDenied shape.
A Send shape is placed below the Construct_ReqDenied shape and named Send_ReqDenied.
A Send shape is placed below the Else shape and named Send_ReqToERP.

Once the developer diagrams the abstract process logic, subsequent steps involve linking the shapes to objects that implement the process (for example, the actual message documents and port locations where the messages are sent and received). I will not itemize each individual implementation step here; instead, I will focus on the implementation of the Transform step.

As a subprocess of the Construct_Denied step, the Transform step converts an instance of the Receive_Req document to an instance of the Req_Denied document (schemas for both were specified earlier) by invoking the conversion map, also created earlier. This conversion is accomplished by simply clicking on the Transform shape, which opens the dialog box. Here, document instances are linked to the referenced schemas and conversion map that were encapsulated in an Assembly and referenced earlier by the orchestration project.

In similar fashion, any implementation objects (such as transport mechanisms, document instances, database access procedures, Web services, .Net and COM objects, and other orchestrations) can be bound to the logical process steps within an orchestration. Once all the logical steps are implemented, the build of the orchestration diagram generates a DLL Assembly. The BizTalk run-time engine can then deploy and execute the Assembly as an application.

Object properties within the overall Solution (orchestrations, schemas, maps, instance documents, rule sets, ports, and so on.) are functionally transparent and isolated. They are accessible from within the host VS.Net environment or directly through their XML representation. Furthermore, the completed orchestration can generate a BPEL document of the entire process that includes its implementation references. Not only is the BPEL document readable, any BPEL-compliant execution engine can execute it.

Because the process steps and the implementation mechanisms are loosely coupled, a change in the logical execution of a process does not affect the construction, operation, or integrity of the implementation mechanisms. Conversely, changes to implementation objects won't affect the execution or integrity of the process. The document schemas or conversion map could be modified in almost any respect without having any direct impact on the logical process or any other implementation mechanism.

Rate This Article

Comments:

Optional e-mail address:

A Shift Takes Hold

Process management technology based on the SOA paradigm requires a conceptual reorientation in the methodologies of application development. As with any paradigm shift, its ultimate justification must be the derivation of significant benefits. Already, a large and growing body of evidence shows that users are obtaining dramatic development and life-cycle maintenance efficiencies as well as an accelerated return on investment.

Ira Fuchs [ifuchs@xmlassociates.com] is executive director of the Center for XML and Web Services Technologies at CUNY/QCC in New York City. The Center is an educational and advisory resource for IT professionals that's focused on education about the conceptual underpinnings and practical implementation of these technologies.. ]