Message Flow Behavior

In this section, we review how messages flow into or out of a schedule through the ports. The XLANG Scheduler Engine, which hosts the schedule instance, manages the flow of messages in the running schedule. When an Action is performed, the running schedule intercepts messages that flow into or out of it, via a port. If the port is connected to a COM component, the schedule instance also holds (the proxy to) the component's interface needed for passing messages to it. Messages entering the schedule are captured as part of the schedule state; they are optionally parsed based on a schema, and the fields of the captured messages are available to populate outgoing messages or for use in Rule expressions within the schedule.

Some things are worth keeping in mind to understand the message flows. One is that the message flow occurs only in response to an Action being performed in the schedule. Another is that the schedule instance intercedes for an Action to deliver or receive a message to or from a port implementation. Finally, for a COM component, the schedule holds the interface required for passing messages to it. Having noted this, we look at two kinds of message exchange: synchronous and asynchronous.

As you know by now, an Action that communicates through a port connected to a COM component uses a message pair to communicate: one to make the method call request and pass arguments, and the other to receive the call response and return arguments. This is a synchronous exchange of messages. An Action that communicates through a port connected to a messaging service, on the other hand, uses a single message. This is an asynchronous action. For each of these two scenarios, the message sender can be the schedule or an outside application. Thus, there are four combinations to consider. These are depicted in Figure 10.9.

Figure 10.9 shows the two synchronous cases on top (cases 1 and 2), and the two asynchronous cases on the bottom (cases 3 and 4). The legend at the bottom describes the objects shown, and the arrows depict the flow of messages. Note that the port is just a logical endpoint for the delivery or receipt of messages; the message flow occurs when an Action is performed by the schedule instance. We look at each of these cases in the following sections.

Case 1: Application Calls a Method

This case is arguably the most nonintuitive of the three. In this case, an Action in the schedule is waiting for a method call from an application over a port bound to a COM component. In the schedule drawing, you see this as a message pair for a method call, with the blue arrow going into the Action shape on top of the red arrow depicting call return. When the application initiates the method call, the schedule intercepts the call request message and then forwards it to initiate the method call using the interface it holds for the COM component. It then again waits for the call to return from the component. When the call returns, it intercepts the returned message containing the returned parameters of the method call. Finally, it forwards the call return message to the application that initiated the call in the first place. Figure 10.9 shows these four steps using dashed and solid arrows.

The process is the same whether the port involved is static or dynamic. In either case, the schedule holds an interface to the COM component specified by the port, and messages are sent to the method on that interface.

One useful special case occurs when the application making the call merely wants to pass the call request message to the schedule and discards the call return message. That is, the application merely wants to provide some argument values. In this case, the schedule instance need not bother acquiring the COM interface in the first place! This is the case for No Instantiation when binding a COM implementation to a port. For a COM port binding, this is an additional option to Static or Dynamic in the wizard. You see this option when the port-binding wizards are described in the section “COM Component Binding Wizard.”

Case 2: Schedule Calls a Method

In this case, an Action initiates a method call to a port bound to a COM component. The schedule passes the call request message by initiating the method call on the component's interface. The schedule then waits for the call response to come.

The next two cases are for asynchronous messaging.

Case 3: Application Sends a Message

This case is for an asynchronous receipt of a message. In this case, an Action waits for a message to arrive from a port connected to an MSMQ queue or BizTalk Messaging Services. The message is posted by another application or a schedule instance.

If the port is connected to BizTalk Messaging, the posted message may result in a new schedule being started. If the message is posted to an existing XLANG schedule, then it must be sent via the HTTP protocol for BizTalk Messaging to process it.

Case 4: Schedule Sends a Message

This case is for an asynchronous delivery of a message. In this case, an Action sends a message to a port connected to an MSMQ queue or BizTalk Messaging channel. The queue or the channel may be dynamic, but this does not alter the characteristics of the message flow.

Asynchronous and Synchronous Communication

Of the four cases shown in Figure 10.9, two showed synchronous exchange of messages, whereas the other two showed asynchronous exchange of messages.

Asynchronous communication, although arguably more difficult to use, is easy to understand. The sender just sends the message and forgets about it. The receiver waits until it gets a message. It is also more scalable because it provides loose coupling between the two communicating systems.

Synchronous communication, where the XLANG schedule calls a component, is akin to the normal programming paradigm of a function call. The XLANG schedule acquires an interface, possibly by instantiating the component, and makes the method call using the arguments described in the design of the schedule. This results in tight coupling between the interacting systems at the cost of concurrency.

Using asynchronous communication allows you to build robust and scalable solutions. In the real world, systems or applications that exchange documents do not reside on the same computing system. Different computing systems may encounter scheduled or unscheduled downtime, making the processes running on them unavailable. In addition, the network connectivity between the computing systems cannot be mandated. The connectivity may be disrupted due to operational reasons, or it may only be established at specific times. In such an environment, writing a tightly coupled solution is asking for trouble. The participating applications will interlock waiting for calls to return as every message is processed.

Asynchronous messaging allows one application to continue processing messages available to it and forwarding them to other applications without waiting for those applications to accept or process those messages. Typically, the messages get queued and wait until such time that the necessary communication channels become available or when the receiving application is able to process the message. The actual processing can be staggered to balance the load or prioritize the tasks.