XML Frameworks, Applications, and Protocols

Now that we have discussed XML to some degree, let's talk a bit about the BizTalk Framework and other related initiatives, such as ebXML, cXML, RosettaNet, and UDDI. But before doing so, it is important that you understand SOAP (Simple Object Access Protocol) because it, frankly, has had the greatest influence on the BizTalk Framework to date and is likely to influence many other initiatives as well.

Introduction to SOAP

At the most fundamental level, Simple Object Access Protocol (SOAP) is an XML-based language used to perform Remote Procedure Calls (RPC) over the Internet. Using SOAP, you can invoke an object on a Unix box in California, for example, from the Windows NT development machine running in your office in Virginia.

Let's say that your corporate intranet is running on your server, which is an NT machine with IIS installed, and all your applications are built using ASP 3.0 and VB 6. Now imagine that a user requests a weather update from your intranet. The user is going to assume that the weatherUpdata.asp page is extracting the information from some local data source and feeding her the information; but, she would be wrong! Instead, the Weather application is a SOAP-compliant interface that links to a Unix-based, SOAP service (also known as a Web Service).

When a user makes a request to your Web server by issuing a POST with some basic information—for example, a ZIP Code—an ASP script accepts the request and invokes a VB component, which wraps the request parameters—that is, the ZIP Code—in a SOAP request. The VB component passes a SOAP-compliant message (we will discuss some of the requirements of SOAP v1.1 a bit later, but for now, it is important to understand the theory) over HTTP(S) to the Unix box in California. The Unix box is running Apache, which receives the XML message and parses out the SOAP request. The SOAP message tells the server which method to use—ergo which object to invoke—and passes off the required parameters—in this case, the ZIP Code. The Unix box, which is a Weather Service application, looks up the ZIP Code in a database and feeds the respective weather information back to the Apache Web Server. The weather information is then wrapped up into a SOAP response, sent back to the IIS box and VB component, parsed, and passed on to the original weatherUpdate.asp page to be viewed by the user in her browser as HTML. The result is a real-time weather service that uses logic from the source application to provide the necessary data via the Internet.

Some people might wonder what the difference is between this kind of distributed model and a more traditional model in the form of Remote Procedure Call (RPC). The primary difference is that a SOAP application—or Web Service—must be compliant with the SOAP standard and most often will use HTTP as its transport protocol. However, other protocols can be used. HTTP is just the most common.

Another way to think of it is that instead of making a request with a browser, a Web server will be capable of brokering those requests for you and managing the presentation of the material independent of where that data lives. That way, there is no need for a person to keep track of a hundred different Web sites. Your corporate portal or favorite Web portal will be responsible for aggregating specific information for you, and making it presentable. Let's talk now about how this can be accomplished.

Understanding the SOAP v1.1 Specification

First, there is the SOAP v1.1 specification. SOAP consists of three independent parts:

• The SOAP envelope construct defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory.

• The SOAP encoding rules define a serialization mechanism that can be used to exchange instances of application-defined data types.

• The SOAP RPC representation defines a convention that can be used to represent remote procedure calls and responses.

A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body.

<html> 
<head>
<title>My Favorite Books</title>
</head>
<body>
</body>
</html>

<books> 
<book id="1">
<title>Hunt for Red October</title>
<author>Tom Clancy</author>
</book>
...
</books>

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:b="http:/
/myFavoriteBooks.org"> 
<head>
<title>My Favorite Books</title>
</head>
<body>
<b:books>
<b:book b:id="1">
<b:title>Hunt for Red October</title>
<b:author>Tom Clancy</author>
</b:book>
...
</b:Books>
</body>
</html>

The SOAP Envelope defines the overall framework for the message. It does this by qualifying itself through use of the SOAP Envelope namespace. Following is an example of how a SOAP Envelope looks:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> 
<SOAP-ENV:Header>
<SOAP-ENV:Body>
...
</SOAP-ENV:body>
</SOAP-ENV:Header>
</SOAP-ENV:Envelope>

The SOAP Envelope should be thought of as the entire SOAP message, of which the header and body are subparts.

