官术网_书友最值得收藏!

Design patterns within the BizTalk architecture

In addition to being a great application server, BizTalk serves as a model in application architecture and design. The following sections explore some of the architectural features of the product itself ranging from core precepts to more subtle implementation details.

Messaging

Messaging has become an overloaded term in technical parlance these days. You can ask different parts of the technical (IT) community what messaging means and get very different answers. Almost all of them legitimate. To some, messaging represents e-mail and instant messenger or human communication. If this is the camp you find yourself in, I am afraid you have purchased the wrong book. Increasingly, messaging means an interaction between parts of a software system. Today these are generally distributed systems, but that need not necessarily be the case. A quick read of Grady Booch's seminal work, "Object Oriented Analysis and Design with Applications", Addison-Wesley Object Technology, will show that, even in early OOP, the concept of a client and server were well understood; though they almost assuredly were parts of the same executable. Booch goes as far as using the term message to describe the call from a client to a server (client and server are also used in a different, but very appropriate, context from what we would understand today). In this way, we can see that what messaging and middleware are doing is not necessarily a radical departure from traditional programming paradigms, but an evolutionary step into a more robust and distributed incarnation.

As Phil Boardman once proclaimed to me during his journey deep into WCF: "The message is the unit of work". This is an important proclamation because it bridges a divide between traditional software design patterns and distributed computing. We'll dig deeper into this as we go on and see exactly how significant this statement is in terms of BizTalk, but for now it is enough to remember that a message is an encapsulated payload of meaningful data normally having associated metadata.

On this note, it is probably appropriate to explain how messaging in our context of modern distributed systems differs from messaging of old. Although Booch may have seen setting the properties of a class as messages, those would not be meaningful in a distributed software environment. These types of messages would be neither meaningful nor self-encapsulated. In order to be both meaningful and self-encapsulated, such a message would have to contain the entire object (which would violate some OOP principles including the Law of Demeter). This is an aspect where distributed/message-oriented development can appear to deviate from OOP practices. Most often, in practice, the Data Transfer Object is the pattern used to reconcile these differences.

Messages can be commands or CRUD operations or simply status updates, but as the definition says, they should be meaningful and encapsulated. A Purchase Order, let's say (in XML format) would be a great example of a message. In the service context, the Operation (or Action) to which the Purchase Order is sent would determine what is to happen to it. There are many schools of thought on message and schema definitions or designs, and it is important to strike the right balance for your organization between flexibility and control, but that is a topic for another conversation.

Publish Subscribe

It is important to point out that Publish Subscribe is predicated upon messages being published, that is to say, to external sources sending messages in. This is perhaps one of the more difficult concepts for many developers to embrace with BizTalk. BizTalk is not a proactive or imperative (procedural) environment like Java, C#, or most programming languages; it is a reactive one. BizTalk never starts processes on its own; it may start complex processes based upon specific messages being received, but it does not have the concept of a traditional application starting point. There is no "Hello world" in BizTalk. Frankly, "Hello world" is a concept best left to introductions to computer programming.

In a traditional procedural/imperative environment, the starting point of an application is often similar to the following:

  1. Look for input.
  2. Decide what to do with the input.
  3. Send the data to whatever destination is determined to be the recipient.

This pattern is pictured as follows:

In most implementations, parts 1 and 2 are in the same process. This results in each sender (step 1) needing to be aware of each possible recipient. Even if implemented in clever ways, such as recipient list, the result is implicit coupling from the source to the destination. Also troublesome is the fact that the router is normally replicated in many places throughout the enterprise, often via unique implementations in each system that is being integrated. This is a colossal opportunity for reuse that is missed in most organizations. Some try to leverage this with home grown solutions or open source platforms that can fall far short in the long run. The previous pattern violates loose coupling principles for both service and object-oriented methodologies.

Publish Subscribe overcomes these limitations by almost completely turning this model around. In the Publish Subscribe model, the sequence of events is as follows:

  1. Subscribers enlist (or enter) their subscriptions (what they're interested in).
  2. The Subscription Manager tracks these subscriptions.

The sending system (Publisher) sends a message (it is now done) and the Subscription Manager matches the subscription list, forwarding each subscriber its own immutable copy of the message.

The Publisher (sender before) is now completely unaware of which systems are interested in the message it is sending. Further, the Subscription Manager not only abstracts away the recipients, it also abstracts away the state of those destination systems. Filled subscriptions can simply await their delivery long after the sender has completed sending its message. If there are no subscribers, it is really not the concern of the sending system, but of the Subscription Manager.

A primary goal of Publish Subscribe is to move away from point to point and synchronous architectures and towards loosely coupled asynchronous interactions. Publish Subscribe goes a long way towards making loose coupling a first class concept in software.

BizTalk embraces Publish Subscribe so fully that there is actually no such thing as a synchronous request in BizTalk. We can make services or endpoints appear to be synchronous, but they are in fact asynchronous.

Adapter

Adapters are a core concept of BizTalk. Adapters allow us to bridge different systems together through common experiences and tools. The adapter pattern has a readily understandable implementation in the wider software world: ODBC. Most developers have at least some experience with ODBC (or JDBC). These are adapters to the underlying database they connect to. Although connecting to SQL Server, Oracle, or MySQL are all done in a fundamentally different way, the ODBC driver (really it's an adapter) allows us to connect to all of these data sources and more. BizTalk uses adapters for all endpoints, in and out, of a solution. In this way, no matter the platform outside of BizTalk, inside everything is a common platform and is almost all XML.

Streaming

Streaming is another critical architectural principle in BizTalk, but thankfully it is one that many developers will never need to work with directly. With very few exceptions every component in BizTalk is a stream-based component. Pipelines and maps use streaming to handle messages in BizTalk. This means that stream classes are chained together in the framework so as to avoid large memory buffers. This is one of the concepts I struggled the most with early in BizTalk, but it is also so critical to the scalability of the platform.

Instead of loading an entire message into memory, BizTalk loads a piece of it—normally only a few kilobytes. Then, each class in the chain of classes involved in mapping and pipeline processing calls the Read operation on the next in the chain, passing this small buffer between them, making their requisite changes along the way. The ultimate motivation behind this is to keep a flat memory footprint for the process. Even with relatively small messages, a high volume system will quickly consume large amounts of memory if loading entire messages. The larger the messages, the faster this becomes problematic. For very large messages that have operations requiring large intermediate buffers, BizTalk will even stream to disk as needed, to save memory.

These stream classes are some of the most impressive parts of the BizTalk framework and something many in the .NET world have been eagerly awaiting.

主站蜘蛛池模板: 行唐县| 嘉峪关市| 岳普湖县| 栾城县| 德化县| 轮台县| 师宗县| 商城县| 北安市| 小金县| 同江市| 眉山市| 崇明县| 聂拉木县| 静安区| 枣强县| 肇庆市| 额敏县| 清苑县| 宝鸡市| 城步| 茌平县| 壤塘县| 墨竹工卡县| 北宁市| 平邑县| 佛冈县| 皮山县| 馆陶县| 财经| 房产| 乐安县| 富锦市| 汕尾市| 远安县| 江城| 剑河县| 夏邑县| 曲阳县| 化州市| 华容县|