BizTalk 2004 Adapter Alternatives for Handling Web Services, Page 2
Authentication and Secure Communication
Minimal Web service best practices dictate that a Web service support some type of authentication and secure communication. In this example, authentication is done via IIS Basic Security and secure communication is implemented using SSL. So, to invoke the Web service, you must supply the proper credentials (authentication) and perform some actions to accept a certificate.
When use a Web browser to communicate with a SSL site, you must accept a certificate to secure the connection with the site. In a BizTalk Orchestration, there is no user to accept the certificate. So, you must programmatically accept the certificate. The following line of code accepts all X.509 Certificates:
System.Net.ServicePointManager.CertificatePolicy = new TestWSTrustCertificatePolicy();
TestWSTrustCertificatePolicy implements the ICertificatePolicy interface. The example accepts all X.509 certificates. In your own ICertificatePolicy implementation, you can filter for particular certificates by using the X509Certificate parameter.
Next, you must authenticate. The following code performs the authentication:
cred = new CredentialCache(); netCred = new NetworkCredential("****","****123#"); cred.Add(new Uri(ws.Url),"Basic",netCred);
As you can see, the code supplies a login and password, and directs the credentials for use with Basic Security.
Ideas for Your Own Implementation
Before applying the ideas in the previous sections to your own implementation, you must consider a few things:
- The example does little with the data returned from the Web service. In your implementation, you have a number of options for working with the returned data. Instead of returning a string, you can return a more complex data structure and assign it to a BizTalk variable. If you do this, remember to include the [Serializable] attribute on the class declaration.
- Think carefully about exception handling. Because you've implemented your code in a .NET assembly, you must determine whether you should handle exceptions in the assembly or, in BizTalk, or both.
- You may find BizTalk 2004 Business Rules helpful in your own implementation. The Web service you contact may be offline at times. If you were using the HTTP adapter, you can reset the service window. By using Business Rules and a loop, you can create your own service window implementation. Also, instead of using an Orchestration Expression, you can move the code to a set of Business Rules. (See the article "BizTalk 2004 Business Rules Explained" for more information.)
As you may have noticed in the example code snippets, sensitive information such as a username and password are embedded in the code. Depending on your security requirements, you may want to secure this information.
If you were using the BizTalk HTTP adapter, you could've used single sign-on (SSO) to store credentials. SSO may still be an option if you want to use the SSO API.
Download the Code
To download the accompanying source code for this article, click here.
BizTalk 2004 with the .NET Framework
Although BizTalk 2004 has more extensive Web service support than its predecessor, its support has some limitations. You can overcome the limitations using the .NET Framework by wrapping the Web service in a .NET assembly. Once you've wrapped the code in an assembly, you can use it in an Orchestration Expression or even BizTalk Business Rules.
About the Author
Jeffrey Juday is a software developer with Crowe Chizek in South Bend, Indiana. He has been developing software with Microsoft tools for more than 12 years in a variety of industries. Jeff currently builds solutions using BizTalk 2004, ASP.NET, SharePoint, and SQL Server 2000. You can reach Jeff at email@example.com.