XOCP applications, including those originally written with the WebLogic Collaborate C-Enabler API for WebLogic Integration Release 2.0, must be run in a separate Java Virtual Machine (JVM) in nonpersistent mode.

Key Concepts

This section describes the following key concepts associated with XOCP applications:

XOCP Applications

An XOCP application is a user-written Java application that runs on a WebLogic Integration node that is deployed in a hub-and-spoke configuration and that uses the XOCP application class to execute a specific role in a conversation definition. In a hub-and-spoke configuration, a trading partner XOCP application is associated with a spoke delivery channel, or B2B spoke. This XOCP application allows a trading partner to communicate with other trading partners at B2B spokes via an intermediary, or routing proxy, which is configured with a hub delivery channel.

A user-written XOCP application executes the following tasks:

The following figure shows three possible hub-and-spoke configurations for the delivery channels, the XOCP applications, and the instances of WebLogic Integration that host the XOCP applications.

Figure 1-1 Possible Hub-and-Spoke Configurations

XOCP Application Sessions

An XOCP application session is the means by which an XOCP application is associated with a collaboration agreement and a delivery channel. An XOCP application session is created by an application to communicate with a trading partner; and its scope is bounded by a delivery channel. XOCP applications create an XOCP application session by invoking the getXOCPApplicationSession method on the XOCP application class.

An XOCP application can be associated with multiple XOCP application sessions, enabling the application to participate in multiple conversations simultaneously.

Messaging API Class Library

The Messaging API class library includes the XOCP application class and provides APIs for exchanging XOCP business messages. It consists of the packages listed in the following table.

XOCP Business Messages and Message Envelopes

Diagram of an XOCP Business Message

The following figure shows a message envelope and the components of an XOCP business message.

Figure 1-2 Components of an XOCP Business Message

An XOCP business message is a multipart MIME (Multipurpose Internet Mail Extensions) message. It consists of the following components.

Information Flow for Message Envelopes

The following figure shows an example of how message envelopes are processed in WebLogic Integration.

Figure 1-3 Message Envelope Processing in WebLogic Integration

Conversation Initiators and Participants

In any XOCP conversation, there are two types of trading partner roles:

Each conversation definition in the repository includes at least both of these types of roles. A trading partner must be subscribed to the appropriate role in the conversation to initiate or participate in conversations associated with the associated conversation definition.

The initiator of a conversation is usually determined by the role in which a trading partner is registered. For example, in a GetQuote conversation, the trading partner in the role of the buyer normally initiates a GetQuote conversation. Any trading partner in the role of the seller normally acts as a conversation participant in the GetQuote conversation.

The following figure shows some of the tasks that conversation initiators and conversation participants perform.

Figure 1-4 Conversation Initiators and Participants

WebLogic Integration supports two types of conversation coordinators that manage conversations at run time: a global conversation coordinator manages active conversations on the B2B intermediary, and local conversation coordinators associated with B2B spokes help the global coordinator manage active conversations locally.

The following figure shows where global and local conversation coordinators work in the WebLogic Integration architecture.

Figure 1-5 Global and Local Conversation Coordinators

A global conversation coordinator is a service associated with the intermediary, which is configured with a hub delivery channel. The global conversation coordinator manages conversation lifecycles according to the rules of XOCP and supports long-living, durable conversations that span multiple organizational boundaries. The global conversation coordinator maintains a list of active conversations.

The global conversation coordinator performs the following services:

Local Conversation Coordinators

A local conversation coordinator is a service associated with a B2B spoke. The local conversation coordinator manages conversations in which the local trading partner (configured with a spoke delivery channel) is participating and maintains a list of active conversations. Each XOCP application session has a separate local conversation coordinator.

The local conversation coordinator performs the following tasks:

Trading Partner States

The following table describes the states assigned to trading partners as they perform tasks related to XOCP application sessions and conversation participation.

Some of these trading partner states are visible in the WebLogic Integration B2B Console.

Secure Messaging

Key Tasks for XOCP Applications

This section introduces the key tasks that XOCP applications perform:

Creating an XOCP Application Session

Before exchanging business messages, an XOCP application must create an XOCP application session for the trading partner and its associated delivery channel.

Before a trading partner XOCP application can create an XOCP application session:

