Monday, December 13, 2004
So, it's been a while since I've blogged. Life has been hectic and I'm currently spreading my time between two projects so blog time has been in short supply, even though my blog-to-do list is growing!
Anyway, so what is this post all about? It's about where BizTalk fits architecturally within the new "hot" world of Service Oriented Architectures.
BizTalk Server, as we know, is a middleware product that enables integration between LOB applications and systems in an EAI scenario and trading partners in a B2B scenario. As part of this broad area of responsibility BizTalk is able to execute business processes that implement complex integration or workflow scenarios, transform data from one format into another, route messages based on message metadata or actual content, perform security duties such as encryption and signing, capture tracking information for administrators or business analysts, communicate with a variety of communication protocols and mechanisms and so on and so on and so on. In short, the platform of BizTalk Server offers a complete business process and integration suite, hence the title of Microsoft's new division that is in charge of all of this stuff.
Knowing what we know of the features of the BizTalk Server platform how does that fit into an SOA world, one in which client applications "e;patch"e; together software services that provide specific business functions and offer a cohesive whole? Ultimately, why would you want to put an integration and business process engine into the mix when effectively the client is just calling a web service or two in order to offer specific functionality to a user?
Well, my belief is that BizTalk does offer value in an SOA when it is operating within 3 distinct patterns: Service Broker, Service Aggregator and Integration Enabler.
A service broker sits between the client and the web service and provides brokering services on behalf of the web service to the client. By putting a broker in between, it can act as a secure boundary that allows you to provide controlled access to internal web services. The broker might be the only supported route for consumers of an organisation's web services (see figure 1).
Figure 1: Service Broker
In addition to brokering based on security boundaries, the broker might act as a routing engine capable of determining the correct web service based on either message metadata content (such as HTTP or SOAP headers) or message content itself, in a content based routing scenario (see figure 2).
Figure 2: Service Broker using CBR
The service broker, depending on caller requirements, may operate in a request-response or one-way scenario.
If the broker operates in a request-response scenario, it is likely that it will provide some form of sync-on-async operation, as in the case of BizTalk Server 2004, in order to be able to provide a synchronous response to the client.
If the broker operates in a one-way scenario, no response is required and BizTalk Server is able to process the request in an asynchronous manner.
It may well be that a response can be asynchronously delivered, in which case the client issues a one-way request to BizTalk Server that brokers the call to the appropriate web service asynchronously (to the client), while further on in the process after a response has been received from the brokered web service, BizTalk Server asynchronously delivers a notification to the client containing the response.
Either way, BizTalk Server is used as middleware to broker calls between a client and its target web services. Introducing BizTalk Server as a broker will have performance implications due to an extra hop between two endpoints, however, the benefits of imposing a routing engine and security boundary offer an attraction to naturally security sensitive organisations that would like to expose business functionality as web services.
The service aggregator I tend to term a "super service" - a service that offers an aggregated business function view of discrete separate business functions.
In this scenario, BizTalk Server is used to consume multiple web services and aggregate their results behind the facade of a web service offering a single, probably coarse grained, business function (see figure 3). The aggregator, in effect, offers the ability to create composite applications using business process rules that tie multiple finer grained web services together.
Figure 3: Service Aggregator
Creating an aggregator, or super service, in BizTalk Server would involve building an Orchestration (the composite application logic) that enable the results from multiple web service calls to be aggregated together to provide a single response.
Indeed, BizTalk Server, in this scenario, operates as both a broker and an aggregator in one - brokering all calls to internal web services but also aggregating responses.
This pattern, I expect, will be the most oft used pattern with regards to BizTalk Server and an SOA. With the power of the Orchestration Engine and Business Rules, as well as the ability to inspect, manipulate and transform messages, BizTalk Server offers a great deal as a service aggregator within a SOA.
The previous two patterns are probably the most obvious with respect to a SOA; however, there is quite often the need to integrate with LOB applications behind the web service facade in an organisation. Just because BizTalk Server may sit between the client and the web service offering brokering and aggregation services, doesn't mean to say that its role as an application integration tool disappears - far from it (see figure 4).
Figure 4: Integration Enabler
An organisation may offer a web service that integrates both ERP and warehousing systems to external trading partners. While it is probably quite easy (depending on the interfaces into each application) to write code to achieve this integration, we get back into the mindset that we have been trying to get away from. Writing point-to-point interfaces between applications is bad! It has been proven time and again that P2P interfaces are short term and never stack up, both in terms of costs and support, in the long term.
Therefore, integrating between a web service's private implementation and LOB applications should still be achieved using an integration tool such as BizTalk Server, its bread and butter purpose.
So, in conclusion, I think that BizTalk Server 2004 fits quite appropriately into these 3 patterns of operation within an SOA. BizTalk Server itself is trumpeted as a friend to SOA with whitepapers and patterns and practices on the subject. On the whole, it isn't just marketing fluff and Microsoft is right. However, there are caveats - the most important caveat being performance and scalability. It is possible, it's just that there are pitfalls that you need to be aware of when designing architectures around BizTalk at the heart of an SOA. That, my friend, is an article for another day...
Just a quick issue I discovered the other day with one of my schemas. I added an element called timeout with some child elements to the schema (days, hours, minutes, seconds), promoted the child elements as distinguished fields and then tried to use the schema in my orchestration.
Every time I tried to use the promoted property days using myMessage.Blah.timeout.days, I kept getting a squiggly red line under timeout and days with the error: unexpected keyword: timeout, cannot find symbol ''
The issue is because the timeout name is an XLANG/s reserved keyword. Therefore, if you want to promote a field as a distinguished field to be used in an orchestration, then make sure that no elements exist that are named the same as XLANG/s reserved keywords in the path up to the root element.
When oh when will Microsoft junk XLANG/s and just use C#???