Ports

A port is a conduit used by a schedule instance to exchange messages. An action in the schedule communicates through a port. At a conceptual level, a port is a named endpoint for the delivery (or receipt) of a message from an attached implementation into (or out of) an XLANG schedule instance. This statement, however, is simplistic; it glosses over issues of synchronization, transactions, error handling, state, instantiation, naming, call semantics, and so on. Although a port is just a conduit for a message, its behavior is affected by the implementation behind the port. The rest of this chapter is devoted to looking at these issues more carefully. This section, however, attempts to provide a better conceptual understanding of ports. We begin at the process of creating a port. We will then work through use cases that motivate the issues raised here.

To create a port as an XLANG schedule designer, you usually pick an implementation shape from the stencil and drop it on the right half of a process flow page. When you do this, a wizard walks you through the necessary configuration steps needed for the specific implementation technology you selected. The wizards themselves are described in the section “Wizards for Port Implementations.”

When designing the schedule, as an alternative to picking the implementation technology first, you can start instead with defining ports first; however, this works only for messaging-based implementations. You do this by right-clicking on the separator bar in a process flow page and selecting the Add New Port menu item. When created, these ports are unbound; however, you must subsequently bind these ports to an MSMQ queue or a BizTalk Messaging implementation before the schedule can be compiled and run. You may later proceed to bind Action shapes to these ports; however, the port properties are determined by the implementation you bind to the port eventually. Using an unbound port is useful when you want to proceed with designing your business process along with associated messages while deferring to select the messaging implementation. Commun-ication through an unbound port is always asynchronous, and you must use the XML Communication Wizard to define the messages flowing through it.

A port can perform its function of exchanging messages only if the underlying implementation is available. For example, unless a COM component is instantiated, you cannot make method calls through the port; unless a queue or a channel exists, you cannot send or receive messages through the port. (In the special case of No Instantiation, you must have the type library of the COM component.) This may seem obvious but is something to keep in mind when a running schedule uses a port created by some other application or a schedule. We next look at a use case that motivates these instancing options.

At the time you design an XLANG schedule, you may possess all the information required to construct or specify the desired port implementation. In some cases, however, you need to communicate through a port instance that is available only at runtime and cannot be fully specified at design time. Such a port instance may be implemented, for example, by another application or even by a trading partner on a remote and inaccessible system. Figure 10.3 shows such a scenario in abstract. The ScheduleA and ScheduleB are reusing the business process defined by ScheduleC.

Figure 10.3. Using ports to integrate schedules.


Both schedules, A and B, are shown to contain just two steps: send a request to schedule C and then get a response from it. Both schedules, A and B, are unaware of each other's existence but use the same business process defined in schedule C: to get the request and send a response. Schedule C must maintain this isolation by sending the response back to the original requesting schedule. Schedule C does not know about schedules A and B; it merely processes the request sent by any schedule, like A or B. Therefore, when designing schedule C, you cannot hard-code the routing of messages; this routing must be resolved dynamically.

The ScheduleC is designed so that it can respond to ports on specific instances of running schedules, such as ScheduleA and ScheduleB shown in Figure 10.3. The schedules A and B may be two instances of the same schedule or an instance each of two different schedules; however, in each case, the running instance is sending a document to an instance of ScheduleC, shown by the solid arrows. The document sent to ScheduleC is called Req, and it contains a tag for the sender's port. The tags are shown by the ribbon shapes in the Figure 10.3. The ScheduleC is completely unaware of the sending schedule. It processes Req and generates a Resp document. This generated document is sent to the port identified by the tag in the Req document. This is shown by the dotted arrow. The action taken by the ScheduleC is identical in both cases; however, it ends up sending the document to different ports, each identified by the tag in the Req document.

This is a common trading partner document exchange scenario. There are many variations of this general scenario: schedules A and B may communicate with the same instance of C, or the entire business process represented by C (or by A or B) may be implemented by a trading partner without using the BizTalk Server. The important point is to note the mechanisms needed to integrate business processes. We need a way to generate a tag for a port that can be unambiguously resolved to a real port instance some time in the future, even after system failures. This notion of a tag applies to port references and dynamic ports, which are described next in the section “Port References and Dynamic Ports.” Chapter 16, “Correlation—Integrating BizTalk Server Messaging and Orchestration Services,” is devoted to correlation, alluded to in Figure 10.3.

Another example of when a port name is not adequate is multiple instances of the same schedule running in memory. Clearly, the design-time name for each port will be the same and will not serve to distinguish the ports. Now we return to port creation.

In an XLANG schedule drawing, when you create a port, you get to name it. However, this name is the static, design-time name that you assign and is not adequate as a tag that can be used as a name for a runtime instance of that port. For this, BizTalk Orchestration has the notion of port references.

When you choose an implementation technology for a port, by dragging a shape from the stencil to the drawing surface, you can specify at design time whether the XLANG Scheduler Engine should create the port instance object, or whether it should use a port that's already been created earlier. This is done by using a port reference. The ability to specify a port implementation that can be resolved at runtime is required to enable the scenario shown in Figure 10.3. To facilitate this, BizTalk Orchestration has the notion of static and dynamic ports.

Moving to other aspects of ports, the runtime behavior of messages passing through ports is also important to understand. When you bind an Action with a port, messages are defined; however, when the schedule runs, specific messages are created and flow through the ports. In the sections “Message Flow Behavior,” “State Management,” and “Transaction Support” and “Security” later in the chapter, we cover the runtime aspects of message flows, including concurrency in message flows, persistence relating to dehydration and rehydration, transactions, and security. All these issues are related to the runtime behavior of schedules, ports, and their underlying implementation.

To summarize, in the following sections we look at each of these items:

As promised, the next section discusses port references and dynamic ports.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset