The
easiest way to link orchestration with messaging endpoints is to create
logical ports in orchestrations and bind them to physical ports at
runtime. A developer using this technique will know for sure that an
orchestration will exchange messages with the appropriate ports.
However, this mechanism of orchestration communication is more
point-to-point oriented than event driven. What if relevant messages for
an orchestration could arrive via multiple receive ports? Or how about
trying to anticipate all the possible parties interested in a message
that your orchestration is sending out?
The tight coupling produced
by binding orchestration ports to physical ports is not the most
service-oriented way to design orchestration communication. Instead,
MessageBox direct binding is the cleanest way to sever the one-to-one
relationship between the messaging and orchestration architectural
layers. The way it works is that the "activating" receive shape that
instantiates the orchestration maintains a subscription based on the
message type in combination with any "filter" applied to the receive
shape. ANY message that hits the MessageBox and meets this subscription
criterion will get delivered to this orchestration. For any
"non-activating" receive shape (such as receive shapes present elsewhere
in the orchestration), the subscription is based on the message type
and a correlation set made up of additional subscription attributes.
The greatest benefit of this
technique is that orchestrations can absorb messages that match specific
data criteria instead of focusing on the data publisher. When sending
messages on MessageBox direct bound ports, we get the benefit of
broadcasting messages without identifying an individual target. There are cases where you want to use
MessageBox direct binding but still need to target a specific consumer
and this is entirely possible.
How do you apply
MessageBox direct binding? When creating a new orchestration receive
port, you get the option of choosing a target binding. In the book so
far, we've typically used a Specify later
binding, which allows us to hook up logical and physical ports at
deployment time. However, notice that we also have the option to choose Direct binding from this orchestration port creation wizard.
When creating orchestration send ports, we get a similar experience when choosing direct binding.
For orchestrations that use
direct bound ports, you will see a much different "binding" view in the
BizTalk Administration Console. Specifically, you'll notice that there
are no ports to bind! The only activity required is the binding of the
orchestration to a specific host.
Throughout this article,
we'll make heavy use of MessageBox direct bound ports in order to
demonstrate this technique in a variety of scenarios.
Pitfall
What's the downside of
MessageBox direct bound ports? For one, careless usage can lead to
unanticipated messages reaching your orchestration or worse, infinite
loops. Consider an "activating" receive which is direct bound solely on
the message type (i.e., no additional filter applied). If you decide to
send this same message out of your orchestration later on (via ANY type
of port binding), you will unexpectedly find that this original
orchestration starts up all over again! The proper application of direct
binding requires forethought of subscription criteria and situational
modelling of instantiation scenarios.
