twitter
facebook 
| BizTalk Server Engine Reworked |
| Mar. 22, 2004 |
A new BizTalk Server release moves Microsoft closer to establishing the .NET Framework and Web services as dominant standards for Web-based application and business interoperability. BizTalk Server 2004 runs on the .NET Framework’s Common Language Runtime (CLR), integrates Visual Studio .NET, and offers native Web services support. Customers will also benefit: BizTalk 2004 promises more reliable Web services implementations, addresses performance problems in earlier versions, and introduces a new engine for adding and changing business logic. However, these benefits do not come without a cost: BizTalk 2002 applications will need to be migrated or rewritten to work with BizTalk 2004. Why BizTalk Matters BizTalk’s primary objective has not changed from previous versions: it helps systems with incompatible data formats and communication protocols to exchange information. The product is generally used in one of two scenarios:
In these scenarios, BizTalk serves as a messaging and processing hub between two or more external business systems. A messaging component in BizTalk controls the exchange of messages (typically business documents, such as purchase orders) between systems, and an orchestration component guides messages through a predefined business process (or orchestration, in BizTalk parlance), which could involve converting messages to the data format expected by a target system, or applying business logic such as the conditions and sequence under which outgoing messages are sent, for example. BizTalk provides a set of tools and logical building blocks that business analysts and developers use to model and build the communication mechanisms, message translations, business logic, and procedural steps that make up an end-to-end business communication process. The code that represents this collection of objects is referred to as a BizTalk application. A BizTalk execution engine, made up of the messaging and orchestration components, manages and runs the BizTalk application in real time. (For an illustration of a typical B2B process that uses BizTalk, see "BizTalk Process Flow".) Overhaul Improves Performance and Scalability Functionally, the two main components in BizTalk’s core engine, messaging and orchestration, are largely unchanged in BizTalk 2004. (Earlier BizTalk versions referred to the two components as the messaging and orchestration engines; the new release consolidates these components into a single engine that Microsoft calls the BizTalk Server 2004 engine.) Technically, however, BizTalk 2004 is a major overhaul: a reworked architecture leverages SQL Server and the .NET Framework to address deficiencies in earlier releases that hurt product performance and thus adoption. (For an overview of BizTalk’s logical architecture and BizTalk terminology, see the illustration "BizTalk Server 2004 Architecture".) Improved Scalability, Load Balancing In BizTalk’s earlier designs, the physical server running an instance of an orchestration stored the state of that instance in memory (orchestration state includes information such as messages sent by the orchestration instance or its overall progress). Although inactive orchestration instances (for example, those waiting for a message) could be "dehydrated," which involved writing state information to a local database and removing the orchestration instance from memory, active orchestrations could rapidly consume a server’s available resources. The problem could be only partially alleviated by adding orchestration servers: for example, BizTalk 2002 orchestration instances were tied to physical servers once started, making it difficult to share processing demands with other servers. BizTalk 2004 implements a SQL Server-based message store, called the "MessageBox," to track the state and transactional history of orchestration instances, making orchestration servers stateless. This should afford two advantages over the previous version. First, an active orchestration instance should consume fewer resources on the server running it, allowing a server to run more orchestration instances before its performance suffers. Second, the MessageBox, and thus orchestration instances, are not tied to a physical server; a dehydrated instance can be reactivated on any available server running the BizTalk engine, thus allowing more effective load balancing. Managed Code, Compiled Orchestrations Large parts of BizTalk have been rewritten in C#, and both the BizTalk engine and BizTalk applications are managed code applications that run under the CLR. This affords BizTalk 2004 advantages common to other .NET applications, such as improved reliability, and should also reduce the amount of error-prone low-level code that developers building BizTalk applications must write. Additionally, where previous BizTalk orchestrations were serialized scripts that got interpreted at runtime, BizTalk 2004 orchestrations are now compiled by the .NET Framework, resulting in faster runtime execution. Performance gains are significant: according to Microsoft, customers can expect five to ten times faster orchestration execution. Faster Messaging Customers should also see faster, more scalable messaging. Past BizTalk versions read an entire incoming message into memory before parsing it into XML and validating its format; in practice, this imposed a limit on message size (about 20MB), beyond which messaging throughput deteriorated. (For example, a supplier’s parts catalog or a batch upload of customer records could exceed this limit.) BizTalk 2004 streams incoming messages into XML and validates them on the fly. Still, large messages with complex schema could present a problem in BizTalk 2004 because the messaging component must "look ahead" and read enough of an incoming message into memory to validate that it is well-formed. Thus large, complex messages theoretically could increase memory and processor consumption and could cause the message engine’s performance to degrade. Feature Set Expands BizTalk 2004 offers two new features that provide greater flexibility for developers and information workers. A business rule feature provides a separate mechanism for creating, storing, and executing business logic, and BizTalk 2004 can integrate systems requiring different log-on credentials. Rule Engine Separates Logic from Orchestration Earlier BizTalk releases provide a limited set of functions for building and applying business logic to messages as they flowed through orchestrations. A simple example of such logic would be determining inventory availability before submitting a fulfillment order; more complex logic would apply volume pricing rules or international tax calculations that require mathematical computation or a database look-up. Simple logic in prior BizTalk versions could be implemented as expressions in orchestrations, or by building custom scripted functions (called "functoids") that were embedded in orchestrations and could operate on message fields. However, to build more complex logic developers needed to write external COM components that were called by orchestrations or the messaging component. However, implementing business logic in this way presented several problems. Because expressions or script-based logic in BizTalk 2002 orchestrations were interpreted at runtime, organizations were limited in the amount and complexity of logic that could practically be housed in an orchestration: too much logic could quickly create a performance bottleneck. Implementing business logic in external components created other problems: it required sophisticated development knowledge to build the components and developer involvement to update or modify the logic encapsulated in them. A new engine in BizTalk 2004 encapsulates business logic in rules or sets of rules (called "policies") that are stored and executed independently of orchestrations or external objects. Rules consist of conditions, logical expressions that are evaluated against facts (such as data values from a BizTalk message or data retrieved from a database), and actions that depend on those conditions. For example, a rule could determine whether the total price of goods in a purchase order exceeds some value (the condition) and apply a discount (the action) if the condition was true. Rules are stored in a SQL Server database or as XML documents in the file system and are loaded and executed at runtime by the rule engine, which can be invoked from within orchestrations. The rule engine caches rules on their first invocation and periodically queries the rules store for changes, updating the rules stored in memory as needed. This allows users to change rules and policies without touching the orchestration that uses them. A graphical user interface included with the product, called the Business Rules Composer, allows business analysts, IT workers, or developers to build, modify, and apply rules and policies in BizTalk 2004. BizTalk 2004 also offers a .NET API for the rule engine, which lets developers invoke the engine from any other applications built on the .NET Framework. Single Sign-On for Heterogeneous Applications BizTalk 2004 introduces a feature called Enterprise Single Sign-On (SSO), which will help businesses integrate systems requiring separate log-on credentials. SSO uses similar underlying technology and provides the same basic capabilities as the identically named feature in SharePoint Portal Server. At the core of SSO are two components:
(The diagram "BizTalk SSO Enables Enterprise Logon" illustrates how a business could use SSO in conjunction with BizTalk messaging and orchestration to integrate systems that require different log-on credentials.) BizTalk SSO includes tools to help IT workers map user credentials to systems. An SSO client allows end-users to self-manage credential mappings. For example, a user could update their SSO credentials to reflect a change made to their HR system log-on credentials. However, the BizTalk SSO feature has no provision for automatically keeping accounts and passwords synchronized with the SSO credential storage. For example, if the HR system enforces a periodic password change, users would have to update their corresponding credentials in the SSO store. BizTalk 2004 implements SSO at the adapter level: adapters query the SSO server for user credentials and attach these credentials to messages before sending the messages to external systems. Consequently, only adapters specifically designed to use the feature will work with SSO. BizTalk 2004 ships with several adapters (including the HTTP, SOAP and FTP adapters) that support SSO. Microsoft has also built an SAP adapter that works with SSO. Third party, SSO-compliant adapters for Peoplesoft and Siebel products are also available. Better Web Services Support Since its first release in Dec. 2000, BizTalk has supported the communication protocols and data standards that enable Web services, and developers could expose existing applications as Web services or call Web services from orchestrations. However, doing so was a difficult exercise for developers. For example, calling a Web service from within an orchestration required a developer to create a COM-based client that served as an intermediary between BizTalk and the Web service. BizTalk 2004 allows direct integration of Web services from the product’s development tools. In addition, the product continues to adopt new Web services standards as they emerge. Faster Web Services Implementation BizTalk 2004 offers built-in support for Web services—developers no longer must write proxy clients to call Web services from BizTalk orchestrations. BizTalk’s development tools, which are based on Visual Studio .NET, allow developers to add Web services references directly to their projects by navigating to URLs or through registries such as Universal Description, Discovery, and Integration (UDDI)—a Internet-based directory of Web services. Once a reference is added to a project, developers can use the Web service in BizTalk applications being built—for example, adding an orchestration step that sends messages to (or receives messages from) the Web service. BizTalk 2004 also provides a wizard-based tool that allows users to publish orchestrations as Web services in registries like UDDI directly. Benefits are immediate: businesses get faster and simpler (thus less error-prone) integration of Web services in BizTalk applications, and developers see a reduction in custom code, which also reduces code maintenance chores. Web Services Standards Gain Traction As Web Services standards inch forward, BizTalk has moved in step: the product supports available Web services standards and adopts new standards after they are released. This adds weight to Microsoft’s standards push of the past several years and its ongoing attempt to position its server products as the platform standard for Web-based applications. It also brings customers closer to the cross-platform, cross-organization interoperability promised by Web services. New standards supported in BizTalk 2004 include the following: XML Schema Definition (XSD). BizTalk converts all incoming messages to XML documents and checks that these conform to a predefined schema, which dictates the structure of the XML document, before publishing them to the MessageBox. Prior to BizTalk 2004, BizTalk used Microsoft’s proprietary XML Data Reduced (XDR) language for describing and validating XML schema. However, following the recommendation of the XML Schema Definition (XSD) standard in May 2001 by the W3C, BizTalk has adopted XSD for describing the structure of XML documents. Because businesses adopting Web services have largely settled on XSD for defining schema, lack of support for the standard in previous versions hurt BizTalk adoption. Business Process Execution Language for Web Services (BPEL4WS), a specification coauthored by Microsoft and IBM, defines how Web services can be combined to orchestrate long-running business processes. BPEL4WS allows developers to formally describe a business process, such as the steps involved in processing a loan application or making a purchase request. BizTalk 2004 orchestrations and schema can be exported into BPEL4WS; BizTalk’s development tools can also import BPEL4WS documents and display graphical representations of the processes they describe. These capabilities could give BizTalk 2004 customers a mechanism for exchanging business process information with trading partners that have designed processes using integration software from other vendors.. Compatibility, Standards Futures BizTalk 2004 offers customers significant benefits, including a faster, more flexible architecture and easier development of BizTalk applications that use Web services. However, these benefits do not come without a cost. Existing and prospective customers should consider the following issues: BizTalk 2002 applications are not forward compatible. Because of the move from XDR to XSD, BizTalk 2002 messaging items (such as schema, pipelines, and maps) are not forward compatible with BizTalk 2004. Microsoft is providing tools and wizards to help users migrate these items forward. However, not all items will migrate: for example, Visual Basic scripts used in BizTalk 2002 (for example, in scripted functoids) cannot be migrated and must be rewritten in a .NET-compliant language (such as C# or Visual Basic .NET). Finally, BizTalk 2002 orchestrations and adapters will not work with BizTalk 2004 and will need to be rewritten. BizTalk 2002 and BizTalk 2004 cannot run on the same machine. Developers and testers will likely have to maintain redundant hardware when migrating applications to BizTalk 2004 to allow side-by-side testing of migrated applications against their BizTalk 2002 counterparts. Similarly, IT data center personnel with BizTalk 2002 applications in production will want to keep those applications running while they prepare new or upgraded BizTalk 2004 applications for production on separate hardware. Other standards still in the works. BizTalk 2004 improves support for Web services standards, but many standards that are critical to IT shops considering Web services architectures are still unfinished. Microsoft and IBM continue to plug away at a standards effort, referred to by Microsoft as the Web Services Architecture (WSA), which addresses many of the gaps (such as security, reliability, and transactional integrity) in early specifications—gaps that have stunted the growth of Web services. (For more information on Microsoft’s Web services standards work, see "Web Services Specifications Inch Forward" on page 26 of the Nov. 2003 Update.) Where the standards are not complete, Microsoft has designed around the gaps: for example, BizTalk 2004 relies on SQL Server to provide transactional integrity and uses a variant of the Microsoft Message Queuing protocol called BizTalk Message Queuing (MSMQT) for reliable messaging. However, Microsoft plans to support WSA standards in BizTalk as the standards are released. For example, the company will release an adapter that conforms to the WSA specification for signed and encrypted messages (called WS-Security) when that specification is finalized. Availability and Resources BizTalk 2004 was released to manufacturing on Feb. 25, 2004, launched Mar. 2, 2004, and will be generally available at the beginning of Apr. 2004. The product runs on Windows 2000 Server and Windows Server 2003; it can also run on Windows XP Professional for development and testing. BizTalk 2004 is available in three editions: Enterprise, Standard, and Partner. The Standard Edition and Enterprise Edition each require SQL Server 2000 (which would most commonly be licensed in per-processor mode). BizTalk 2004 Partner Edition can be used with the free Microsoft SQL Desktop Engine (MSDE) or SQL Server 2000. Unlike previous versions, which supported only four languages, BizTalk 2004 will be available in English, French, German, Italian, Japanese, Korean, Simplified Chinese, Spanish, and Traditional Chinese. BizTalk Server 2004 pricing and technology requirements are listed in "BizTalk Server 2004 Pricing" on page 9 in the Feb. 2004 Update. The BizTalk Server 2004 Web site is www.microsoft.com/biztalk. A 120-day trial version of BizTalk Server 2004 can be downloaded at www.microsoft.com/biztalk/evaluation/trial/default.asp. |
