BizTalk 2004 Adapter Alternatives for Handling Web Services

Although BizTalk 2004 is generations ahead of its predecessor in handling Web services, it still presents some limitations when you begin to invoke a Web service. For example, BizTalk does not handle Web service ArrayList return types and other complicated XML message schemes.

Luckily, BizTalk 2004 Orchestrations include support for the .NET Framework. With .NET Framework support for Web services, you can handle an odd Web service, such as an ArrayList, without resorting to building your own adapter.

Using a simple example, this article shows how to integrate .NET Framework Web services support into a BizTalk 2004 Orchestration.

Overview of the Example

Before proceeding, a couple clarifications will put the example in the right context. First, the underlying technology matters. Web service support and conventions can vary depending on the environment hosting the Web service. For example, some platforms don’t distinguish between an integer and floating point value; they simply support a Numeric Datatype. Second, although the example utilizes all Microsoft technologies, you can apply the same ideas to integrate BizTalk with another vendor’s technology.

The example includes the following components:

  • An ASP.NET Web service hosted on IIS
  • A BizTalk 2004 Orchestration, which receives a file via a receive port, calls a Web service, and transmits a file via a send port
  • A .NET assembly, which wraps the Web service functionally

Now, you can turn your attention to the example’s Web service component.

A Sample .NET Web Service

The Web service, TestXML, has implemented a single function (TestInvoke) that accepts a few parameters and returns a .NET Framework ArrayList. The following is the body of the TestInvoke function:

public ArrayList TestInvoke(int idVal, string testName,
                            int numValues)
   ArrayList al;

   al = new ArrayList();

   for (int i=0; i<numValues; ++i)
      al.Add (testName + i.ToString());

   return (al);

As stated earlier, the TestXML is hosted in IIS. The IIS Web site hosting TestXML has been set up to use SSL and configured with IIS Basic Security. Although configuring an IIS site to use SSL and Basic Security is beyond the scope of this article, the key changes to make in IIS are summarized below.

First, to implement Basic Security in IIS, make sure Basic Authentication is switched on and Anonymous security is turned off (see Figure 1).

Figure 1: Implement Basic Security in IIS

Implementing SSL is a little more complicated. The example uses selfssl.exe, a command-line utility that ships with the IIS Resource Kit (see Figure 2).

Figure 2: SelfSSL.exe Command-Line Utility

SelfSSL.exe will create a certificate and set up SSL on your Web site.

The Orchestration and the Assembly

Before invoking the Web service, quickly review of the Orchestration (see Figure 3).

Figure 3: The Orchestration

The “Call WS” expression icon invokes the Web service. As stated earlier, Web service handling is wrapped in an assembly. The assembly has been included in the solution along with the Orchestration. Because you are loading the assembly in the GAC, it has been strongly named.

When you create a Web reference to the Web service, Visual Studio reads the service’s WSDL code and creates the appropriate classes for you. The following code from the assembly invokes the Web service:

TestXML ws;
object[] obj;
CredentialCache cred;
NetworkCredential netCred;
string retval;

retval = "";

System.Net.ServicePointManager.CertificatePolicy =
   new TestWSTrustCertificatePolicy();

ws = new TestXML();

cred = new CredentialCache();
netCred = new NetworkCredential("****","*****");

cred.Add(new Uri(ws.Url),"Basic",netCred);

ws.Credentials = cred;

obj = ws.TestInvoke(0,"Name value",3);

As you can see, some of the code is a straightforward Web service invocation. Some of the other code dealing with authentication and secure communication requires some explanation.

More by Author

Must Read