Biztalk Server 2006: what is it about ?

No application is an island. Whether we like it or not, tying systems together has become the norm. Yet connecting software is about more than just exchanging bytes. As organizations move toward a service-oriented world, the real goal—creating effective business processes that unite separate systems into a coherent whole—comes within reach.BizTalk Server 2006 supports this goal. Like its predecessors, this latest release allows connecting diverse software, then graphically creating and modifying process logic that uses that software.

The product also lets information workers monitor running processes, interact with trading partners, and perform other business-oriented tasks. Built on the foundation of its predecessor, BizTalk Server 2004, this new release will look familiar to anyone who’s used this earlier version. The most important new additions in BizTalk Server 2006 are: · Better support for deploying, monitoring, and managing applications.· Significantly simpler installation.· Improved capabilities for Business Activity Monitoring (BAM).

BizTalk Server 2006 also uses the latest releases of other Microsoft technologies. It’s built on version 2.0 of the .NET Framework, for example, and its developer tools are hosted in Visual Studio 2005. For storage, the product can use SQL Server 2005, the latest version of Microsoft’s flagship database product, or SQL Server 2000, the previous release. BizTalk Server 2006 can also run on 64-bit Windows, taking advantage of the larger memory and other benefits this new generation of hardware offers .What BizTalk Server 2006 ProvidesCombining different systems into effective business processes is a challenging problem.

Accordingly, BizTalk Server 2006 includes a range of technologies. The figure below illustrates the product’s major components.

As the figure suggests, the heart of the product is the BizTalk Server 2006 Engine. The engine has two main parts:· A messaging component that provides the ability to communicate with a range of other software. By relying on pluggable adapters for different kinds of communication, the engine can support a variety of protocols and data formats, including Web services and many others.· Support for creating and running graphically-defined processes called orchestrations. Built on top of the engine’s messaging components, orchestrations implement the logic that drives all or part of a business process.Several other technologies can also be used in concert with the engine, including:·

A Business Rules Engine that allows evaluating complex sets of rules.· A Health and Activity Tracking tool that lets developers and administrators monitor and manage the engine and the orchestrations it runs.· An Enterprise Single Sign-on facility, providing the ability to map authentication information between Windows and non-Windows systems.On top of this foundation, BizTalk Server 2006 provides a group of technologies that address the more business-oriented needs of information workers. Those technologies are:· Business Activity Monitoring, allowing information workers to monitor a running business process. The information is displayed in business rather than technical terms, and what gets displayed can be controlled directly by business people.· Business Activity Services, allowing information workers to set up and manage interactions with trading partners.All of these technologies are focused on solving the problems inherent in using a diverse set of software to support automated business processes. The next section examines how these solutions might look.How BizTalk Server 2006 Is UsedThe great majority of modern business processes depend at least in part on software. While some of these processes are supported by a single application, many others rely on diverse software systems. This software has commonly been created at different times, on different platforms, and using different technologies. Given this, automating those business processes requires connecting diverse systems. Addressing this challenge goes by various names: business process automation (BPA), business process management (BPM), and others. Whatever it’s called, two scenarios are most important for application integration. One is connecting applications within a single organization, commonly referred to as enterprise application integration (EAI). The other, called business-to-business (B2B) integration, connects applications in different organizations. The figure below shows a simple example of the core BizTalk Server 2006 engine applied to an EAI problem. In this scenario, an inventory application, perhaps running on an IBM mainframe, notices that the stock of an item is low and so issues a request to order more of that item. This request is sent to a BizTalk Server 2006 orchestration (step 1), which then issues a request to this organization’s ERP application requesting a purchase order (step 2). The ERP application, which might be running on a Unix system, sends back the requested PO (step 3), and the BizTalk Server 2006 orchestration then informs a fulfillment application, perhaps built on Windows using the .NET Framework, that the item should be ordered (step 4). In this example, each application communicates using a different protocol.

Accordingly, the messaging component of the BizTalk Server 2006 engine must be able to talk with each application in its native communication style. Also, notice that no single application is aware of the complete business process. The intelligence required to coordinate all of the software involved is implemented in the BizTalk Server 2006 orchestration. Connecting applications within an organization is important, but connecting applications that span organizations can have at least as much value. The figure below shows a simple example of this kind of B2B integration. In this case, the purchasing organization at the top of the figure runs a BizTalk Server 2006 orchestration that interacts with two supplier organizations. Supplier A also uses BizTalk Server 2006, providing indirect access to its Supply application. Supplier B uses an integration platform from another vendor, connecting to the purchasing organization’s BizTalk Server 2006 orchestration using, say, Web services. Integrating existing applications, whether in a single company or across different organizations, into a single automated business process is a fundamental goal of BizTalk Server 2006.

