Publishing Schemas and Orchestrations as WCF Services in BizTalk
If there’s one problem that an integration system needs to address, it’s standardizing the format of all data being exchanged. Before any type of data can be processed or transformed, the system handling it must be aware of its format and structure. Using a service, at the client endpoint, forces the user to provide proper data that is agreed upon. This acts as a contract between the service and the client. Given a certain format of data, the client will receive another format of data in return. Anything that happens behind the curtain is the responsibility of the service; the client simply waits for the returned data set.
BizTalk WCF Service Publishing Wizard
One of the more popular tools offered by BizTalk 2010 is the WCF Service Publishing Wizard. This handy tool can automatically create a WCF service, and fully configures the bindings to distribute the integration solution from your BizTalk application. The wizard offers two options for publishing the service. The first option is publishing the BizTalk Orchestration as WCF Service, while the second is publishing schemas as WCF service.
On the client side, these two options are practically identical. However, there are minor differences between the two that offers major benefits when used appropriately. In this post, we will briefly discuss the basic concepts of the two options, on a high level. For technical purposes, here are some tutorials on publishing the WCF Services:
Publish Orchestration as WCF Service
Publishing an entire orchestration to the interface allows the components to become a tightly coupled. The service binds all of the parts from inbound schemas, to every component inside the orchestration, and all the way to the outbound schema. The binding exposes the entire end-to-end process, from a single assembly, to the service. Consider a general BizTalk process with an orchestration.
A service with a send/receive port will direct all messages to the message box, then get subscribed to by an orchestration. By publishing the orchestration, it offers simplicity of the process flow that seems like one component piece. Typically, this exposure references only a single assembly file that contains all of the necessary components within it; since the entire process is exposed to the service and is in one assembly. Any change or update to the process will require interruption to the running instance; which means redeployment, or a restart, of the service instance.
Publish Schema as WCF Service
Another method of publishing a BizTalk artifact is Publishing the Schema as a service while ignoring the rest of the process beyond the point of the receive. In contrast to exposing the entire process, along with the orchestration, the service instance will have no knowledge of any operation beyond the message box.
There is a major benefit to this type of limited exposure. The data processing stage is left open ended. This allows for more dynamic integration of the entire system. While the service references the published schemas from one assembly file, the rest of the operation can be built in other different assemblies. This limited exposure offers a uniform inbound and outbound format while creating the separation of concerns. In this case, the diagram shows multiple orchestrations subscribing to the message box.
While multiple orchestrations are possible in Orchestration publishing method, Schema publishing can use other processes other than an orchestration. Each of these components can be developed in isolation and any change or update can be applied without interrupting other components. A developer can also easily add a new orchestration to the system while keeping everything running seamlessly. During down time, when one of the components crash, the message will get suspended but can be resumed once the issue is remedied.
To learn more about BizTalk and how Tallan can help be your trusted BizTalk partner, CLICK HERE.