1.

Create the documents involved in the application/process as well as their respective schema definitions.

This is accomplished in the Schema Editor, a BizTalk Server module accessed from within Visual Studio .NET. The Schema Editor enables you to define 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. When BizTalk Server receives an instance of a document, the process to which the document is associated validates the document content against its schema definition to ensure the document’s form and content conform to the schema and the application’s processing requirements. BizTalk Server Schema Editor creates a W3C-compliant XSD document as well as a visual tree node reference model of the schema.

Following is an example of the Schema Editor that shows the tree node model of the schema in the left panel and the XML representation of the document schema in the right panel.

2.

Create and define the transformation requirements for any document interchanges.

In applications that are composed of loosely coupled interactions between XML objects, document transformation becomes a functionally exposed mapping subprocess. In BizTalk Server this subprocess is created in BizTalk Server Mapper. The transformation maps are used to process and convert the content and structure of any source information (based on its schema representation) into any target document format, such as a report. BizTalk Server Mapper visually displays the source and destination information formats using the schema tree node model used by BizTalk Schema Editor. Information is mapped from one or more nodes in a source schema to one or more nodes in the destination schema by drawing links between the nodes. Functoids, which provide additional conversion, processing, and abstraction capabilities (looping, cumulative, date and time, iteration, and so forth), are graphically implemented by linking one or more source nodes to a functoid, and then linking the functoid to one or more destination nodes.

Each transformation map (as well as the referenced source and target schemas) becomes a BizTalk Server project resource that is subsequently embedded into an orchestration as a process step and compiled into the orchestration assembly. Maps can be reused and modified as needed to implement any number of transformation requirements and they be deployed within any number of orchestrations. The maps created by BizTalk Server Mapper are based on XSLT, an open standards protocol for transforming XML information.

3.

Specify the business logic governing event execution.

If the business logic is simple, it can be embedded as an expression directly within a BizTalk Server orchestration decision step. If the business logic is complex, the BizTalk Server Rules Composer can be used to create and process the sophisticated rule sets. Each rule set (or “Policy”) drives a specific activity or function and becomes a resource object embedded into a BizTalk Server orchestration.

Consistent with the overall BizTalk Server architecture, transparency and loose coupling govern the creation and implementation of business rules. A rule set incorporated within a BizTalk Server orchestration can be viewed, modified, or completely replaced both at design and run time, without affecting any other process operation or interrupting running instances of the affected process. The flexibility that an exposed and componentized rule engine provides for modifying business processes is of fundamental significance. In conventional application development, business rule logic is embedded in procedural code and is not accessible for modification without changing the code itself. Because most modifications to a business process life cycle pertain to changes in business rules (as opposed to technology-related modifications), the ability to isolate business rules entirely from procedural code, or any process implementation mechanisms, dramatically improves the efficiencies of managing and adapting business processes throughout their life cycle.

BizTalk Server Rules Composer supports the creation of domain-specific vocabularies for defining business rules, and its functionality is exposed through public interfaces, making it extremely flexible and extensible. The following is an illustration of the BizTalk Server Rules Composer module.

4.

Determine and implement requirements for message preprocessing and post-processing.

This is accomplished in the BizTalk Server Pipeline Designer module. Accessed through the BizTalk Server orchestration workspace, the Pipeline Designer module is used to implement the interchange requirements for encryption, authentication, and data format conversion with external applications and parties.

A pipeline is a sequence of processing operations that take place before a message is received by, or dispatched from a process orchestration or message data store. A “receive pipeline” accepts an incoming message, decrypts or decompresses it as required, disassembles the message into its parts, converts it into an XML document as specified in the BizTalk Server Schema, validates the message, and authenticates the identity of its sender. When a message passes through a pipeline, it is transferred to the BizTalk Server MessageBox store. A “send pipeline” performs the same operations as the “receive pipeline,” but in reverse. It assembles, formats, encrypts, compresses, and digitally signs a message as required by the external recipient.

5.

Compose and orchestrate the application/process steps.

This takes place in BizTalk Server Orchestration Designer, the main workspace within Visual Studio .NET where an overall BizTalk Server application is developed and implemented. A process orchestration diagram is created by dragging and dropping object shapes found on the Orchestration Toolbox and linking them together. These shapes represent process activities such as receive, invoke, sequence, flow, link, and source. These shapes are used to compose and execute message flows, messaging events, business rules, activities, operations, transformations, and subprocesses.

The following figure illustrates a BizTalk Server orchestration diagram that implements the following workflow process steps:

Composing the illustrated process diagram involved dragging and dropping the following shapes from the Toolbox and then modifying them:

6.

Link the design shapes to implementation objects.

When the process steps are diagrammed, the next step involves linking the shapes to the objects required to implement the process. The objects may include the actual message documents, port locations where the messages are sent and received, and transport mechanisms required to move the messages. This linking stage is also performed in the Orchestration Designer.

In the sample orchestration diagram, when a running process receives an instance of a Request document (note the Receive shape that initiates the process), the process will validate the document’s content against its schema definition to ensure the document’s form and content conform to the schema and the application’s processing requirements. If the Request document does not conform, the Transform subprocess embedded in the Construct Message process references an XSLT transformation map that converts the Request document to a ReqDenied document, as described in the second step.

7.

Where applicable, define parties and their respective roles and link to orchestration functions.

This is accomplished in BizTalk Server Explorer, a tool that provides configuration information for the orchestrations and external components that make up a specific BizTalk Server project. Organized in a hierarchical tree structure, Explorer is used to configure the relationships and interactions of the project orchestrations to other project components such as roles, parties, send and receive ports, and receive locations.

After all the logical steps are implemented in an orchestration diagram, a Visual Studio .NET run-time assembly (DLL file) is generated from a “build” of the orchestration diagram. This assembly may be implemented as an application on its own, or included as a component of a larger BizTalk Server solution.

A BizTalk Server solution (a process application) includes one or more Visual Studio .NET projects that contain BizTalk Server components such as schemas, orchestrations, transformation maps, and pipelines. From the example discussed earlier, the schemas for the Request and ReqDenied documents and the transformation map are combined in a discrete BizTalk Server project that builds a compiled assembly.

The BizTalk Server orchestration diagram that details the process workflow is also a discrete BizTalk Server project within the same solution. By referencing (encapsulating) the schema and map assembly, the diagram can incorporate the schemas and map as functional objects. All of the BizTalk Server project assemblies for a solution are then deployed and installed as an executable application under the management of the BizTalk Server run-time engine.

The SOAP client and listener applications are simple constructs. A SOAP client can be easily embedded as a routine in any program or Web page, and the URL endpoint can serve as the SOAP listener.

By using HTTP as its transport mechanism, a SOAP message can go anywhere, use existing SSL facilities for authentication and encryption, and make the most of the infrastructure scale of the World Wide Web.

Everything in the message, the SOAP envelope, the message header, and the body is expressed in XML, thus making the whole object entirely transparent. Because the semantics and structure of the documents are fully exposed, extensive validation, manipulation, routing, and transformation functions can be applied to the documents without writing application code to do so. Unlike CORBA, a Web services network endpoint (an HTTP, URL, or other address) can support multiple XML formats, providing a real polymorphic interface that will not break down with new versions.

Because HTTP is one of the transport mechanisms used by SOAP, a Web Service method call can be made to and from any Web-enabled computer anywhere in the world. Consequently SOAP has the potential to construct distributed computing processes on the same massive scale as the World Wide Web.