Endpoint Manager and Message Agent
As BizTalk developers know, receive, business processing, and
sending messages, occur in the process space of a Host Instance.
In this post, I'm interested in the
receive and send processing:
Starting at the receive end, BizTalk Messaging Engine –
also called Endpoint Manager or EPM – is responsible for hosting the receive
port including the adapter and the pipeline.
The adapter picks the message from the wire and passes it
to the Receive Pipeline. Within the pipeline, the message passes through the
various components. Finally an optional map can be used to transform the
message before being sent to the MessageBox.
The Message Agent sub-service – hosted within the
BTSNTSVC runtime process - then passes the message to the Host queue for
publishing into the Message Box.
The Host queue is represented by a set of tables inside
the messagebox database. Each new host you create will have these tables
created. For example, these are the queue tables created for the default
in-process and isolated hosts:
So, the message finally is stored inside the messagebox.
At this stage, note that the message context and message
parts are stored in the messagebox…
The MessageBox also holds subscription information.
These are the criteria that specified which endpoints are subscribed to
receive published messages. For example, for a message published by the receive
port, which orchestrations or send ports are subscribed to get this message.
Now at the send end, the Message Agent is periodically
checking the subscriptions, and when it finds a send port whose subscribed to
the message, it passes the messages to an optional map for transformation. Then
the send pipeline gets the message which again goes through the components,
before being sent via the adapter to the wire. Again the EPM is responsible for
hosting the send port including the adapter and the pipeline.
The MessageBox
The MessageBox is the database which holds crucial
information for the functioning of BizTalk architecture. This includes:
--messages and their constituent message parts.
--Message context
--The subscription information required for the
functioning of the publish and subscribe model. This includes a set of stored
procedures that contain the logic for subscription matching.
--Persisted Orchestrations state
--Tracking data. The messagebox holds
tracking information until they are moved into the tracking database.
Note that, as I showed you in the previous diagram, The
Message Agent is the only way for any other BizTalk components to interact with
the MessageBox. So practically, the MessageBox is abstracted by the Message
Agent, which is the only component allowed to talk directly to it:
Content-Based Publish and Subscribe Model
BizTalk messaging is based on the Content-Based Publish
and Subscribe Architecture
The architecture says that:
--Systems that want to get messages, will have to
register – or subscribe - their interest
--This subscription is based on certain criteria; for
example, a subscriber might say that I want all messages of a certain type, or
messages that came from a certain receive location such as a FTP, or messages
that were transmitted over a certain protocol such as HTTP…and many other
subscription criteria. Of course a subscriber might subscribe over a
combination of criteria, for example, to get messages of a certain type that
were received on a specific FTP location.
--Now when messages are posted – or published – into a
message store. Their subscription criteria is evaluated; and accordingly the
messages is delivered to those subscribers that match these criteria.
This architecture has 2 important characteristics:
--The nature of asynchronous messaging in this
architecture, means that publishers and subscribers are not directly connected;
--and publishers do not know ahead of time what endpoints
will subscribe to their messages.
How BizTalk Implements Pub-Sub
BizTalk implements the content-based publish and
subscribe model, using the following components:
First, the content upon which the subscription criteria
are set, comes from message context. There is a dedicated section for this
topic, but as a high level look, context properties are message metadata that
can be either
--system or user-defined
--system context properties are created (or more commonly
known as promoted), using receive adapters and pipelines. Data such as receive
port name, or the transport type, are examples of such system context
properties
--user context properties are defined by developers, and
they represent information of interest for the sake of application processing;
for example the PO Number or the number of records of a repeating element.
Note that relying on context properties to define
subscriptions is a concept known as Content-Based Routing or (CBR)
The next element required to implement the
publish-subscribe architecture is a store for messages to be published to, and
for subscription criteria to be stored in. This element in BizTalk is
represented by the MessageBox database. Also
the Message Agent, evaluates these subscriptions and deliver messages to the
intended subscribers.
Finally, publishers and subscribers in BizTalk are
represented by receive and send ports, as well as orchestrations. The role of
components might vary between a publisher and a subscriber, based on the
scenario.
I will elaborate on this in the next section.
Publishers and Subscribers
So, the thing that’s obvious, is that Receive Ports
are always publishers. Receive ports never get messages from the MessageBox.
They always receive messages via adapters, and publish these messages into the
messagebox.
Orchestrations, can be both publishers and subscribers. When an Orchestration is expecting a message via a Receive Shape, then its
playing the role of a subscriber.
On the other hand, when an Orchestration is sending a
message via a Send Shape, its playing the role of a publisher.
In the case, where an Ox is calling another Ox via the
Call Ox shape; in this case, the caller Ox is the publisher, while the called
Ox is the subscriber
Orchestrations also appear in an interesting scenario;
which is called Direct Binding.
In direct binding, you do not bind logical
ports within an Ox to any physical ports. Instead when using direct binding,
Oxs exchange messages between each other without the involvement of physical
receive and send ports.
In this model, an Ox publishes a message which is
either targeted to a specific Ox, or to any Orchestration matching specific
filters. You can think of this, as an “internal” publish and subscribe
architecture.
There are 3 types of direct bindings, but a detailed discussion is outside the scope of this post.
Send ports can play the role of a publisher, in case of
a Solicit-Response send port. Solicit-Response means that the port is sending a
message and expecting a synchronous response from the destination application;
for example from a request-response WCF service. In this case, the response
message coming back to the send port will be published into the MessageBox.
Other than that, Send ports play the role of
subscribers; as they subscribe for messages that then are sent out to the
target destinations.
Subscription Types
When the subscriber is an Orchestration, there are two
types of subscriptions:
--The first type, is called Activation Subscription. This
means that a message, when received by the subscriber – or the Orchestration –
will start new instance of that Orchestration.
--The second type, is called Instance Subscription. This
means that message is handed to an existing instance of an already running
Orchestration instance.
For example, lets say that you have a PO Orchestration.
When the PO message is received for the first time,
this kicks in a new instance of the orchestration; this is called Activation
Subscription.
Now assume later in the process, that a confirmation
message from an inventory system is required before the process can continue.
This inventory message is given to the already running instance and will not
activate a new instance. This is called Instance Subscription.
No comments:
Post a Comment