Once those automated processes exist, the product also gives business people, not just technicians, visibility into what’s happening inside the process. In the complex and diverse world of enterprise software today, this kind of integration is a necessity for many organizations.The BizTalk Server 2006 EngineTo allow its users to create a business process that spans multiple applications, the BizTalk Server 2006 engine must provide two primary things: a way to specify and implement the logic driving that business process, and some mechanism for communicating between the applications the business process uses.

The figure below illustrates the main components of the engine that address these two problems. As the diagram shows, a message is received via a receive adapter. Different adapters provide different communication mechanisms, so a message might be acquired by accessing a Web service, reading from a file, or in some other way. The message is then processed through a receive pipeline. This pipeline can contain various components that do things such as converting the message from its native format into an XML document, validating a message’s digital signature, and more. The message is then delivered into a database called the MessageBox, which is implemented using SQL Server.

The logic that drives a business process is implemented as one or more orchestrations, each of which consists of executable code. These orchestrations aren’t created by writing code in a language such as C#, however. Instead, a business analyst or (more likely) a developer uses an appropriate tool to graphically organize a defined group of shapes to express conditions, loops, and other behavior. Orchestrations can optionally use the Business Rules Engine, which provides a simpler and more easily modified way to express complex sets of rules in a business process.Each orchestration creates subscriptions to indicate the kinds of messages it wants to receive. When an appropriate message arrives in the MessageBox, that message is dispatched to its target orchestration, which takes whatever action the business process requires. The result of this processing is typically another message, produced by the orchestration and saved in the MessageBox. This message, in turn, is processed by a send pipeline, which may convert it from the internal XML format used by BizTalk Server 2006 to the format required by its destination, add a digital signature, and more.

The message is then sent out via a send adapter, which uses an appropriate mechanism to communicate with the application for which this message is destined. A complete solution built on the BizTalk Server 2006 engine can contain various parts (sometimes referred to as artifacts): orchestrations, pipelines, message schemas, and more. To allow working with these as a single unit, this release of the product formalizes the notion of a BizTalk application. A BizTalk application wraps all of the pieces required for a solution into a single logical unit, making it the fundamental abstraction for management and deployment.Different kinds of people perform different functions with the BizTalk Server 2006 engine. A business analyst, for example, might defines the rules and behaviors that make up a business process. She also determines the flow of the business process, defining what information gets sent to each application and how one business document is mapped into another. Once the business analyst has defined this process, a developer can create a BizTalk application that implements it. This includes things such as defining the XML schemas for the business documents that will be used, specifying the detailed mapping between them, and creating the orchestrations necessary to implement the process.

An administrator also plays an important role by setting up communication among the parts, deploying the BizTalk application in an appropriately scalable way, and performing other tasks. All three roles—business analyst, developer, and administrator—are necessary to create and maintain BizTalk Server 2006 solutions.Connecting SystemsEffectively exchanging messages across different software on different machines is an absolute requirement for integration. Given the diversity of communication styles that exist, the BizTalk Server 2006 engine must support a variety of protocols and message formats. As described next, a significant portion of the engine is devoted to making this communication work. One important fact to keep in mind, however, is that the engine works only with XML documents internally. Whatever format a message arrives in, it’s always converted to an XML document after it’s received. Similarly, if the recipient of a document can’t accept that document as XML, the engine converts it into the format expected by the target. Sending and Receiving Messages: AdaptersBecause the BizTalk Server 2006 engine must talk to a variety of other software, it relies on adapters to make this possible. An adapter is an implementation of a communication mechanism, such as a particular protocol.

