MSDN Magazine - August 2008 - (Page 63)

Figure 6 Configuring Base AS2 Properties the HTTP adapter. When documents arrive over HTTP, BizTalk first compares the information to the AS2 settings, then opens the EDI document. The EDI document is then routed just as if it had arrived through any other method. AS2 simply provides a secure way to transfer the data and any relevant envelope information. Document Delivery through a Firewall An important concept to illustrate is how documents can be delivered to BizTalk Server on networks where BizTalk is behind a firewall and not available to the public. When a SOAP or HTTP receive port is added to BizTalk, the port will operate on the local IIS server, and all posted data will need to be posted to that local Web server. For example, when using the BizTalk Web Services Publishing Wizard, the Web service can be created only on the local IIS server where BizTalk Server is installed. In an environment where this IIS server cannot be accessed from outside of the network, some sort of solution must be put into place to allow communications to be routed (see Figure 7). There are several solutions, including placing BizTalk Server Public Network in the public portion of the network or creating a reverse proxy that routes requests through a firewall and allows BizTalk to reside in a private portion of the network. Internet Communication through the firewall can be made programmatically as it is rarely acceptable to house BizTalk Server in a publicly accessible portion of a IIS Server network—the security risks are simply too high. There are several approaches that can be taken in the development of the Web service on the public Figure 7 Document Delivery through a Firewall msdnmagazine.com IIS server in the public network. One is to create a gateway Web service. Another is to create a proxy Web service. The gateway Web service requires custom coding, just like any Microsoft®.NET Framework Web service, and complex transformations of interfaces to match those that BizTalk expects. The gateway accepts a request from the public and maps it to a request to the Web service behind the firewall. A proxy Web service, on the other hand, can be created by modifying what is produced using the BizTalk Web Services Publishing Wizard and placing the copy on the public Web server. Due to its simplicity, modifying a proxy Web service seems like the clear choice. To create a proxy Web service, launch the BizTalk Web Services Publishing Wizard. Click on the appropriate options in the wizard and define where the Web service will be published (notice that the only option for where the virtual directory is created is on the local IIS server). When the wizard creates the Web service, it is actually creating a proxy that redirects incoming calls from IIS and places them in the BizTalk MessageBox where they can then be routed to the corresponding orchestration. This proxy Web service is coded automatically, and everything is preconfigured to work without additional user changes—as long as the incoming posts come directly to this Web server. Enabling posts to come in on a public portion of the network and be routed to this Web service requires three basic steps. The first step is to create a proxy-to-the-proxy Web service. When a Web service is exported via the wizard, BizTalk refers to it as a proxy Web service. In order to call this Web service from external clients, a proxy Web service must be created on a public server that can route requests to it. This can be done by creating a virtual directory on the public IIS server with the exact same name and interface as the generated proxy. Once the virtual directory has been created, copy all of the generated files from the original BizTalk IIS directory to a virtual directory on the public server. The second step is to modify the public-facing Web service so that, instead of posting the incoming SOAP information to the BizTalk engine, it reroutes the information to the internal proxy Web service on the IIS server hosting BizTalk Server. The code to Private Network BizTalk Server 2006 R2 August 2008 63 http://msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - August 2008

MSDN Magazine - August 2008 Toolbox CLR Inside Out Basic Instincts Cutting Edge Patterns in Practice Data 2.0 - Expose And Consume Data In A Web Services World Biztalk EDI - Build A Robust EDI Solution With BizTalk Server Silverlight - Create Animations With XAML And Expression Blend Write On! - Create Web Apps You Can Draw On With Silverlight 2 Wicked Code - Craft Custom Controls For Silverlight 2 Team System Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - August 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.