The SOAP Header is where information about the message is expected to exist. Typical examples of header entries are authentication, transaction management, payment, and so on. The header is not required by the SOAP specification.

Finally, we arrive at the SOAP Body, where the core of the message exists. It encompasses the parameters, for instance, that will be required by the object that is going to be invoked by the request. Listing 2.9 shows a copy of a message we might send to receive weather information for our area.

Listing 2.9. SOAP Request for Weather Update

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:getTemp
xmlns:ns1="http://ourlocalweatherstation.org"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<zipcode xsi:type="xsd:string">94041</zipcode>
</ns1:getTemp>
</SOAP-ENV:Body>
12 </SOAP-ENV:Envelope>

In Listing 2.9, you see an element called <nsl:getTemp>. Ignoring the namespace, and focusing on the element name getTemp, that looks like it could be the name of a method, doesn't it? That's because it is a method name! In this case, the method is requesting the temperature for the area matching the 94041 ZIP Code, as defined in the body of the SOAP message.

Also notice that in addition to the namespaces talked about earlier, there is an additional namespace, xsi. This namespace is an XML schema qualifier that allows you to introduce data typing into the application. As you can see in <zipcode xsi:type= "xsd:string">94041</zipcode> of the previous listing, the ZIP Code is being typed as a string. This becomes more valuable as the application grows in complexity.

Listing 2.10 is the response to our Weather request. It is a response to a request from a server that says, “I need to know the temperature for this particular ZIP Code.” The reply, as seen in Listing 2.10, is 68.0 degrees.

Listing 2.10. SOAP Response to Weather Update

<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:getTempResponse
 xmlns:ns1=" http://ourlocalweatherstation.org"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:float">68.0</return>
</ns1:getTempResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Only a few things are worth looking at in this SOAP response because it is so similar to the request. The first thing you should notice is that the method name has changed to indicate that this is a response to the original message, thus you have <nsl:getTempResponse>. Also notice that in <return xsi:type="xsd:float"> 68.0</return>, the node name has changed from <zipcode> to <return>, and the data type value is now a float with a node value of 68 degrees. To process the response to our request, all we would need to do is parse the XML, retrieve the temperature infor-mation, and then apply it to the application logic.

This is only a quick introduction to SOAP, but it gives you enough of a taste to understand how the BizTalk Framework uses the SOAP 1.1 specification later on in the chapter and throughout the book. For more information on SOAP, visit the W3C site at http://www.w3.org/TR/SOAP/.

ebXML, cXML, and RosettaNet

Without a doubt, SOAP is going to play a key role in XML-based messaging for years to come. Although the W3C is hard at work on a specification to expand on SOAP, the foundation has clearly been set. However, SOAP by itself, is nothing more than a messaging protocol. Along with the message routing rules must come standards for interoperability in terms of the messages themselves, schemas, repositories, and discovery tools. More than a handful of companies—and even the United Nations—are in the process of developing entire frameworks around these standards, and we will discuss some of them now.

ebXML (Electronic Business XML Initiative)

Perhaps the most influential framework—apart from Microsoft's own BizTalk initiative—is ebXML (Electronic Business XML). Depending on who you ask, the ebXML standard has perhaps the strongest chance of becoming the perennial leader in the B2B realm. With the largest amount of international support, ebXML is a joint venture casted by the United Nations Body for Trade Facilitation and Electronic Business (UN/ CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS). Together, these two bodies are seeking to standardize business specifications as defined by the XML syntax.

The goal of the Electronic Business XML initiative is to develop a technical framework that enables XML to be used in a consistent manner for the exchange of all electronic business data—for example, purchase orders, invoices, acknowledgments, financial reporting, and so on. A primary objective of ebXML is to lower the barrier of entry to electronic business to facilitate trade, particularly with respect to small- and medium-sized enterprises (SMEs) and developing nations.

It should first be understood that this is not “revolutionary” technology. In fact, for the past 25 years, companies have been exchanging information with each other electronically, based on Electronic Data Interchange (EDI) standards. Unfortunately, EDI currently requires significant technical expertise and deploys tightly coupled, inflexible architectures. Although it is possible to deploy EDI applications on public networks, they are most often deployed on expensive dedicated networks to conduct business with each other. The ebXML initiative looks to correct this problem by decreasing the cost for entry into the Internet-based marketplace.

