Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Enterprise Application Integration with Microsoft BizTalk Server 2006, Part 2 : Page 5

Walk through this simple but common integration scenario to find out how to include BizTalk Server 2006 in your own application integration projects.


advertisement
Deployment
In BTS 2006, an Application is a group of related artifacts (orchestrations, pipelines, resources, etc.) that are managed as a single unit. When deploying a solution, you can choose the default BizTalkApplication 1 application, or create your own.

BTS 2006 offers two options for deploying BizTalk applications. In production deployment scenarios, the most common is via the BizTalk Server 2006 Administration Console, which is an MMC snap-in style administrative console. During design time, however, developers may use BizTalk Explorer, which provides a light version of the BizTalk Server 2006 Administration Console for use within the Visual Studio IDE.

Using Visual Studio 2005 to Deploy a BizTalk Application
Remember to always use implicit casting of the interfaces to keep the calls type-safe.
In practical terms, it is very unlikely that a solution will use the BizTalk Explorer for deployment chores outside the local development environment. Often an organization will use BizTalk Server on single or multiple server class machines that are separate from the development environment. BizTalk Explorer does not lend itself well to distributed deployments; however, for developing locally it is the perfect tool to deploy and test a solution and will help to isolate some of the complexity inherent to using the fully featured BizTalk Server Administration Console.

  1. After successfully building the entire solution, right-click on the Northwind.BusinessWorkflows.RetailOps project and click Deploy. The project DLL is deployed to the GAC and appropriate entries are made into the BizTalkMgmtDb database.
  2. Next, install all remaining assemblies from Table 2 to the GAC. Remember that these assemblies must be strongly named. Again, you may use the existing Northwind.snk file or use your own if you wish.
At this point the example orchestration is not very useful. With the exception of the SOAP Port you created for the Billing Service, there is no physical correlation between the logical Send and Receive Ports and the physical endpoint(s) (adapters) that will be the interface between this application and the rest of the world.

Exposing the Orchestration as an ASMX Web Service
Deploying an orchestration as a SOAP ASMX web service is simply a matter of invoking the BizTalk Web Services Publishing Wizard. There are two options for doing this. One is to deploy an endpoint that is bound explicitly to the orchestration. Because you've defined the primary message, purchaseOrderMsg, as a serializable .NET type, exposing the orchestration directly is a perfect choice.

Note that publishing an orchestration itself as a web service may not be the best approach if you are making heavy use of XSD schema or you want to preserve XSD semantics on the incoming document. Note, however, that the trend with vendors (including Microsoft) is to abstract as much about the XML itself from the design-time experience and leave to the plumbing the task of adhering to a specific standard or schema. Although there are passionate debates over using XSD versus XML serializable types (and vice versa), anyone working heavily with XSD can testify to its cumbersome nature. That said, XSD is a very common sure-fire approach to maintaining strict control over the message while guaranteeing interoperability and is especially useful in maintaining contract-based semantics where traditional interfaces are either unpopular or unsupported. If maintaining entities/messages as XSD schema is the chosen approach, the second option will allow you to publish schema as a web service and provides more control over the naming, request, and response schema used.

 
Figure 19: Using the BizTalk Web services Publishing Wizard, an orchestration can be easily exposed as an ASMX SOAP endpoint.
Since you've opted for exposing the orchestration directly, choose the first option below:

  1. To start, under Tools, click BizTalk Web Services Publishing Wizard and click Next.
  2. Choose the first option (Publish BizTalk orchestrations as web services), as shown in Figure 19 and click Next.
  3. On the next screen, select the Northwind.BusinessWorkflows.RetailOps.dll assembly and click Next.
  4. On the Orchestrations & Ports step, check the option to merge all Ports into a single ASMX service definition, and proceed to the next screen.
  5. For the namespace, enter a valid URL in the textbox such as "http://NorthwindTraders.com" and click Next.
  6.  
    Figure 20: Publishing details such as location, security, and BizTalk Application are configured via the BizTalk Web services Publishing Wizard.
  7. Replace the default Location entry with a cleaner name such as http://localhost/Northwind.Services.RetailOps. Enable anonymous access and select the option to create a physical Receive Location in the BizTalk Application 1 application. Figure 20 summarizes these options.
  8. On the final screen, click Create to deploy the SOAP service interface to the local IIS web site.
This results in the deployment (and creation) of an IIS application that hosts the Northwind.Services.RetailOps web service. If you followed the naming guidance, the URL should be:

http://localhost/Northwind.Services.RetailOps/ WebService_Northwind_BusinessWorkflows_RetailOps.asmx

Navigating to the URL loads a familiar WSDL discovery page as shown in Figure 21.

 
Figure 21: Browsing to the URL after publishing of the service via the BizTalk Web services Publishing Wizard is complete reveals a familiar discovery Web page.
Binding the SOAP and File Drop Locations
Thanks to the indirection provided by the logical ports, you can begin by supporting the submission of purchase orders via HTTP SOAP. You can leverage this same indirection to support additional protocols and file formats.

At this point, the only thing left to do is associate the logical ReceivePurchaseOrderPort and SendPurchaseOrderPort with the respective HTTP URL and physical file drop URI.

  1. Within Visual Studio, click View and select BizTalk Explorer. Expand the Orchestrations folder and select the Northwind.BusinessWorkflows.RetailsOps Orchestration as shown in Figure 22.
  2.  
    Figure 22: The BizTalk Explorer is a one-stop show for managing BizTalk artifacts from Visual Studio.
  3. Within the Orchestrations folder, right-click the Northwind.BusinessWorkflows.RetailsOps Orchestration entity and click Bind. Under InBound Ports, select the Receive Location created by the BizTalk Web Services Publishing Wizard. This connects the logical ReceivePurchaseOrderPort Receive Port with the physical SOAP/ASMX endpoint created by the wizard. Click OK to close the Port Binding Properties.
 
Figure 23: The FILE Transport Properties dialog box allows you to specify the destination folder for file drops.
Now you'll correlate the logical SendPurchaseOrderPort with a physical Send Port.

  1. Right-click the SendPorts folder ,and click Add Send Port. Select the Static One-Way port. In the Static One-Way Send Port Properties window enter FileDrop for the Port Name, choose FILE as the Transport Type, and enter a URI of C:\Outbound\CompletedPurchaseOrders (or something similar) as shown in Figure 23. Click OK.
  2. In the tree view on the left pane, under Send, set the Send Pileline property to use the Microsoft.BizTalk.DefaultPipelines.XMLTransmit Pipeline, and click OK to exit.
  3. Open the orchestration bindings and configure the logical SendPurchaseOrderPort to use the physical FileDrop Port you just created.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap