Tech Ads
Back to Article List
Originally published January 2006 [ Publisher Link ]
BizTalk Server: Microsoft's SOA building block
The enterprise software market for products delivering service-oriented capabilities is a crowded place, many companies offer the same end result yet all of them use differing jargon and marketing terms to differentiate themselves from the competition. Microsoft, has also entered the thick of things with a product that will prove to be at the center of service-oriented architectures: BizTalk Server.
To place BizTalk Server in the context of competing technologies and the usage scenarios for which it was designed, let's part from Microsoft's definition: An integration and business process server.
Integration in this case refers to the capabilities of bridging disparate applications in order for them to communicate with each other, through the use of business rules or transformations, and accommodate the formats required by the involved parties.
This approach is rooted in the concept of EAI (Enterprise Application Integration), where earlier generation products -- such as messaging systems in the form of Microsoft Message Queuing (MSMQ) -- handled the workload of bridging disparate platforms.
But with the emergence of Web-enabled applications, the demand to offer interoperability amongst different EAI vendors and the bigger push to offer reusable application blocks in the form of services to reduce overall software organizational costs, Microsoft developed BizTalk server.
If you follow other enterprise software vendors -- such as IBM, BEA, Oracle or Sun Microsystems -- BizTalk's target market might seem strikingly similar to another product being pushed by these other large vendors, named ESB (Enterprise Service Bus).
Though the official Microsoft stance is that BizTalk server is not an ESB, technically speaking they are very much a like, since both provide a bus-like architecture into which requests are funneled, business rules get applied through some high level mechanism -- not standard programming code -- and finally dispatched onto the appropriate end points.
BizTalk server's architecture is also composed in much the same way as an ESB, by adapters, pipelines and a business rules engine.
Adapters are what allow BizTalk server to process requests from various platforms and protocols, among its basic adapters are those corresponding to SOAP, MSMQ, HTTP, SMTP, SQL, EDI & File formats and in the latest 2006 BizTalk version a gamut of ERP adapters are also available for brands like SAP, Oracle/JD Edwards/PeopleSoft and Siebel.
Pipelines on the other hand define the processing sequence that must be undertaken by BizTalk server in order to convert any given message request received by an adapter and transform it into a readable state for the server's internal engine -- which is XML based –- and later retransform the message into whatever format the receiving application is expecting. In general terms, BizTalk server has two types of pipelines: Receiving and sending, which are used to process incoming and outgoing requests, respectively.
Finally, the business rules engine is what allows BizTalk server to orchestrate the series of incoming requests and transform them through high-level processing instructions for later channeling to the appropriate receiver. These high-level processing instructions can be specified either through BPEL directly or by graphically bound wizards which expedite and simplify the orchestrating process.
Even though the similarities between some ESB's and BizTalk server are evident there is one underlying distinction that makes BizTalk -- or one could argue Microsoft's approach -- very different. That would be BizTalk's tightly designed companion, WCF (Windows Communication Foundation).
In an earlier column on WCF , we addressed how WCF is Microsoft's approach to unifying all of its distributed technology API's under one programming model. This approach allows WCF by itself to achieve many of the functionalities an ESB platform brings to the table.
Since WCF contains all of the necessary foundations to interpret any Microsoft distributed technology, including .NET remoting, ASP.NET Web services (ASMX), as well as WS-* standards. The transformation mechanisms present in a middleware tier like an ESB or BizTalk server can be bypassed, since each end point using WCF can interpret varying degrees of distributed technologies.
However, where WCF starts to show its limitations, BizTalk server picks up the slack. WCF clearly assumes that you will be doing serviceable designs in a 'from scratch' manner. Not only that, it also assumes all interactions will be done in a point-to-point fashion and with Microsoft technology all around.
For these aforementioned scenarios, BizTalk server can address such needs -- orchestrating applications that require communication to multiple address points, bridging communication between various non-Microsoft technologies and inclusively leveraging the newer WCF application programming model to plug into existing software assets.
As you might realize, there is a blurry line between what BizTalk server and other ESB solutions can achieve in terms of service-oriented architecture, especially since, depending on the circumstances, WCF/Indigo can achieve a serviceable design while avoiding the use of a bus-type middleware like BizTalk or ESB all together.
However, it is clear that BizTalk server along with WCF will play a pivotal role in organizations that have existing investments which need to be enabled to form a service-oriented architecture and plan on stacking newly minted services using a fresher programming model.