The ebXML framework consists of 11 separate project teams, working in cooperation to realize the goals of the initiative. They are

• Business Process Methodology

• Core Components

• ebXML Requirements

• Marketing, Awareness, and Education

• Registry and Repository

• Technical Architecture

• Technical Coordination and Support

• Transport/Routing and Packaging

• Proof of Concept

• ebXML Trading Partner

• TA-Security

One thing we haven't mentioned yet is the need for repositories. Repositories offer public and private parties a searchable, Web-accessible location to which they can publish their XML schemas. For instance, if Company X is a publishing company and required its authors to format their books in a particular XML format, Company X might save the XML schema representing the necessary book format to an XML repository. At the time of this writing, there are two major XML schema repositories: XML.org and BizTalk.org. It is likely that the ebXML initiative will either use XML.org in some way as its preferred repository or build a comparable repository customized to its particular needs.

Is ebXML at odds with BizTalk? Concerns about this were put to rest in mid-February 2001 when UN/CEFACT and OASIS announced that plans were underway to integrate SOAP 1.1 and SOAP with attachments specifications into the ebXML messaging specification. This landmark event makes it clear that the goal behind these standards is true interoperability. There will always be money to be made in proprietary systems that build on these systems, but if the infrastructure is unstable, then applications built on those standards will be inefficient. By adopting SOAP, you can rest assured that ebXML and BizTalk will be able to operate interdependently among one another.

For more information on ebXML, visit http://www.ebXML.org on the Web.

cXML (Commerce XML)

While we wait for the ebXML framework to come to fruition, another initiative called cXML (Commerce XML) has achieved actual results in a production environment. The cXML specification was developed by Ariba and uses XML for describing

• Business catalogs

• Purchase orders

• A “punch-out” process

Business catalogs and purchase orders are nothing new to most companies. cXML simply enables these documents to be exchanged in a uniform fashion over the Internet using XML as the document syntax. In this way, applications can be written using an open, nonproprietary API to extract information from these documents and to share them in a consistent manner.

Punch-out, on the other hand, offers us a unique way to enhance the way buyers procure goods from their business partners. Simply, cXML punch-out enables a procurement officer to click a link in the office's intranet, or otherwise punch-out-enabled site, and “punch out” to his distribution partner or manufacturer's procurement site. The punch-out usually occurs by opening another browser window, thereby maintaining state on the original punch-out browser.

The user then shops around on the procurement site, browsing for items that he wants to purchase. When the user is ready to buy, he clicks a “purchase” button—or something similar such as a “buy” button. Regardless, the procurement site wraps the shopping cart in cXML-compliant syntax and then sends it via HTTP(S) to the original punch-out site. The server from which the user initially punched out then processes the cXML shopping cart it received and enters it—for instance—into an internal purchase request (see Figure 2.1).

As with SOAP, cXML is not a complete solution but can be thought of as more of a partial solution to help automate the integration process between business partners.

RosettaNet

We'll use a metaphor to assist in the understanding of what RosettaNet is about. The story goes that the name comes from the “Rosetta Stone,” which was an ancient carving with a message that was done in three languages. This was a huge revelation leading to the understanding of hieroglyphics—which is, in a sense, the goal of RosettaNet. To break language barriers when it comes to doing business over the Net by enabling everyone to speak the same language.

Developed with the collaboration and expertise of leading high-tech companies, RosettaNet standards offer a robust nonproprietary solution, encompassing data dictionaries, implementation framework, and business message schemas and process specifications for e-business standardization. RosettaNet standards include the RosettaNet Business Dictionary, RosettaNet Technical Dictionaries, RosettaNet Implementation Framework (RNIF), and RosettaNet Partner Interface Processes (PIP).

The goal for the RosettaNet Business and Technical Dictionaries is to reduce confusion in the procurement process due to each company's uniquely defined taxonomies—that is, business terminologies. The RosettaNet Business Dictionary designates the properties for defining business transactions between trading partners, and RosettaNet Technical Dictionaries provide properties for defining products and services.

For instance, in your electronic business documents, do you semantically define a purchase order as a <purchaseOrder>, a <purchaseorder>, or a <PurchaseOrder>? Perhaps it is something entirely different, such as an <orderRequest>. Regardless, RosettaNet-compliant applications, due to XML's cap-sensitivity and strict adherence to semantics, require that everyone use the same language to define, for instance, a purchase order using this <PurchaseOrder> tag. All the possible tags that are used within RosettaNet-compliant messages can be found in the RosettaNet Dictionaries.

The RosettaNet Implementation Framework

The RosettaNet Implementation Framework (RNIF) Core Specification provides exchange protocols for quick and efficient implementation of RosettaNet standards. The RNIF specifies information exchange between trading-partner servers using XML, covering the transport, routing, and packaging; security; signals; and trading partner agreement.

The RNIF specification can be likened to SOAP. However, unlike SOAP, it is complex at first glance and is not a standard that is officially recognized among groups such as the W3C. It would be very nice indeed to see the RNIF specification evolve to a more SOAP-like standard than the current less-familiar syntax.

RosettaNet Partner Interface Processes

A key product of the RosettaNet effort is the set of Partner Interface Processes (PIPs), which are specialized XML-based dialog that define how business processes are conducted between trading partners. The PIPs define processes for a range of business activities, such as inventory, pricing, sales management, order handling, product configuration, and shipping. Each PIP specification includes a business document with the vocabulary and a business process with the choreography of the message dialog. PIPs apply to the following core processes:

• Administration

• Partner, Product, and Service Review

• Product Introduction

• Order Management

• Inventory Management

• Marketing Information Management

• Service and Support

• Manufacturing

Each of these initiatives exhibits a relatively noncomplex way for companies to conduct business online to lower the costs associated with commercial transactions. RosettaNet, ebXML, and cXML each share many of the same qualities, but each has a different goal.

As you will see, the BizTalk Framework seeks to solve the same problems that these initiatives do.

The bad news then—if there is any bad news—is that companies must go through a bit of effort to see which initiative is most suited to resolving their particular business requirements. The good news is that all these initiatives, because of their adherence to open standards such as XML and SOAP, will most likely be able to communicate with each other without the need for expensive systems or extensive programming “glue.” The moral of the story then is to implement whatever types of systems and coding languages work for you internally and are capable of providing you the access you need to interface with others—and let them interface with your systems—in an open format that enables the simple, efficient, and secure exchange of business data.

UDDI

Now that you have taken a close look at some of the more popular B2B frameworks, you need to examine another piece of the puzzle that will play a large role in making online business processing a reality.

Introduction to UDDI

UDDI (Universal Description, Discovery, and Integration) is a set of specifications that define a way to publish and discover information about a Web Service.

UDDI basically takes an approach that relies on a distributed registry of businesses—think of an online White Pages—and their Web Service descriptions when applicable. The services are revealed in a common XML language that an application can process to find a best possible match for its business need. This common language is not SOAP, but a UDDI-specific XML grammar. Just remember that SOAP is used as a transport protocol, but the message itself can be of any type. In this case, the SOAP message encloses the necessary parameters required by the UDDI services.

The bottom line is that the UDDI business registry can be used for

• Establishing whether a given partner has a particular Web Service that can be used

• Finding companies in a given industry with a particular set of generic or bundled services

• Locating information about how a partner or intended partner has exposed a Web Service to learn the technical details required to interact with the service

Building with UDDI

So you are the CEO of ACME, and you build widgets. You are going to provide a Web Service that allows business partners to send a request for more widgets when their inventory gets low. You service thousands of customers and can't contact each one individually, so you decide to “advertise” your company's Web Service on UDDI. That way, as more of your partners decide to participate in eCommerce activities, they can simply “subscribe” to your service via UDDI.