Note: If the machine hosting the XOCP application associated with the spoke delivery channel crashes after connecting to a hub delivery channel, the XOCP application can reconnect to the hub delivery channel upon normal startup. The previous XOCP application session is discarded and new resources are assigned to the new XOCP application session. However, the intermediary cannot deliver business messages while the machine associated with the spoke delivery channel is down. Undelivered business messages are discarded if the number of retry attempts is exceeded or if the business message or conversation times out.

Registering for a Role in a Conversation

After the XOCP application session has been created, a trading partner needs to register a message listener for the conversation type to which it is bound by the collaboration agreement. The message listener must be registered for a conversation type that defines how the trading partner participates in the conversation.

Role registration requires the following information in the repository associated with the hub delivery channel:

Before registering a message listener for a conversation type in a collaboration agreement, the trading partner must first be authorized to register. Authorization is configured by the administrator of the intermediary and is based on the trading partner's subscription to a role in a conversation definition.

When an XOCP application session attempts to register a message listener for a specific conversation type in a collaboration agreement, the spoke delivery channel sends an XOCP system message, register for conversation, to the intermediary. The intermediary validates the role of the trading partner for the requested conversation type in the associated delivery channel. If the registration is valid, the trading partner is then allowed to initiate and participate in conversations associated with the registered conversation type. At this point, the trading partner is in a REGISTERED state and is ready to initiate or participate in conversations.

Engaging in Conversations with Trading Partners

Once registered for a role in a conversation, a trading partner can engage in conversations in accordance with that role. Conversation initiation and participation occurs on the intermediary itself. However, the XOCP application session maintains some state information about the conversations in which it is involved.

Conversation initiator XOCP applications and conversation participant XOCP applications are very similar. However, conversation initiator XOCP applications can terminate conversations while conversation participant XOCP applications cannot. Conversation participant XOCP applications can only leave a conversation.

Initiating a Conversation and Sending a Business Message

To initiate a conversation, a conversation initiator XOCP application first creates it. Optionally, the conversation initiator XOCP application can specify a timeout value, after which the conversation automatically terminates; this value overrides the timeout value that is specified in the associated conversation definition in the repository.

Participating in a Conversation

The global conversation coordinator in the intermediary handles all business messages that the intermediary receives for a given conversation. After the intermediary delivers an initial business message to recipient trading partners, the global conversation coordinator enlists those trading partners in that conversation. Once a trading partner is enlisted in a conversation, the trading partner is in an ACTIVE state and can send and receive business messages in that conversation.

Once a registered trading partner is enlisted in a conversation, the trading partner is in an ACTIVE state and can send and receive business messages in that conversation.

Leaving a Conversation

When it has finished participating in a conversation, a conversation participant trading partner can leave it. When a trading partner leaves a conversation, it is removed, by the conversation coordinator, from the list of participating trading partners. Subsequent business messages in that conversation are not sent to that trading partner. After a trading partner leaves, it is kept in a DROPPEDOUT state for the remainder of that conversation.

Terminating Conversations

A conversation terminates when the initiating trading partner explicitly terminates the conversation, or when the conversation times out; whichever occurs first. A trading partner who initiates a conversation must terminate that conversation at the appropriate time in a business process.

Note: Only the conversation initiator can terminate a conversation.

When a conversation is terminated, the conversation coordinator sends all of the participating trading partners an XOCP system message: terminate message. This message is propagated as the callback onTerminate on registered message listeners in XOCP application sessions on B2B spokes.

Shutting Down an XOCP Application Session

When a trading partner finishes all the activities in a conversation, the XOCP application shuts down the XOCP application session. When an XOCP application shuts down an XOCP application session, the B2B engine associated with the spoke unregisters with the intermediary all the collaboration agreements associated with this session. This causes the intermediary to unregister the associated conversation type. In response, the conversation coordinator automatically terminates all of the conversations that the trading partner has initiated in the XOCP application session and delists the trading partner from all other conversations in which it was participating.

When a trading partner shuts down an XOCP application session, the consequences are as follows:

Run-Time Information Flow

At run time, all XOCP applications perform certain tasks identically: they connect to a delivery channel, register message listeners, and shut down the application session in the same way. During individual conversations, however, conversation initiators and conversation participants perform a series of distinct, interweaving tasks.

Information Flow Diagram

The following figure shows the run-time information flow between a conversation initiator and a participant.

Figure 1-6 Information Flow Between Conversation Initiator and Participant

Steps in the Information Flow

At run time, the flow of information between trading partners (via XOCP applications communicating through the intermediary) proceeds in the following sequence: