By the time you read this, BizTalk Server 2004, the third version of BizTalk, will have been released. As you can see by the articles in this special issue of .NET Developer's Journal, this is a very important product release, and it is poised to have a profound impact on how developers create enterprise applications.

At the same time, 2004 is "The Year of Web Services" - again. Unlike the past couple of "Years of Web Services," this time it's for real. Most of the required standards have been released or at least defined, all the infrastructure pieces are falling into place, and architects and developers are starting to chant the services-oriented architecture mantra.

These two events are going to converge, the result being a very powerful toolset that can be brought to bear on application requirements.

There are three primary ways BizTalk Server 2004 can be used in conjunction with Web services:

• Orchestrating Web services
• Exposing orchestrations as Web services
• Invoking Web services as part of message processing

Overview
Visual Studio .NET and tools for non-Microsoft platforms have made it increasingly easy for developers to expose application and business functionality as Web services. In addition, developers are increasingly using Web services for interoperability, building Web services layers on top of their enterprise applications. In the ideal services-oriented ecosystem, applications would expose functionality as services, which would in turn be aggregated and composed into applications in order to meet business needs. As business requirements change, these services would be recombined in other configurations to meet the new needs. This sounds elegant and efficient, but requires that we have some higher-level "controller" to perform the aggregation. Enter BizTalk Server 2004 orchestration, a business process automation engine that is also quite adept at orchestrating the handling of messages. (BizTalk Server 2004 has two main functional components: orchestration, and the messaging engine. This article will focus on orchestration.)

BizTalk Server 2004 is tightly integrated into the Visual Studio .NET environment, making it possible for BizTalk application developers to perform most of the tasks they need to do, from design through deployment, without leaving Visual Studio. As is the case with SQL, BizTalk server management tools are available inside Visual Studio (as well as stand-alone, for use by system administrators). When you install the BizTalk Server development environment, it adds a new project template. To create a BizTalk project, it's as simple as selecting File|New|BizTalk Server Project. Project items and variables associated with the BizTalk project are accessible via the Visual Studio Solution Explorer tab.

An orchestration can be thought of as a process - a step-by-step sequence of actions. To design orchestrations, BizTalk provides a visual Visio-like design surface, fully integrated into the familiar Visual Studio .NET environment, that allows developers to drag-and-drop orchestration elements from a toolbox, much as they would while designing a form. Available shapes include advanced capabilities such as decisions, parallel tasks, loops, and transactions. To fully address all of the orchestration shapes and their functionality is beyond the scope of this article. However, rest assured that the provided shapes should be sufficient to provide the building blocks required to model most business processes. Later in this article we will look at a simple orchestration.

The need to orchestrate Web services and business processes is not unique to .NET developers. There is an emerging XML-based open standard - coauthored by Microsoft, IBM, and others - called BPEL (Business Process Execution Language) that meets this need. BizTalk Server 2004 has the ability to import and export BPEL files, thereby ensuring compliance with this new standard.

Talking to the Outside World
We've just seen that BizTalk offers us a powerful orchestration engine. In order to be truly useful, we need a way for the orchestration process to communicate with the outside world. This role is played by ports and adapters.

In a BizTalk orchestration, a port is an entry or exit point from the orchestration itself. It is a way that the orchestration engine can pass a message to something outside of itself. Conceptually, an adapter is just a transport mechanism that performs the actual message movement. BizTalk Server 2004 ships with several adapters, such as file, SOAP, and SQL, and there is also a thriving third-party market offering adapters for a broad range of enterprise applications, from vendors such as J.D. Edwards, PeopleSoft, SAP, and more. The ability to consume Web services from inside a BizTalk orchestration is provided by the SOAP adapter.

In order to consume a Web service in an orchestration we need to know what its capabilities are. We do this by reading a reference to the WSDL it exposes. This is done using the same "Add Web Reference" technique that Visual Studio developers use to add a reference to a Web service in any other type of project.

Consuming a Web Service
For demonstration purposes, it is very common to use files as an input and output mechanism for BizTalk orchestrations, as I will demonstrate in this article. These input and output points could also have been coming from or going to any application or endpoint that you have an adapter for.

BizTalk port endpoints can be late-bound, and then specified by an administrator after the orchestration has been deployed, which means that you can change the endpoints without needing to change the orchestration itself. In the context of the example application shown below, this means we can define at runtime the file input and output locations, as well as the Web service URI. This is a powerful technique that lends itself well to orchestration reuse. As the Web service can be specified on the server after deployment, you can change the Web service you are invoking without changing the orchestration itself.

Figure 1 shows a very simple orchestration. The orchestration starts when a file appears in a folder. It then calls a Web service and deposits the Web service response message in another folder.

Without going into all the details of each step, here is what's going on in this orchestration:

• The first shape is a Receive shape. We need something to activate an instance of this orchestration, and we use the Receive shape for this. It is bound to a file receive location that is monitoring a specific file folder. When a file is placed in the folder, a new orchestration instance is created, and the file is imported into the new orchestration through the receive port on the left-hand port surface, and through the Receive shape.
• The second shape is a Message Assignment shape. This is where we take values from the incoming message (the data that was in the file) and assign them to a Web service request message.
• The third shape is the call to the Web service. The communication pattern we've specified here is request-response, but it could have been fire-and-forget.
• The fourth shape receives the Web service response.
• The fifth shape is a Send shape that deposits the Web service result as a file in a folder specified by the send port.

Exposing Orchestrations as Web Services
BizTalk orchestrations are instantiated by external events, such as a file appearing in a folder, a record appearing in a database, being called from another orchestration, direct invocation from another process, etc. Wouldn't it be nice if we could take an orchestration and expose it as a Web service? If we did that, then we could expose a WSDL file, and anyone that could consume that Web service would be able to call our orchestration.

The good news is that it couldn't be much easier to do this. Even better news is that there is no bad news. A BizTalk Web services publishing wizard walks you through the process. There are two entry points into the wizard: a Start menu entry and the Tools menu inside Visual Studio.

Running the wizard will create a standard .NET C# Web service project that acts as a proxy to your orchestration. The wizard examines the data types of the messages going into and out of (if applicable) your orchestration, and uses them to generate the appropriate WSDL file. There is no magic here, the wizard is just generating code for you that you could write yourself - and that you can modify.

You can have multiple ways to activate the same orchestration, which is a simple, yet incredibly powerful, technique. For example, we could have a credit check orchestration. This orchestration may be called when a file appears in a folder - or we could expose the same orchestration as a Web service and invoke it from our CRM system.

You can see how this has the potential to streamline operations by leading to the development of a standardized suite of business processes that may be invoked from several different applications, and that can be composed into different higher-level aggregations to meet multiple business needs.

Invoking Web Services as Part of Message Processing
When a message enters or leaves BizTalk Server 2004, it flows through a pipeline. Using a pipeline designer integrated into the Visual Studio environment, developers can define custom pipelines to accommodate their specific message processing needs. This includes being able to call their own components as part of the message processing. Web services could play a role here too. As part of message processing, you can consume Web services. An example of this would be a system that receives a purchase order and calls a Web service that logs the receipt of that order to a customer service SharePoint site.

Performance is an important consideration here. Ideally, pipelines should execute as quickly as possible. If you introduce high-latency operations into pipeline processing, you could be adding a significant bottleneck to your message throughput capabilities.

In addition, the messaging engine can receive a message on a port and transmit it on another port without any involvement by an orchestration. Either one of these ports could be a Web service.

InfoPath and BizTalk Orchestration
InfoPath is the newest member of the Microsoft Office family of products. An InfoPath form can be thought of as a self-contained chunk of smart data. It contains form data, schemas specifying metadata about the data, and a reference to a template that defines how that data should be displayed. InfoPath provides a rich form-design and form-filling environment.

It's often been said that InfoPath is to BizTalk Server 2004 what Outlook is to Exchange, and I fully agree with that comparison. InfoPath forms can be configured to submit their data to a Web service. The data being submitted is XML that conforms to a known schema. As we just saw, BizTalk can expose an orchestration as a Web service. In addition, BizTalk understands schemas. So it's a logical conclusion that we should be able to post an InfoPath form to a BizTalk orchestration schedule - and that conclusion would be correct! This is my favorite aspect of BizTalk Server 2004, and from a business standpoint, one of its most powerful and compelling features.

In order to create a new InfoPath form that can submit form data to a BizTalk orchestration, follow these simple steps:

• Create an orchestration that has a public receive port (a receive port must be public to be exposed as a Web service) with Activation set to true.
• Use BizTalk's Web services publishing wizard to expose your orchestration as a Web service.
• In InfoPath, specify that you want to create a new form from a data source. Specify a Web service as the data source, and that you want to submit data to the Web service.
• Enter the URI of the Web service proxy that was created by the Web service publishing wizard. InfoPath will query the WSDL.
• After reading the WSDL, a schema will be created in the InfoPath designer, and you will be able to design your form.
• Preview the form, fill in data, and choose File|Submit from the menu (when you create an InfoPath form from a Web service it will automatically fill in that URI as the endpoint for form submission).

• Created a business process
• Exposed it as a Web service
• Defined a form, based on the Web service, that acts as an entry point into the business process

Conclusion
This article has shown you how BizTalk Server 2004 works in conjunction with Web services. We have seen how orchestrations can consume and aggregate Web services. We've seen how BizTalk orchestrations themselves can be exposed as Web services. Last, we looked at how InfoPath can be used as a front end to BizTalk orchestration by posting form data to a process that has been exposed as a Web service.

BizTalk Server 2004 is a powerful new tool for enterprise architects and developers to use as they forge ahead into the new services-oriented world.