The first step is for companies to sign up with UDDI. The information that businesses can register includes several kinds of simple data that help others determine the answers to questions such as “who, what, where, and how?” Corporate information such as company name, business identifiers (D&B, D-U-N-S, and so on), and specific contact information answers the “Who?” question. The “What?” question requires the classification of products and industry codes, in addition to the details about the Web Services that will be made available. Answering the question “Where?” is a matter of registering a unique address—for example, URL, e-mail, or other—through which a particular Web Service is accessed. Technically, the “Where?” question resolves to something referred to as binding information. In the design specs, the node name is bindingTemplate. This leads us to the “How?” question. The registrant issues references to specifications that can be used as models for how a particular software package or technical interface will function. These references are regarded as tModels in the UDDI documentation.

After you have registered your company, ACME, other companies will be able to find you based on a defined set of parameters. You will now see one way UDDI can be used by a potential business partner to find your Web Service to purchase widgets online.

XZY, Inc., is looking for someone who will allow them to purchase widgets online via an automated process that they have built in-house. When inventory drops below 10,000, they would like their system to automatically purchase a certain number of widgets based on business rules programmed into the system.

Because XYZ is looking for a particular company that can provide this type of service, it goes to the UDDI registry. When you, as CEO of ACME, defined your company's services, the UDDI registry saved your settings and propagated them throughout the UDDI distributed network. Now companies such as XZY, Inc., can use a format similar to the following to locate different companies with the types of services that you offer. Sure, this means more competition to you—potentially—but it is also a way for you to market yourself for free (because basic UDDI services are free of charge). Here is how XYZ, Inc., would search for a company to buy widgets from. The following UDDI message would be wrapped in a SOAP call to the UDDI registry:

<find_service 
businessKey="uuid_key"
generic="1.0"
maxRows="20"
xmlns="urn:uddi-org:api">
<findQualifiers>
<findQualifier>sortByNameAsc</findQualifier>
</findQualifiers>
<name>Purchase Widget</name>
</find_service>

By issuing this command, XYZ, Inc., gets back a service list that includes all the services that match the request and the companies that provide those services, which in this case, is any service that provides for the purchasing of widgets online. XYZ, Inc., needs to parse the SOAP reply to extract the information it is looking for. This means that the same application responsible for sending the <find_service> request to UDDI should be able to process the <serviceList> reply that comes back.

Hopefully this explanation of UDDI has cleared up any confusion you might have had about its usefulness in the world of Web Services. For more information, visit the UDDI.org Web site at http://www.uddi.org.

BizTalk Framework 2.0

We have looked at XML technologies and the applications that have been developed around them. We've investigated XML frameworks for messaging and B2B, and also learned a bit about B2B registries and repositories. So now it is time to talk explicitly about how the BizTalk Framework 2.0 can be used to facilitate the efficient, secure exchange of your business products and services.

Introduction to BizTalk Framework 2.0

At the most rudimentary level, the BizTalk Framework provides a set of basic mechanisms required for most business-to-business electronic exchanges. The goal of this framework is to

• Give a general overview of the BizTalk Framework architecture, including the BizTalk document and message semantics

• Provide a detailed set of specifications for constructing BizTalk documents and messages

• Provide necessary insight into ways of securing BizTalk documents and messages over a number of Internet-standard transports and transfer protocols

The BizTalk Framework specification was devised to define messaging interaction between BizTalk Framework 2.0 Compliant servers, referred to as BFC servers. It is important that you realize up-front that a BFC server is not necessarily a Microsoft BizTalk server. A BFC server can be any product—on any platform—that conforms to the BizTalk Framework 2.0 specification. The following list describes the different pieces that come together to form the BizTalk Framework:

• BizTalk Framework Compliant (BFC) server— A BFC server is represented by the set of services providing the message-processing functionality defined in the BizTalk Framework specifications.

• Application— An application is the line-of-business system where the business data and/or logic are stored and executed. An application also includes any additional adapters that may be required to emit or consume business documents (see the following item) and communicate with a BFC server.

• Business document— A business document is a well-formed XML document containing business data. This data may represent a purchase order, invoice, sales forecast, or any other business information. One or more business documents form the body of a BizTalk document. (Following is an example of a simple business document—in this case a PO—which will be processed by BizTalk Server and a variable number of other applications.)

