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 1

BizTalk Implementation

Figure 1 shows the BizTalk Orchestration Designer workspace within Visual Studio.Net where a developer would work on a BizTalk process application. The drag-and-drop graphical user interface allows developers to assemble and link visual objects representing messages, messaging events, business rules and logic, information flows, activities, operations, transformations, and subprocesses. Furthermore, built into the function of objects are implementation mechanisms for supporting highly complex transaction processing functions, such as two-phase commit, roll-back, and other ACID properties; state persistence of long-running interactions; nested and parallel operations; compensation and exception mechanisms; acknowledgments; and correlation capabilities. This inclusion minimizes the need to write procedural code. The system can save a completed orchestration diagram as a Visual Studio.Net BizTalk project that in turn generates a compiled run-time assembly of the process application.

Figure 1 shows a workflow process application for the following scenario:

A warehouse inventory order replenishment request is received by the process application.
The process application checks the quantity of items being ordered. If the order contains more than 500 items, it is denied. If the order contains 500 or fewer items, it is accepted.
If the order is declined, a notification is created and sent to the order's originator.
If the order is accepted, the original order request is submitted to an ERP system for processing.

How does BizTalk enable developers to implement a process using SOA and messaging? The first step is to create the schemas for the two document types that the workflow process will receive and send, as well as operate upon: the Request and the ReqDenied documents. This step is accomplished in the Schema Editor, a BizTalk module also accessed from within Visual Studio.Net. The Schema Editor defines the structure and semantic metadata that "declares" the meaning, functions, and processing requirements of the content of a document (an "instance") that is created from the schema.

Consequently, when BizTalk Server receives an instance of a Request document, the associated process validates the document's form and content against its schema definition and the processing requirements of the workflow application. BizTalk Schema Editor creates a W3C-compliant XML Schema Definition (XSD) document as well as a visual tree node reference model of the schema. Figure 2 shows the Schema Editor. The left panel has the tree node model of the document schema, while the right panel displays the XML representation.

If the workflow application described in Figure 2 denies the inventory replenishment request (because it contains a request for more than 500 items), it will generate a denial notification (ReqDenied document) and send it to the originator of the request. The ReqDenied document, which has its own schema definition, acquires information from the Request document, such as the ReqID and Item Quantity data.

Process, Not Code

In conventional programming, procedural code would extract the information from the Request document and write it into the ReqDenied document. Typically, this code would be embedded within a larger monolithic procedural structure. With applications composed of loosely coupled interactions among XML objects, you can see how the paradigm is different. The document "transformation" step becomes a referenced mapping subprocess that is both exposed and functionally isolated from other process steps. BizTalk Server creates this subprocess in BizTalk Mapper — a module for generating extensible stylesheet language transformations (XSLT)-based transformation maps used to convert the content and structure of a source document into a target document. BizTalk Mapper visually displays the source and destination document structures using BizTalk Editor's schema tree node model. BizTalk maps information from one or more nodes in a source schema to one or more nodes in the destination schema by drawing links between the nodes.

In Visual Studio.Net, one or more BizTalk projects comprise a BizTalk Solution (that is, an application). The schemas for the two document types and the transformation map are combined together in a discrete BizTalk project. A "build" of this project compiles an Assembly (a DLL file) that another BizTalk project can reference. The BizTalk orchestration diagram of the workflow process is another discrete BizTalk project within the same Solution. By referencing the Assembly for the schemas and map, the Solution can incorporate them as functional objects.