BizTalk: Implement Design Patterns for Business Rules with Orchestration Designer
sTopic = oDOM.selectSingleNode(".//topic").Text If sTopic <> "" Then 'Dispatcher ACTS as a factory method pattern as well If sTopic = "BizTalk" Then Set oDispatchable = CreateObject("BizTalkPatterns.ConcreteDispatchable") Call oDispatchable.Execute(sXML) ElseIf sTopic = "MSMQ" Then 'and so on... 'Set oDispatchable = CreateObject("...")
Other BizTalk-friendly Patterns
Two other database-friendly patterns worth mentioning are the Interface pattern and the Factory Method pattern. Although the Interface pattern is a simple design pattern, using interfaces in an environment such as BizTalk is extremely useful. In keeping with using patterns that exhibit loosely coupled aspects, using an interface to all components abstracts the caller from changes to the implementation of the component implementing the interface. This increases the robustness of the architecture and may eliminate unnecessary recompilations in Visual Basic as well as provide a contract upon which to build further implementations using that same interface.
The Dispatcher pattern in our example demonstrated another well-known design pattern that uses a single method as the factory or creator of other objects. This Factory Method pattern isolates the caller from knowing the complexities of instantiating and initializing other worker components in the system. This comes in handy when dealing with external systems where coupling external components in each BizTalk Orchestration would violate its loosely coupled design.
But what does all this have to do with BizTalk? Well, let's see.
BizTalk and the Orchestration Designer
BizTalk is made up of many elements, including the Orchestration Designer which we used to orchestrate the components in our sample. The Orchestration Designer is one of the most powerful and flexible features of BizTalk. Misusing it is also one of the easiest ways to turn a bad design into a bad solution.
Communicating to a BizTalk server implementation simply means using XML as the message format. As you may already know, BizTalk is completely structured around XML and uses a SOAP 1.1 XML message format. The BizTalk-friendly XML message is nothing more than a SOAP 1.1 XML message with additional biztags to comply with the BizTalk Framework specification.
BizTalk Server 2000 is the Microsoft implementation of the BizTalk framework specification. While BizTalk Server happens to run on a Windows® 2000 platform, the framework specification is implementation-agnostic. Any language could be used to implement a BizTalk server as long as it complies with the framework. This provides one of the most powerful features of BizTalk. A message could be sent to a BizTalk server (known as reliable messaging in BizTalk Server 2000) from anywhere as long as it's a well-formed and valid BizTalk message (see the BizTalk Framework 1.0 for details at https://www.biztalk.org). A BizTalk message can be received by an Active Server Page or message queue and forwarded to a running BizTalk server via BizTalk Messaging Manager. A message may even be sent directly to a compiled BizTalk Orchestration schedule. But where do you implement complex logic after a BizTalk server gets its hands on the message? This is where the Orchestration Designer comes in.
The BizTalk Orchestration Designer is a Microsoft Visio® 2000-based design tool that, when compiled, can run as an XLANG schedule. XLANG itself is described through XML (view a compiled schedule in Notepad and see for yourself). The designer provides a high-level means of orchestrating a middleware system's moving parts. Those moving parts can take the form of a message queue, COM component, BizTalk Channel, file, e-mail message, or HTTP-based service. Orchestration Designer provides a way to create loosely coupled business processes that may optionally be long-running in nature. With the Orchestration Designer, analysts not privy to the implementation complexities of COM or Web development can participate in the development of business rules by using the designer in Visio to lay out the business flow. The developer can then implement the moving parts that these designers orchestrate.
But what is the best way to implement BizTalk-friendly moving parts? This is where design patterns come in.
Using the BizTalk Orchestration Designer
There are three key object categories in the business process page of the Orchestration Designer: flowchart shapes, ports, and implementation shapes. Conceptually, the way this works is that you, or your friendly neighborhood business analyst, use the flowchart shapes to create the process flow. The flowchart shapes support basic constructs such as if�then�else decisions, looping while a condition is true, branching execution, rejoining the branches together, and defining transactional boundaries. These relatively simple constructs can be used to create infinitely complex process logic. Implementation shapes come in a few varieties, most of which will be familiar to readers who have used MSMQ and COM+. You can implement application functionality in four basic ways: COM+ components, script components, MSMQ, or BizTalk Messaging. The glue that binds the business process to the implementation code is the third major object category in BizTalk process design—the port.
Ports are named locations where messages are sent and received. Ports can be defined initially as unbound or bound. To create an unbound port, on a design page in the BizTalk Orchestration Designer, right-click on the separator bar and select Add New Port from the popup menu. One primary use of the unbound port is to import an XML document and define the fields that will comprise the message to be passed. Note that unbound ports are less useful than bound ports for defining message flows, especially those that are bidirectional.
To create a bound port, drag an implementation shape onto the right side of the Orchestration Designer page and follow the wizard steps for that implementation. Binding a port provides the ability to define precisely what will travel through the port in each direction, since the target implementation is known when the binding is created. These steps are explained in greater detail in the BizTalk Server 2000 help file. The difference between these two means of port creation is illustrated in Figure 5. Ports are located on the separator bar, with the business process depicted to the left of the bar and the implementation displayed to the right.
BizTalk Orchestration shouldn't be used to design processes at too granular a level (see the Orchestration whitepapers at https://www.microsoft.com/biztalk). Its primary value is integration of existing business processes. To illustrate this idea, consider a traditional business application that uses COM+ components to control the process, and additional COM+ components to perform the work. System designers should strive to replace the controller functionality of such an application with BizTalk, and make use of the existing COM+ work components. As an analogy, you should do your choreography with BizTalk, and do the dancing with COM+, MSMQ, script components, and the BizTalk message tools.
Enough of the tool itself, how do we implement our patterns?
Implementing the Patterns
To provide some context to the scenario that we are tackling, consider the following situation. A hypothetical software company that is small but growing fast has engaged us to consult on their internal systems. The problem is that their existing product support process is taking too much manpower to staff, and the company is having a difficult time gathering quality metrics on this function. The existing system is implemented in Microsoft Exchange, and uses the workflow capabilities of that product to route issues among support personnel.
What is needed is a comprehensive self-service solution to augment the existing application, and to answer questions without direct product support involvement. It would be a simple matter to expose the existing internal knowledge database to the Web as a solution to the problem (see Figure 6), but we want to illustrate that there are benefits to using BizTalk Server to accomplish this integration of existing and new functionality.
Figure 6 Default.asp Query Submission Form
One of our goals in creating the samples was to demonstrate the flexibility of using BizTalk Server Orchestration as the core application engine. Multiple integration points are possible using this architecture. Consider our first entry point into the system: an ASP page creates a COM+ component, then calls a method on that component that places the request message into an MSMQ queue. An XLANG schedule, which already has an instance running, picks up the request from the queue, launches a new schedule instance to monitor the queue, and proceeds to service the request by calling other COM+ components. Entry point number two illustrates a completely different scenario for achieving similar functionality. Here we take a request message from the browser and post it directly into the XLANG schedule from the ASP page.
The pattern implementations we have chosen also achieve a high degree of flexibility and extensibility. The Chain of Responsibility pattern is inherently flexible, functioning similarly to a linked list. The only knowledge required of a participant in the chain is where to forward the request if it can't be resolved. This is made even more flexible in our BizTalk implementation by allowing the component to directly forward the message via a call to Client.Execute. Client.Execute simply acts as a wrapper around the MSMQ APIs such that a message can be sent to a specified queue. The ConcreteHandler tells Client.Execute which queue to send to, which also happens to be the next queue in the chain. If, however, the component developer does not want to mess with the MSMQ APIs, the queue name can also be returned back to a running schedule where BizTalk is used to dynamically send the message to the appropriate queue in the chain. This is one of the niceties of BizTalk. The designer can now benefit by diverging from the traditional pattern implementation by doing it the "BizTalk way."
The code in Figure 7 shows the logic for arbitrarily passing a message to the next component using each of the methods just described. If the Boolean variable bSendDirect is true, the component is instantiated and called. If bSendDirect is false, the value is returned to the schedule and the orchestration invokes the component via MSMQ.
BizTalk Server also greatly simplifies the implementation of the Dispatcher pattern in our samples. We simply branch execution of unhandled requests to the Dispatcher implementation from within our orchestration schedule. By doing this, we have created a well-defined integration point with external systems that has built-in flexibility and extensibility to guard against major code rewrites when the operating environment changes.
Finally, the Observer pattern's functionality provides a simple and powerful mechanism for dynamically modifying system functionality, and responding to events that the application developer deems to be interesting. With a minimum of additional effort, we could use BizTalk Server's persistence mechanisms to create Observer/Observable relationships (or publish/subscribe if you prefer) that live beyond catastrophic events like system failures. In the following code, we illustrate the Observable object as it provides notification to all registered observers through XLANG. The XLANG scheduler allows us to access the schedule as an object.
From IObservable_Notify: While (nCount < m_iObserverCount) sSchedule = m_saObservers(nCount) strURL = "sked:///" & sSchedule ' This enables the XLANG Scheduler Engine to execute the XLANG ' schedule. Set objExecute = GetObject(strURL) Set oObserver = objExecute.Port("Observer")
For related articles see:
House of COM
"Make Your Legacy Apps Work on the Internet"
For background information see:
Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (Addison-Wesley, 1995)
Christian Thilmany is President of the eTier Group Inc. a consulting firm in Houston, TX. He specializes in distributed application architectures for Internet, Intranet, and client/server development. He can be reached at email@example.com.
Todd McKinney is a Senior Consultant for Microsoft Services, specializing in middleware, enterprise development technologies, and system design. He can be reached at firstname.lastname@example.org.
From the October 2001 issue of MSDN Magazine.