<po:PurchaseOrder xmlns:po="http://electrocommerce.org/purchase_order/"> 

<po:Title>BizTalk Server Unleashed</po:Title>
</po:PurchaseOrder>

Always remember that BizTalk Server and other applications are just ways of processing a business document. The business document represents the data ultimately required by end users. Listing 2.11 is a more robust sample of a BizTalk document with BizTalk Framework semantics included. The actual business document, starting with the element <po:PurchaseOrder>, is encased in the <SOAP:ENV:Body> element, near the end of the message.

Listing 2.11. BizTalk 2.0 Message

<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
<SOAP-ENV:Header>
<eps:endpoints SOAP-ENV:mustUnderstand="1"
xmlns:eps="http://schemas.biztalk.org/btf-2-0/endpoints"
xmlns:agr="http://www.trading-agreements.org/types/">
<eps:to>
<eps:address xsi:type="agr:department">Book Orders</eps:address>
</eps:to>
<eps:from>
<eps:address xsi:type="agr:organization">Book Lovers</eps:address>
</eps:from>
</eps:endpoints>
<prop:properties SOAP-ENV:mustUnderstand="1"
xmlns:prop="http://schemas.biztalk.org/btf-2-0/properties">
<prop:identity>uuid:74b9f5d0-33fb-4a81-b02b-5b760641c1d6</prop:identity>
<prop:sentAt>2000-05-14T03:00:00+08:00</prop:sentAt>
<prop:expiresAt>2000-05-15T04:00:00+08:00</prop:expiresAt>
<prop:topic>http://electrocommerce.org/purchase_order/</prop:topic>
</prop:properties>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<po:PurchaseOrder xmlns:po="http://electrocommerce.org/purchase_order/">
<po:Title>BizTalk Server Unleashed</po:Title>
</po:PurchaseOrder>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

A BizTalk document is a SOAP 1.1 message in which the body of the message contains the business documents, and the header contains BizTalk-specific header entries for enhanced message-handling semantics. Following are some concepts that apply directly to BizTalk documents, and how they are interpreted by BizTalk Framework compliant (BFC) servers. We will look at a number of concepts and then follow up with an example of how each works within the framework.

We will begin with the concept of document lifetime. The lifetime is the time period during which a document is meaningful. A document must not be sent, accepted, processed, or acknowledged beyond its lifetime. Listing 2.12 is an example of how a business document's lifetime is set within the context of the message itself.

Listing 2.12. BizTalk 2.0 Lifetime Parameters

<prop:sentAt>2000-05-14T03:00:00+08:00</prop:sentAt>
<prop:expiresAt>2000-05-15T04:00:00+08:00</prop:expiresAt>

Another concept worth noting is the document identity. Identity is a universally unique token used to identify a document. Listing 2.13 is an example of how a business document will identify itself.

Listing 2.13. BizTalk 2.0 Identity Parameter

<prop:identity>uuid:74b9f5d0-33fb-4a81-b02b-5b760641c1d6</prop:identity>

An acceptance is the act of being accepted for delivery by a receiver. A received document is accepted if it is recognized as being intended for an endpoint served by the receiver, including documents that are copies or duplicates of previously received documents (based on the identity). Acceptance does not mean that all header entries and the body have been inspected and their contents verified for any specific purpose.

Idempotence—a word few of us probably have encountered before—represents the capability of a document to be transmitted and accepted more than once with the same effect as being transmitted and accepted once.

A BizTalk message is the unit of wire-level interchange between BFC servers. BizTalk messages are used to send BizTalk documents, and any related files, between BFC servers. A BizTalk message must always contain a primary BizTalk document that defines the semantics of the message within the BizTalk Framework. It may in addition contain one or more attachments, including well-formed XML documents, some of which may themselves be BizTalk documents. BizTalk documents carried as attachments are treated just like any other XML documents and have no special significance in regard to the semantics of the BizTalk message. The structure of a BizTalk message depends on the transport being used to carry the message and often includes transport-specific headers.