A developer can determine which adapters to use in a given situation. He might choose one of the built-in adapters BizTalk Server 2006 provides, for example, or use an adapter created for a popular product such as SAP, or even create a custom adapter. In all of these cases, the adapter is built on a standard base called the Adapter Framework. This framework provides a common way to create and run adapters, and it also allows using the same tools to manage all adapters. BizTalk Server 2006 includes the following adapters:· Web Services Adapter: allows sending and receiving messages using SOAP over HTTP. Since SOAP is the core protocol for Web services, this adapter is critical for BizTalk Server 2006’s ability to interact in a service-oriented world. As usual with Web services, URLs are used to identify the sending and receiving systems.· File Adapter: allows reading from and writing to files in the Windows file system. Because the applications involved in a business process can often access the same file system, either locally or across a network, exchanging messages through files can be a convenient option.· HTTP Adapter: allows sending and receiving information using HTTP. The BizTalk Server 2006 engine exposes one or more URLs to allow other applications to send data to it, and it can use this adapter to send data to other URLs.· MSMQ Adapter: allows sending and receiving messages using Microsoft Message Queuing (MSMQ).· MSMQT Adapter: allows sending and receiving messages using BizTalk Message Queuing (MSMQT). MSMQT is an implementation of the MSMQ protocol that can receive and send MSMQ messages into the MessageBox. While BizTalk Server 2006 still includes this adapter, applications built today should use the MSMQ adapter instead. · WebSphere MQ Adapter: allows sending and receiving messages using IBM’s WebSphere MQ (formerly known as MQSeries). · SMTP Adapter: allows sending messages using SMTP. Standard email addresses are used to identify the parties.· POP3 Adapter: allows receiving email messages and their attachments using version three of the Post Office Protocol (POP3). · Windows SharePoint Services (WSS) Adapter: allows accessing and publishing documents stored in SharePoint document libraries.· SQL Adapter: allows reading and writing information to a SQL Server database. Adapters for commonly-used business software are also available from Microsoft, including adapters for Siebel, PeopleSoft, Oracle applications and Oracle databases, JD Edwards OneWorld and EnterpriseOne, TIBCO Rendezvous and Enterprise Messaging Service, and Amdocs Clarify. Microsoft partners provide still more adapters, including connectors for electronic data interchange (EDI) and others.Whatever adapter is used to receive data, the messages it gets must commonly be processed before they can be accessed by an orchestration. Similarly, outgoing messages produced by an orchestration often need to be processed before they are sent by an adapter. How both kinds of processing are done is described next.Processing Messages: PipelinesThe applications underlying a business process communicate by exchanging various kinds of documents: purchase orders, invoices, and many more. For a BizTalk Server 2006 application to execute a business process, it must be able to correctly deal with the messages that contain these documents. This processing can involve multiple steps, and so it’s performed by a message pipeline. Incoming messages are processed through a receive pipeline, while outgoing messages go through a send pipeline.For example, even though more and more applications understand XML documents, many—probably the majority today—cannot. Since the BizTalk Server 2006 engine works only with XML documents internally, it must provide a way to convert other formats to and from XML. Other services may also be required, such as authenticating the sender of a message. To handle these and other tasks in a modular, composable way, a pipeline is constructed from some number of stages, each of which contains one or more .NET or Component Object Model (COM) components. Each component handles a particular part of message processing. The BizTalk Server 2006 engine provides several standard components that address the most common cases. If these aren’t sufficient, developers can also create custom components for both receive and send pipelines. The figure above illustrates the stages in a receive pipeline, along with the standard components provided for each one. Those stages and their associated components are:· Decode: BizTalk Server 2006 provides one standard component for this stage, the MIME/SMIME Decoder. This component can handle messages and any attachments they contain in either MIME or Secure MIME (S/MIME) format. The component converts both kinds of messages into XML, and it can also decrypt S/MIME messages and verify their digital signatures.· Disassemble: Three standard components are provided. The Flat File Disassembler component turns flat files into XML documents. Those files can be positional, where each record has the same length and structure, or delimited, with a designated character used to separate records in the file. The second standard component, the XML Disassembler, parses incoming messages that are already described using XML. The third standard component, one that’s not often used today, is the BTF Disassembler. It accepts messages sent using the reliable messaging mechanism defined by the BizTalk Framework (BTF), which was implemented in BizTalk Server 2000. · Validate: BizTalk Server 2006 provides an XML Validator component for this stage. As its name suggests, this component validates an XML document produced by the Disassemble stage against a specified schema or group of schemas, returning an error if the document doesn’t conform to one of those schemas.· Resolve Party: the only standard component for this stage, Party Resolution, attempts to determine an identity for this message’s sender. If the message was digitally signed, the signature is used to look up a Windows identity in BizTalk Server 2006’s Configuration database. (As described later, this database is also used by BizTalk Server’s management tools.) If the message carries the authenticated security identifier (SID) of a Windows user, this identity is used. If neither mechanism succeeds, the message’s sender is assigned a default anonymous identity. Outgoing messages can also go through multiple stages, as defined by the send pipeline in use. The figure above shows the stages and standard components for a send pipeline. They are:· Pre-assemble: No standard components are provided. Instead, custom components can be inserted here as needed.· Assemble: Paralleling the Disassemble stage in a receive pipeline, this stage also has three standard components. The Flat File Assembler converts an XML message into a positional or delimited flat file, while the XML Assembler allows adding an envelope and making other changes to an outgoing XML message. The third (seldom used) option, the BTF Assembler, packages messages for reliable transmission using the BizTalk Framework messaging technology.· Encode: BizTalk Server 2006 defines only one standard component for this stage, the MIME/SMIME Encoder. This component packages outgoing messages in either MIME or S/MIME format. If S/MIME is used, the message can also be digitally signed and/or encrypted. BizTalk Server 2006 defines some default pipelines, including a simple receive/send pair that can be used for handling messages that are already expressed in XML. A developer can also create custom pipelines using the Pipeline Designer. This tool, which runs inside Visual Studio 2005, provides a graphical interface that allows dragging and dropping components to create pipelines with whatever behavior is required.