here are a number of ways to integrate disparate applications across the enterprise. With the introduction of new standards and products, an architecture can take on many different implementations. Which implementation you use is a decision best based primarily on the enterprise-level requirements involved. Biztalk, the Enterprise Integration project from Microsoft, provides two ways for applications to interact with an EAI implementation.

The Problem
Our sample problem is a resource planning application that sends critical updates to an existing SAP application in another location. The updates are sent via an XML document over HTTP through the EAI engine and into the local application. The problem will explore the various ways for applications to interface to the EAI layer by examining the interface between the resource planning application and the EAI engine. Because the EAI layer has been implemented using BizTalk, the remaining design decision is how to best move the XML documents from the local application into Biztalk.

Two Solutions
The first option is to write an EAI Web Service as the interface to the BizTalk application and program the application to call that service to submit the XML. The second option is to leverage the HTTP Receive Function provided by BizTalk and direct the application to submit the XML via this capability.

	Figure 1 is an architectural depiction of a Web Service acting as a layer between BizTalk and the calling resource planning application.

Solution One: Post to Web Services
Web Services provide a beneficial interface into BizTalk Server because of the extensible processing layers between message reception and insertion into the host system (SAP in this case). For example, if you have a specific authentication layer other than the standard HTTP 1.0 authentication, you can build that into your Web service. Figure 1 is an architectural depiction of a Web Service acting as a layer between BizTalk and the calling resource planning application.

	Figure 2 demonstrates how to submit the received document to BizTalk Server.

Note that though the Web Server has the BizTalk Server running on it, BizTalk processing can be separated from the same machine hosting the Web Service. In the sample problem, the server-side (BizTalk receiver) is only leveraging Visual Studio .NET and ASP.NET for the Web Service, and the resource planning application used is a Visual Studio .NET developed client.

The question is: how can you get the XML document into BizTalk so it can transform the document into an SAP iDoc? Microsoft developed the BizTalk Server 2002 Toolkit for Microsoft .NET to help developers integrate ASP.NET Web Services to BizTalk. Use the BTSInterchange PIA to submit documents to BizTalk. Follow the toolkit instructions to install the PIAs.

To keep things simple, define your Web Service to receive the XML message as a string. Since the .NET Framework serializes all objects, create overhead by defining the message as an XML Document in the Web Service. Figure 2 demonstrates how to submit the received document to BizTalk Server.

Solution One: Post to Web Services (cont.)
There are two ways to hand off the message to BizTalk. An Orchestration flow walks the document through a process that handles things like routing a notification to a manager or an archiving routine. The other option is to submit the message directly to the BizTalk Messaging engine, which transforms and routes it to the SAP application. The correlation token is a GUID that the BizTalk Server generates for each submission. By submitting directly to BizTalk, you can extrapolate the correlation token and pass it back to the client to check later.

Although you’re operating within your own enterprise, security is still important. For example, if documents contain sensitive personnel data, you don’t want unauthorized users to view or compromise that data. Encrypt the document with your solution’s public key and pass it through the Web Service. Then you can configure BizTalk to decrypt it for us.

Submitting documents to BizTalk via Web Services provides other flexibility as well. If decoupling is important, then the Web Service can submit the transactional document to MSMQ and return a response different from the submission GUID. BizTalk polling the queue can also enhance the performance of the service since it doesn’t need to wait for BizTalk to return the GUID.

The Web Service takes an XML document and posts it to BizTalk, which works with the XML as a string type and not as an XML Document type. BizTalk takes the string and parses the XML. A benefit to using the string type is that it allows you to manage the business message contract between BizTalk and the remote application (client) in the BizTalk product. This decoupling is beneficial because a change in the contract does not require code recompilation. It also allows you to place the business message inside a SOAP envelope for reliable messaging (discussed in the BizTalk Framework section). Plus, there’s no need worry about the actual business message validation at the Web Service layer. The inability to validate the business message at the Web Service layer may be an issue for some architects, but should not cause a large problem.Basically, using Web Services to interface with BizTalk provides flexibility because it allows you to layer enterprise critical requirements. However, there is a cost in complexity since there is more code to manage and maintain. Performance can also suffer since the Web Service must first validate the SOAP message, then strip off the business message to deliver to BizTalk.

	Figure 3 shows how a client can post a document to BizTalk Server through the HTTP Receive Function.

Solution 2: Posting Directly to BizTalk
Submitting documents to the BizTalk server (and thus the legacy system) through a Web Service is great for flexibility, but a simpler, quicker option exists: BizTalk Server’s HTTP Receive Function. The Receive Function is an ISAPI filter that takes posted HTTP requests and submits them to the BizTalk Server.

Figure 3 shows how a client can post a document to BizTalk Server through the HTTP Receive Function.

Notice that the Receive Function replaces the Web Service. As mentioned in the previous section, BizTalk processing can be separated from the HTTP Receive functionality.

Posting directly to BizTalk Server has some advantages. The biggest is that BizTalk will perform the decoupling for you. When the ISAPI filter receives the document, it submits it BizTalk, regardless of whether the messaging service is running. Submitting directly to the HTTP Receive Function provides the correlation token mentioned before. Figure 4 is a sample output of a submission to the HTTP Receive Function.

	Figure 4 is a sample output of a submission to the HTTP Receive Function.

This is not a SOAP response, but rather an HTML document and a well-formed XML response. The Web client parses it and retrieves the token. This is particularly useful for solutions requiring an audit trail on vital data. The token can be persisted and used to retrieve the document through BizTalk’s tracking interface.

This approach benefits because of the simplicity involved. You can quickly structure a BizTalk architecture that receives documents from your resource planning application. The drawback is the loss in flexibility that may hinder you from satisfying critical requirements. BizTalk is flexible enough to build a preprocessing component, but it can quickly become lost in an enterprise architecture.