The actual interchange of BizTalk messages between BFC servers presupposes a communication mechanism that is used to carry messages physically from the source to the destination business entity. The term transport refers to this mechanism. Transports used in this context vary widely in their characteristics, ranging from simple datagram and file transfer protocols to transfer protocols such as HTTP and SMTP, and sophisticated, message-oriented middleware. This specification does not differentiate between transports based on their capabilities. Transport characteristics affect only the transport bindings.

An endpoint is a BizTalk Framework compliant source or the destination of a BizTalk message. Listing 2.14 is an example of a BizTalk endpoint being defined.

Listing 2.14. BizTalk 2.0 Endpoints

<eps:endpoints SOAP-ENV:mustUnderstand="1"
xmlns:eps="http://schemas.biztalk.org/btf-2-0/endpoints"
xmlns:agr="http://www.trading-agreements.org/types/">
<eps:to>
<eps:address xsi:type="agr:department">Book Orders</eps:address>
</eps:to>
<eps:from>
<eps:address xsi:type="agr:organization">Book Lovers</eps:address>
</eps:from>
</eps:endpoints>

Attachments are generally non-XML files or other related information that are not transmitted as a business document within the body of the BizTalk document. These may be related images, large compressed files, or any other information format or content that is not an appropriate business document. Attachments may be carried within the BizTalk message enclosing the BizTalk document, or they may be external to the message and simply referenced within the document.

Another interesting point is that the BizTalk Framework 2.0 does not follow a traditional major and minor versioning model. Instead, the version is implied by a namespace URI reference used to qualify BizTalk-specific elements. For instance, note in the namespace URI shown here that there is a btf-2-0 reference. This string is going to change as an application evolves to handle the newer versions of the specification:

< ... xmlns:eps="http://schemas.biztalk.org/btf-2-0/endpoints"> 

The next version might look like this:

< ... xmlns:eps="http://schemas.biztalk.org/btf-3-0/endpoints"> 

This section gave you some insight into the semantics behind the BizTalk Framework. Now let's discuss the implementation layers of the framework.

The BizTalk logical implementation model consists of three layers. The first is the application layer. Applications will speak with other applications, whether they are external to the enterprise and outside the firewall, or inside the enterprise—for example, EAI or A2A. The application uses the BFC server for both sending and receiving business documents, but the application itself is responsible for the actual creation, evolution, and eventual destruction (or archiving) of the business document(s), including any attachments. Figure 2.2 is an example of how the BizTalk message flow works:

The amount of work that the application is going to have to do to process a business document depends on the type of BFC server you are working with. If you are using Microsoft BizTalk Server as your BFC server, you can be confident that your application will be doing a minimal amount of work, when compared to the use of a “home-grown,” third-party BFC server. The goal of the BFC server is to use information contained in the BizTags to determine the correct transport-specific destination address. The server then hands the message to the transport layer for transmission to the destination BFC server.

Structuring BizTalk Messages

In general, the body of the SOAP message constituting a BizTalk document contains several related business documents, and the header of the SOAP message contains several BizTalk-specific (and potentially other) header entries.

Figure 2.3 depicts the structure of a typical BizTalk document. First, you have the envelope, with two child elements:

• Header

• Body

The header contains

• Endpoints—Mandatory

• Properties—Mandatory

• Services—Optional

• Manifest—Optional

• Process—Optional

The endpoints define the source and destination organizations. Properties provide information regarding the document's identity and the times of transmission. The source nodes enable the source organization to specify details about delivering the document reliably. The manifest is responsible primarily for document catalog information, whereas the process tag is responsible for persisting the process-management data and providing a processing context for the BizTalk document.

Not only is the BizTalk Framework effective at sending and routing documents, but the Framework also has extensive documentation regarding other features such as reliable delivery (that is, return receipts), sending documents with attachments (for example, pictures, binary files, and so on), security (for example, SSL, S/MIME, and detached signature mode), and transport bindings (for example, HTTP and SMTP). All these play an important role in making the BizTalk Framework a both efficient and secure document transport possibility that can only positively affect the future of business processing.