Overview

 

The BEA WebLogic Collaborate^TM product is an XML- and Java-based open market electronic commerce platform that enables you to implement business-to-business (B2B) e-commerce systems on the Web. It helps you quickly deploy B2B e-commerce systems that link existing back-end applications, databases, and customers into automatic and flexible electronic collaborations.

WebLogic Collaborate is a software framework and a set of services built on top of the BEA WebLogic Server^TM system. WebLogic Collaborate is implemented entirely in Java and leverages the J2EE blueprint and standard APIs. Central to WebLogic Collaborate is XML, which provides an open data interchange format between loosely coupled participants. WebLogic Collaborate supports HTTP because the World Wide Web is the ubiquitous communication medium where the majority of e-business gets conducted.

WebLogic Collaborate simplifies and enables the building of portals, Application Service Provider (ASP) businesses, and integrated businesses on the Web.

The following sections provide a product overview:

• Feature Support for Your E-Business

• Understanding the Architectural Requirements of an E-Market

• Using WebLogic Collaborate — the End-to-End View

• Documentation Road Map

 

---

Feature Support for Your E-Business

The goal of WebLogic Collaborate is to provide B2B features for building mission-critical, scalable, real-world e-market collaboration and trading exchanges, including:

• Robust support for secure, high-volume business transaction levels based on BEA's award winning WebLogic Application Server^TM technology. BEA's proven, high availability, 24x7-managed server technology, with dynamic load-balancing, multithreading, and fail-over without processing interruption, has delivered industry-leading results in thousands of the world's most demanding application environments.

• Reliable, role-based XML messaging that supports enhanced send and receive capabilities, including support for large messages, based on any combination of sender, receiver, and content filtering.

• Dynamic market management, allowing you to configure e-markets, trading partners, and collaborations on-the-fly.

• An SSL-based secure platform for conducting collaborations that includes mutual (two-way) authentication using digital certificates among trading partners.

• A pluggable architecture that supports multiple, standards-based business protocols, business rules, and market applications.

• Conversation coordination to manage the execution and interaction of two or more trading partners within the conversation and to manage conversation life cycles.

• An open, nonproprietary architecture that leverages Java, J2EE XML, HTTP, HTTPS, and other emerging industry standards to allow rapid system and cross-platform integration, with low barriers to entry and "plug and play" with XML-ready, best-of-breed application software.

• Support for user-defined business protocols and vocabularies, allowing you to meet custom e-market requirements and obtain competitive advantage.

• A data repository and a set of design and configuration tools to define and manage the metadata and conversation definitions of WebLogic Collaborate.

• Integration with BEA WebLogic Process Integrator, the BEA workflow automation tool, which is packaged with WebLogic Collaborate.

WebLogic Collaborate also has a number of features inherited directly from WebLogic Server, including:

• The ability to build custom portals to e-markets by leveraging BEA WebLogic Personalization Server^TM components

• A portal backbone

• Controlled and secure Web access to existing business data and applications

• Support for existing applications based on CORBA, EJB, Tuxedo®, and COM+

Figure 1-1 shows a high-level topology of an example e-market based on WebLogic Collaborate.

Figure 1-1 Topology of an Example WebLogic Collaborate-based E-Market

 

In the preceding figure, note the following

• Trading partners connect to a WebLogic Collaborate entity called the collaboration space, or c-space, which organizes the business exchanges among trading partners. C-spaces are described in Collaboration Spaces.

• A trading partner may be colocated on the machine that hosts the c-space, or a trading partner may be remote at a site behind its own firewall.

• Multiple trading partners may be colocated on the same WebLogic Server instance.

• Trading partners may be set up on top of a WebLogic Server-based platform, on a WebLogic Express-based platform, or on a platform that has no BEA-provided software.

• Trading partners that are based on WebLogic Server can also use the WebLogic Process Integrator software to integrate workflows into their exchanges with other trading partners.

 

---

Understanding the Architectural Requirements of an E-Market

The following sections describe the architectural requirements of an e-market:

• Trading Partners

• Business Processes and Vocabularies

• Conversations and Roles

• Business Messages

• Collaboration Spaces

• Conversation Subscriptions

• Software for Implementing the C-Space

Trading Partners

One of the basic building blocks of an e-market is the notion of a trading partner. A trading partner is an e-market participant, such as a company, that joins other trading partners to form a community with a specific business purpose. For example, a typical e-market could be an automobile parts exchange: one trading partner supplies exhaust pipes and another is an auto parts retailer.

In an e-market, a trading partner must have a special identity that defines where it fits with the business purpose of the e-market. In WebLogic Collaborate, the term trading partner refers specifically to an entity that is authorized to participate in one or more specific business exchanges, or conversations, in a specific role that is defined for the e-market. These concepts are explained in later sections.

Business Processes and Vocabularies

One of the first things you do when you create an e-market is to define the vocabulary and business processes of the e-market. This is a key step because when you define the vocabulary and business processes for exchanging information, you establish:

• The kind of information that is exchanged

• The processes that trading partners will follow when exchanging information

For example, in an automobile parts exchange, a trading partner sending a purchase order must include a specific set of data in that purchase request so that the recipient can understand the contents of that purchase order. The identity of each piece of information, which is exchanged between trading partners in XML messages, makes up the vocabulary.

Business processes govern how trading partners behave when they receive certain types of messages or when error conditions arise. Business processes also define what certain kinds of documents, such as a bid request or a purchase order response document, mean. For example, a business process may state what kind of responses a trading partner can send when the trading partner receives a purchase order.

Once you have defined the e-market vocabulary and business processes, you must choose:

• A business protocol appropriate for the e-market — for example, the eXtensible Open Collaboration Protocol (XOCP) or RosettaNet. While RosettaNet specifies both the business process and the protocol, XOCP refines the business process that governs the exchange of business information between trading partners. The business protocol specifies how to process the messages and how to route them to the appropriate recipients. A business protocol may also specify characteristics of messages related to persistence and reliability.

• A set of Document Type Definitions (DTDs) that define the grammar and syntax of the XML messages sent among trading partners

Conversations and Roles

A preliminary outcome of having defined the vocabulary, business processes, business protocol, and DTDs for the e-market is the outline of the conversations that take place between trading partners.

In WebLogic Collaborate, a conversation:

• Consists of a predefined set of message exchanges. Each message may cause any number of back-end system transactions to occur when it arrives at a trading partner's site.

• May be complex and long-running, or short-lived.

• Has an ID, which is used by the system. The conversation ID can also be used by the trading partner application to retrieve conversation-specific data.

A given conversation specifies the types of messages that can be changed between two or more trading partners for a specific business process. The kinds of messages a specific trading partner may send or receive is a conversation role.

The final outcome of specifying the details of each conversation in an e-market is the conversation definition. A conversation definition specifies:

• A unique conversation definition name

• A conversation definition version

• The DTDs, or schema, for the business messages exchanged in the conversation

• Roles in the conversation

Each trading partner who participates in a conversation in a given role — for example, supplier, as shown in the following figure — must implement its local view of the conversation. Although this local view is partner-specific, to enable the trading partner to participate in the conversation as specified by the conversation definition, the view must encapsulate the processes required to handle the right business messages at the right time.

The following figure shows a graphical representation of a simple conversation and possible local flows for the two roles.

 

In this figure, note the following:

• The business messages PriceAndAvailabilityQuote and PriceAndAvailabilityResponse.

• The roles Buyer and Supplier. The implication of being in a role in a given conversation is that you send and receive only the business messages defined for your role. For example, the Buyer:

  • Starts the conversation

  • Sends the business message PriceAndAvailabilityQuote

  • Receives the business message PriceAndAvailabilityResponse and processes it

    By contrast, the Supplier:

  • Receives and processes the business message PriceAndAvailabilityQuote

  • Sends the business message PriceAndAvailabilityResponse

• The local flows. Each role has its own set of local processes required to send and receive the right business messages at the right times.

Business Messages

A business message is the basic unit of communication among trading partners. A business message contains one or more XML business documents, one or more attachments, or a combination of both. Business messages, which are expressed in XML and are communicated in a WebLogic Collaborate-based c-space, also have other information depending on the business protocol — for example, XOCP or RosettaNet — chosen for the conversation. Business messages are exchanged as part of a conversation. Business Protocols provides more detail about this additional, protocol-specific information.

Business Protocols

As mentioned earlier, the business protocol is a further refinement of the business process that governs the exchange of business information between trading partners. WebLogic Collaborate Version 1.0 supports two protocols:

• RosettaNet 1.1

• eXtensible Open Collaboration Protocol (XOCP), a BEA-specific protocol

WebLogic Collaborate provides a pluggable architecture to support multiple protocols, providing message routing and filtering capabilities that are customized especially for each protocol. A c-space can support multiple protocols, giving you a great deal of flexibility in organizing an e-market by reducing the need for trading partners to standardize on any single protocol. Support for additional protocols will be available in future releases of WebLogic Collaborate.

RosettaNet

From the RosettaNet Web site (http://www.rosettanet.org): RosettaNet is an independent, self-funded, non-profit consortium of major information technology, electronic components, and semiconductor manufacturing companies working to create and implement industry-wide e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis.

RosettaNet provides e-business Partner Interface Process (PIP) specifications, which define business processes between supply-chain partners, providing the models and documents for the implementation of standards.

PIPs fit into six clusters, or groups of core business processes, that represent the backbone of the supply chain. Each cluster is broken down into segments, which are cross-enterprise processes involving more than one type of supply chain partner. Within each segment are individual PIPs.

PIPs are specialized system-to-system XML-based dialogs that define business processes between supply chain partners. Each PIP includes a technical specification based on the RosettaNet Implementation Framework (RNIF), a Message Guideline document with a PIP-specific version of the Business Dictionary, and an XML Message Guideline document.

RosettaNet is a point-to-point messaging protocol: business messages are sent between only two trading partners.

XOCP

The XOCP protocol, like RosettaNet, is also designed for deploying peer-to-peer and supply-chain market applications among suppliers, manufacturers, and distributors. However, XOCP also provides the following messaging characteristics:

• Message multicasting

  Message multicasting is the ability of the messaging service to broadcast a message from one trading partner to all conversation participants who are registered as recipients of that message. For example, if 15 trading partners are registered in the role of "supplier" in the ProcessPurchaseOrder conversation, then all messages received by the c-space messaging service that are meant to be sent to the "supplier" will be sent to all those trading partners (within the constraints of message routing and filtering, described later).

• Message payload definition independence

  XOCP provides the flexibility for you to specify both the vocabulary and business processes for your messages for a given conversation so that they are an exact fit for your business requirements.

• Conversation life cycle management

  XOCP is designed to manage long-lived conversations. When a conversation terminates, all trading partners who are enlisted in that conversation receive an end-of-conversation message.

• Qualities of Service (QoS) capabilities

  The WebLogic Collaborate software offers a variety of settings related to QoS that allow you to set and control characteristics of XOCP messages sent in conversations, such as:

  • Message durability — Specify whether a durable message store is to be used to guarantee the delivery of messages in the case of network, machine, or software failures.

  • Timeout — Specify how long a trading partner application will wait before terminating all processing related to the business message.

  • Retry attempts — Control how many times a message should be resent in the presence of specific situations, such as timeouts, network failures, and so on.

  • Correlation ID — Set an additional business message property that can be used to correlate messages in a conversation.

    WebLogic Collaborate allows you to establish QoS settings on a per-conversation and per-message basis.

XOCP Business Messages

Business messages exchanged in a conversation based on the XOCP protocol have the structure shown in the following figure. Understanding the structure of XOCP business messages is especially important for writing WebLogic Collaborate-based XOCP applications, such as trading partner applications, or special c-hub-located applications called logic plug-ins, described later.

 

Note the following parts:

• Message envelope — This is a logical container for the XOCP business message that is added while the business message is in transit through the WebLogic Collaborate messaging service software. The message envelope typically contains data related to the sender of the message and the recipients, and can contain other metadata. The envelope is visible in the messaging service only. The envelope is not part of the transport protocol.

• Message headers that include:

  • Transport and Qualities of Service (QoS) data, such as sender and recipient identities, content length and type, and status code. This metadata is typically used and modified while the XOCP business message is in transit through the c-hub.

  • Conversation and routing headers, such as sender information, list of message recipients, conversation information, message ID, creation timestamp, and other data. Message attributes can be set by the originating trading partner, or by logic plug-ins in the c-hub, such as the XOCP router or XOCP filter.

• Payload, which includes one or more business documents, one or more attachments, or a combination of both. Note that a business document is expressed in XML, and an attachment is a binary (non-XML) part of the message. The business documents, with their attachments, constitute the kernel containing the information being exchanged among trading partners.

  When a trading partner application or a WebLogic Process Integrator workflow prepares a message payload to be sent to one or more trading partners, that application or workflow includes a process that adds the XOCP headers to the XOCP business message.

An XOCP message is a MIME multipart message. All its components are expressed in XML, except for the non-XML attachments.

Collaboration Spaces

In its simplest sense, a collaboration space, or c-space, is the implementation of an e-market using WebLogic Collaborate. A c-space is an abstraction that provides the structure for organizing and administering conversations among trading partners.

A c-space supports:

• A single business model

• A business message vocabulary

• A set of business processes

• One or more business protocols

• A registered set of trading partners

In summary, a c-space provides the administration capability, conversation coordination, and underlying messaging services that are required to create a dynamic business-to-business integration environment. A WebLogic Collaborate-based e-market can support any number of c-spaces on the Web concurrently and any number of trading partners.

Conversation Subscriptions

When a trading partner wants to participate in a c-space, that trading partner subscribes to specific roles in specific conversation definitions. This establishes the relationship of the trading partner to the c-space. For example, an auto parts manufacturer can participate in a c-space by subscribing to the role of "supplier" in the ProcessPurchaseRequest conversation.

Software for Implementing the C-Space

WebLogic Collaborate provides two primary pieces of software for implementing a c-space:

• The collaboration hub, or c-hub, which hosts the c-space and thus serves as the transportation utility for sending messages among trading partners

• The collaboration enabler, or c-enabler, which exists at each trading partner's site and which allows a trading partner to participate in predefined c-spaces and possibly with multiple c-hubs

Optionally, a c-enabler can be integrated with WebLogic Process Integrator to provide better conversation flow handling. As mentioned earlier, WebLogic Process Integrator is bundled with WebLogic Collaborate.

The following figure shows the WebLogic Collaborate software deployed in an e-market. Each machine that hosts a c-enabler is referred to as a c-enabler node. The machine hosting the c-hub is a c-hub node.

 

The c-hub and c-enabler work together to enable the exchange of business messages among trading partners by providing the following services:

• Messaging Service

• Conversation Coordination Service

• Administration Services

• Security Services

• XML Services

• Logging Service

In addition to these services, the c-hub also includes a repository service, and the c-enabler can be integrated with WebLogic Process Integrator.

The sections that follow introduce each of these services.

Messaging Service

WebLogic Collaborate provides a flexible messaging service to facilitate information transfer between trading partners. The messaging component relies on decoupled, deferred synchronous messaging capabilities to allow communication flexibility between trading partners.

The WebLogic Collaborate messaging service has the following features and characteristics:

• Supports multiple XML-based business protocols natively; for example, the eXtensible Open Collaboration Protocol (XOCP) and RosettaNet

• Supports blocking and non-blocking message delivery

• On the c-hub:

  • Provides routing and filtering capabilities, controlling who receives messages

  • Accommodates the insertion of user-written code at key points to customize the handling of incoming or outgoing messages or to perform messaging-related operations

• For XOCP-based messages, provides Quality of Service (QoS) capabilities to establish durability, confirmation of receipt, message tracking, message timeout, retry, and other settings for messages sent among trading partners

Conversation Coordination Service

Conversations can be complex and long running; in fact, some business conversations may last years. Conversations always have life cycles, and they are explicitly demarcated by a beginning and an end. The WebLogic Collaborate software provides a service, called the conversation coordination service, that coordinates trading partners who are participating in conversations around these life cycle events.

The WebLogic Collaborate conversation coordination service is protocol-specific. In the case of XOCP-based conversations, the conversation coordinator in the c-hub does the following:

• Creates the conversation on behalf of the trading partner that initiates the conversation

• Enlists new trading partners into the conversation

• Delists trading partners that choose to leave the conversation

• Sends conversation termination notices to all conversation participants when the conversation is terminated

Also in the case of XOCP-based conversations, the conversation coordinator in the c-enabler keeps track of the following:

• Conversation handlers for the different conversation types

• All the conversations currently active in the c-enabler

Repository Service

The c-hub includes a repository service to store data required to run the c-space and manage trading partners, including:

• Conversation definitions

• Trading partner role subscriptions

• Document definition (DTD) names

• Document and configuration information

• Extended properties of trading partners

• Data used for message routing and filtering operations

In addition, the repository:

• Is accessible through the C-Hub Administration Console for administration and monitoring functions. The repository allows you to plug in a variety of JDBC RDBMs.

• Provides Oracle, Microsoft SQL Server, or Cloudscape as a primary store

• Can be loaded with the Bulk Loader utility

Administration Services

The WebLogic Collaborate administration services perform multiple configuration and system management functions, including:

• Providing the entry point for trading partners to join a c-space

• Providing a means to configure, administer, and monitor the c-space, conversations, trading partners, and more

Through the administration service, the c-space administrator can configure and manage trading partners (create IDs, grant and revoke roles), and both c-hub administrators and trading partners can browse system status (conversations, message delivery, and so on). In addition, trading partners can use the administration service to start and end c-enabler sessions and end conversations.

Access to Administration Services

WebLogic Collaborate provides two means of access to the administration services:

• For configuring and monitoring, WebLogic Collaborate provides two Web-based administration consoles:

  • C-Hub Administration Console, used by the c-hub administrator to configure and monitor the c-hub

  • C-Enabler Administration Console, used primarily by the trading partner as a monitoring tool, although it is also used to start and stop c-enabler sessions

• For monitoring use only, WebLogic Collaborate also supports user-written applications that use the Java Management Extensions (JMX) Management Beans (or MBeans) to view various data and statistics maintained by the administration service, particularly data about the c-space, conversations, and trading partners.

  Trading partners can use the JMX Mbeans through an Mbean server, which is included in the administration services package, to send and receive messages to and from the administration service.

  Note: The version of the MBean server provided with WebLogic Collaborate 1.0 supports only local access.

Security Services

WebLogic Collaborate security is built on top of the security features provided by WebLogic Server. WebLogic Collaborate implements a role-based authorization scheme in the c-hub in which trading partners apply for roles in conversation types.

The key security features are:

• Mutual, two-way authentication using digital certificates

  WebLogic Collaborate authenticates the identities of trading partners, before the trading partners can access services or participate in dynamic collaboration and the trading partner's c-enabler and the c-hub server authenticate each other.

• Authorization control for WebLogic Server and WebLogic Collaborate resources

  WebLogic Collaborate conversations and business messages delivered by the messaging service are available only to an authorized set of trading partners. The authorized set of trading partners is specified per conversation type by the c-hub administrator, which is done by defining roles and specifying which trading partners are in the role.

• SSL communication among the WebLogic Collaborate trading partners, human users, and the c-hub

• Privacy

  Messages sent and received by and through WebLogic Collaborate are only seen by the appropriate set of trading partners.

Trading partner information is captured and stored by the c-hub repository. The basic information captured includes conversations, roles, URLs, and so on.

The c-hub security mechanism leverages from WebLogic Server to perform the following tasks:

• Map digital certificates to valid trading partners, using either the email addresses contained in the certificate or the fingerprint. (WebLogic Collaborate provides a default authenticator to perform the mapping.)

• Specify root Certification Authorities (CAs) and other WebLogic Server properties.

You can read more information about the tasks associated with setting up and administering the WebLogic Collaborate security:

• For a comprehensive discussion about WebLogic Collaborate security, and specifically c-hub security, see Configuring Security in the BEA WebLogic Collaborate C-Hub Administration Guide.

• For c-enabler security, see the topic Configuring C-Enabler Security in the BEA WebLogic Collaborate C-Enabler Administration Guide.

XML Services

The WebLogic Collaborate c-hub provides the following bundled XML services from the Apache Software Foundation:

• Xerces — an XML parser

• Xalan — an XSLT engine

For more information about these services, go to the Apache Software Foundation Web site at http://www.apache.org.

Logging Service

In both the c-hub and c-enabler, WebLogic Collaborate provides a local logging capability for error and information messages, which allows for data stores (for example, files). In the WebLogic Collaborate environment, all messages are timestamped. Logging is maintained as set of log messages, which can be sent to the WebLogic Server log, or to a separate log file.

Workflow Process Engine

A workflow process engine is not a mandatory architectural requirement for an e-market, but it can provide an extremely useful service when integrated with a trading partner's platform to control the execution of local business processes. The WebLogic Collaborate software includes the WebLogic Process Integrator product.

WebLogic Process Integrator is a process engine tool suite that trading partners can integrate with their market and back-end enterprise applications to manage complex e-business processes with multiple trading partners. The overall management of these distributed processes are part of WebLogic Collaborate conversation coordination.

Key features of the WebLogic Process Integrator software make it a powerful addition to WebLogic Collaborate:

• A design tool, called Studio, that a trading partner can use to graphically model business processes, including participation in the conversation roles in which the trading partner is registered. The WebLogic Process Integrator software then provides a means to link an instance of that model, called a workflow, to the trading partner's c-enabler configuration and execute the workflow. You can also use Studio to configure, administer, debug, and monitor workflow instances.

• Integration with back-end application by means of business operations defined by the trading partner.

• You use Worklist, a convenient user interface that defines and directs e-business process exceptions to human users for resolution.

Note: WebLogic Process Integrator is available in two versions: one that ships separately (version 1.2.1), and one that is bundled with WebLogic Collaborate (version 1.2.1C). WebLogic Process Integrator 1.2C provides all the functionality of 1.2, but also provides additional integration features with WebLogic Collaborate, including:

• Specialized workflow properties for manipulating business messages, specifying the message delivery Quality of Service, handling message tokens, and so on

• A Java application programming interface (API) for use in WebLogic Collaborate applications

The following figure shows a typical trading partner configuration that integrates the WebLogic Process Integrator software with WebLogic Collaborate.

 

For more information about WebLogic Process Integrator integration with WebLogic Collaborate, see Using Workflows to Exchange Business Messages in the BEA WebLogic Collaborate Developer Guide.

For more information about WebLogic Process Integrator, see the following documents:

• BEA WebLogic Process Integrator Studio User Guide

• BEA WebLogic Process Integrator Worklist Guide

• BEA WebLogic Process Integrator Tutorial

 

---

Using WebLogic Collaborate — the End-to-End View

This section provides more details about the WebLogic Collaborate architecture and features by showing a step-by-step, end-to-end view of:

• The procedure for setting up the components that make a c-space work, which shows what you need to do

• An exchange of business messages among trading partners registered for a conversation in a c-space, which shows how WebLogic Collaborate works

The procedures described in this section include:

• Registering Trading Partners for the C-Space

• Creating the Trading Partner Application

• Configuring the C-Hub

• Configuring the C-Enabler

• Starting the Conversation

• Broadcasting a Message to Trading Partners

• Receiving a Business Message and Responding Through WebLogic Process Integrator

• The C-Hub Sending a Response to the Buyer

The procedures described in this section focus on three trading partners: one has an application that invokes the c-enabler directly by way of the C-Enabler API to send and receive XOCP business messages. The other trading partners' configurations use WebLogic Process Integrator to process business messages received and sent through their c-enabler. The conversation used in this example is described in Conversations and Roles, and a figure showing a representation of this conversation is repeated as follows.

 

The following figure shows a static, high-level view of the WebLogic Collaborate environment in which the conversation takes place. Note the following:

• The buyer is shown on the left. The buyer's IT environment includes its Finance, HR, and Purchasing enterprise applications that are connected to the underlying WebLogic Server platform. (Note that the buyer's configuration does not include WebLogic Process Integrator. The use of WebLogic Process Integrator is optional. The configuration shown in this figure is hypothetical and could potentially have a number of different types of platform configurations.)

• The suppliers are shown on the right. Each supplier is configured with its own set of enterprise applications and WebLogic Process Integrator.

  

   

Registering Trading Partners for the C-Space

After the conversation definitions for a c-space have been created, the c-hub administrator can register trading partners in the c-space. Registering a trading partner in a c-space requires the following:

1. The c-hub administrator and the trading partner need a means to communicate, whether via email, a solicitation on a Web page, or whatever is appropriate for the business purpose of the c-space, to match a trading partner to a role in a conversation definition.

2. The c-hub administrator uses the C-Hub Administration Console to subscribe the trading partner to one or more specific roles in one or more conversation definitions.

3. The trading partner needs the c-enabler software. The trading partner can download the c-enabler from the BEA Web site, or from the c-hub administrator. If the trading partner platform includes WebLogic Process Integrator, the software sent by the c-hub administrator typically includes the local WebLogic Process Integrator workflow template definitions for each role to which the trading partner is subscribed. The trading partner also needs to have the software and business processes required to implement its roles.

In addition to completing the preceding steps, each trading partner also needs to have an application that:

• Interacts with the c-enabler

• Implements the processes defined in their local flows

The application may be provided by the c-hub administrator and configured by the trading partner, or may be created and configured entirely by the trading partner.

Creating the Trading Partner Application

The trading partner application is the implementation of the local business processes required to participate in the c-space conversations. The requirements for the application vary depending on:

• Whether the trading partner applications invokes the c-enabler directly, via the Enabler API, to participate in a conversation, or is integrated with WebLogic Process Integrator.

• Whether the trading partner's role is to initiate a conversation, or participate in an existing conversation

The trading partner application must implement the following functionality:

• Populating the outgoing business messages with the information required for the conversation

• Extracting information from the incoming business messages that have been received by the c-enabler

• The business process that is needed for the conversation, which typically includes access to back-end applications

About Trading Partner Applications That Invoke the C-Enabler Directly

The c-enabler has an API that provides trading partner applications with access to the following basic capabilities:

• Joining the c-space

• Registering conversation handlers

• Creating conversations

• Sending and receiving messages

• Terminating conversations

The trading partner application can use these APIs to implement the business logic for performing these tasks directly in Java.

For complete details about implementing applications that invoke the c-enabler directly, see Using XOCP C-Enabler Applications to Exchange Business Messages in the BEA WebLogic Collaborate Developer Guide.

About Trading Partner Applications Integrated with WebLogic Process Integrator

A trading partner whose c-enabler software is integrated with WebLogic Process Integrator needs to create an application that does the following:

• Invoke the workflow template to start the workflow instance

• Provide data for outgoing messages

• Process incoming messages

• Link to back-end applications, as appropriate

As mentioned earlier, the logic flow of the trading partner application depends on whether the trading partner's role is to initiate a conversation or to participate in a conversation initiated by someone else. A powerful way to implement a c-space is for the c-hub owner to create workflows that trading partners, who are subscribed to roles as participants in a conversation, can download from the c-hub administrator. These trading partners can then implement the business logic required to connect the workflows to their back-end applications, including other local workflows.

For complete details about using WebLogic Process Integrator to exchange business messages in the WebLogic Collaborate environment, see Using Workflows to Exchange Business Messages in the BEA WebLogic Collaborate Developer Guide.

Configuring the C-Hub

Before any trading partner activity can take place, the c-space administrator needs to configure the c-hub. Configuring the c-hub, which runs in a WebLogic Server instance, is a set of tasks in which you configure the following:

• WebLogic Server, to set values specific to the environment in which the c-hub runs

• The c-hub start-up classes

• The c-hub repository, which primarily involves setting up the JDBC connection to the database in which the repository exists

• The Java Message Service (JMS) queue

• The C-Hub Administration Console

• C-space, which includes associating trading partners with conversation definitions

• Security

• Persistence and recovery of business messages

• Business protocols used in the c-spaces

The c-space is the key entity that links trading partners with specific conversation definitions and roles. Each c-space has a URL that trading partners use to access the c-space. The URL also indicates the business protocol for the conversation in which the trading partner's role is subscribed.

For complete information about configuring the c-hub and c-spaces, see the BEA WebLogic Collaborate C-Hub Administration Guide.

Configuring the C-Enabler

To participate in conversations coordinated by the c-hub, each trading partner needs to create a c-enabler session between their c-enabler and the c-hub. Each c-enabler session allows the trading partner to exchange business messages with other trading partners in a c-space.

Each c-enabler requires an XML configuration file, which specifies:

• C-enabler name, URL, and session name

• Trading partner name, as registered in the c-space, and security information

• URL of the c-hub with which the c-enabler interacts

For complete information about creating the c-enabler XML configuration file, see the BEA WebLogic Collaborate C-Enabler Administration Guide.

Starting the Conversation

The trading partner in the role of buyer begins a conversation. The buyer's configuration is shown in the following figure.

 

When the buyer's application starts, the following events occur:

1. The market application, shown in this figure as MarketApplication.java, invokes the C-Enabler API to start a c-enabler session and a conversation. Because of the buyer's role in the conversation definition, the buyer is a conversation initiator. (This has an impact on the code that needs to be implemented in the market application, as opposed to a trading partner in the role of conversation participant, described in Receiving a Business Message and Responding Through WebLogic Process Integrator.)

   When the trading partner creates an XOCP conversation, the trading partner becomes enlisted in the conversation.

2. The market application constructs an XML business document containing a quote request to be sent to trading partners in the role of "supplier." The business document uses the appropriate DTDs specified in the conversation definition to which the trading partner is subscribed.

3. The market application invokes the C-Enabler API to create an XOCP business message containing the XML business document created in step 2.

4. The market application sends the XML business message through the transport service to the c-hub, and then waits for a system reply from the c-hub.

   The specific replies that the application may receive depends on the message Qualities of Service (QoS) settings that have been established. For example, with the lowest QoS, there is no reply and the return is immediate. With the highest QoS, the reply contains the list of trading partners to whom the message has been delivered. In the latter case, the system reply arrives only when one of the following events has occurred:

   • All trading partners have received the business message.

   • The message has expired.

Broadcasting a Message to Trading Partners

When the buyer's XOCP business message arrives at the c-hub, the c-hub messaging service executes the sequence shown in the following figure:

 

The preceding figure shows that the messaging service in the c-hub is made up of three components: the transport service, the scheduling service, the routing service. Among these services are decoder, encoder, router, and filter modules that do specialized processing of the business messages, described in the following sequence:

1. The transport service receives and passes the message to the appropriate decoder module.

2. The decoder:

   • Processes the protocol-specific headers, creating the message envelope

   • Identifies the sending trading partner (in this case, the buyer)

   • Prepares a system reply to be returned to the buyer, which is returned immediately if this QoS is requested

   • Passes the business message to the scheduling service

3. The scheduling service queues the business message for the router.

4. The router processes the router logic plug-ins that are configured for the current conversation definition. In the case of an XOCP business message, at a minimum the BEA-provided XOCP router logic plug-ins are processed. The XOCP router logic plug-in typically consists of a sequence of Xpath expressions that are maintained in the repository. The purpose of an Xpath expression in the XOCP router logic plug-in is to add or remove recipients to the list of trading partners who will receive the message.

   If the incoming business message uses the RosettaNet protocol, BEA provides a RosettaNet router logic plug-in to process routing operations, such as matching the DUNS number of the incoming business message and matching that number to a trading partner identity in the repository and updating the message header.

   Note that the c-hub administrator can add one or more user-written logic plug-ins to the router — for example, to implement a billing function. A series of such plug-ins in the router is called a router chain. For information about creating logic plug-ins, see Developing Logic Plug-Ins in the BEA WebLogic Collaborate Developer Guide. For information about configuring the router chain, including adding or removing logic plug-ins and specifying Xpath expressions, see Routing and Filtering XOCP Business Messages in the BEA WebLogic Collaborate C-Hub Administration Guide.

5. The routing service performs final validation of the message recipients, and queues the message for the filter chain of the selected recipients.

6. The filter processes the filter logic plug-ins that are configured for the current conversation definition. In the case of an XOCP business message, at a minimum the BEA-provided XOCP filter logic plug-ins are processed. As with the router, the XOCP filter logic plug-in typically consists of a sequence of Xpath expressions that are maintained in the repository. The purpose of an Xpath expression in the XOCP filter logic plug-in is to accept or reject a business message intended for a particular recipient.

   If the outgoing business message uses the RosettaNet protocol, BEA provides a RosettaNet filter logic plug-in for completeness, although it does not perform any operations.

   Note that the c-hub administrator can add one or more user-written logic plug-ins to the filter. A series of such plug-ins in the filter is called a filter chain. For information about creating logic plug-ins, see Developing Logic Plug-Ins in the BEA WebLogic Collaborate Developer Guide. For information about configuring the filter chain, including adding or removing logic plug-ins and specifying Xpath expressions, see Routing and Filtering XOCP Business Messages in the BEA WebLogic Collaborate C-Hub Administration Guide.

7. The scheduling service performs any Quality of Service functions on the business message, as required, and passes the business message to the encoder.

8. The encoder prepares the business message for the transport service.

9. The transport service sends the business message onto the recipient trading partners. This causes the following two events to occur:

   1. The recipient trading partners are enlisted in the conversation.

   2. The system reply is sent back to the originating trading partner if the QoS requires it.

Receiving a Business Message and Responding Through WebLogic Process Integrator

In this scenario, the suppliers each have a configuration that includes the WebLogic Process Integrator software, as shown in the following figure. Note that the WebLogic Process Integrator software is not a mandatory component of a trading partner platform, but it is shown in this figure as an example.

Regardless of whether a trading partner is configured with WebLogic Process Integrator, in order to be invoked in conversations, the c-enabler for a trading partner must be running, have joined the c-space, and be registered for the conversation. (Note that The C-Hub Sending a Response to the Buyer describes a scenario in which a c-enabler that does not use WebLogic Process Integrator receives a message.)

 

When the business document arrives at each supplier's c-enabler, the following events occur:

1. The WebLogic Process Integrator process engine, which is a subscriber to WebLogic Collaborate events, receives the business document and instantiates the workflow instance that matches the conversation definition identified in the business message.

2. The workflow instance starts and processes the incoming business document by passing it to a user-written Java message manipulator class, ExtractData.java, which extracts the information from the incoming XML business document and passes that information back to the workflow instance.

3. Because approving the quote request requires human intervention, the workflow instance adds a task to the Worklist. The use of the Worklist is not mandatory. A trading partner has the flexibility to create whatever user interface applications are appropriate for its business processes that require human intervention.

4. The human user at the supplier site starts the worklist, double-clicks the task, and approves the request.

5. The workflow instance invokes another user-written Java message manipulator class, CreateDocument.java, to create an XML business document containing the response.

6. The message manipulator class returns the business document to the workflow instance.

7. The workflow instance passes the business document to the supplier's c-enabler.

8. The c-enabler prepares the XOCP protocol metadata for the business message containing the XML document, and sends it to the c-hub.

The C-Hub Sending a Response to the Buyer

The c-hub processes the supplier's response similar to how the c-hub processed the buyer's business message, applying Xpath routing and filtering expressions as necessary.

When the buyer's c-enabler receives the XOCP business message, the following events occur:

1. The c-enabler passes the business message to the market application via the conversation handler. The application is invoked asynchronously.

2. The conversation handler passes the business message to the local Java class, ProcessPriceResponse.java.

3. The Java class extracts the data from the business message, and returns the data to the market application.

4. The market application may invoke the C-Enabler API to terminate the conversation or send another message. If the market application terminates the conversation, the following events occur:

   1. The c-enabler sends the termination to the c-hub.

   2. The c-hub propagates the termination notice to all the trading partners enlisted in the conversation.

   3. Each trading partner receives the termination notice from the c-hub.

This concludes the end-to-end view of WebLogic Collaborate. The next section describes the other topics covered in this document and the rest of the WebLogic Collaborate documentation set.

 

---

Documentation Road Map

The following topics are described in this document and throughout the entire WebLogic Collaborate documentation set:

• Installing the WebLogic Collaborate software — See the BEA WebLogic Collaborate Installation Guide for complete details about the installation prerequisites, installation steps, and installation verification instructions.

• WebLogic Collaborate Tour — See the tour to get a high-level description of the WebLogic Collaborate architecture and how to build and run an example furniture exchange.

• Setting up the WebLogic Collaborate environment — See Setting Up the WebLogic Process Integrator Environment, in this document for instructions on setting up WebLogic Collaborate to work with WebLogic Process Integrator. You need to complete this step to run the WebLogic Process Integrator-based example.

• Example applications — See Running the WebLogic Process Integrator Verifier Example, and Using Logic Plug-Ins for Billing, in this document for instructions on building and running two WebLogic Collaborate example applications.

• Configuration and monitoring tools — See the BEA WebLogic Collaborate C-Hub Administration Guide and the BEA WebLogic Collaborate C-Enabler Administration Guide for complete documentation on using the administration service to perform configuration, administration, and monitoring tasks associated with running, respectively, a c-space and a trading partner platform.

• Online help — When you use the C-Hub Administration Console or the C-Enabler Administration Console, click on the Help menu to obtain full, context-sensitive online help.

• Developing applications — See the BEA WebLogic Collaborate Developer Guide for a details about building and deploying trading partner, logic plug-in, and administration applications for the WebLogic Collaborate environment.

• Programmer reference documentation — See the BEA WebLogic Collaborate Javadoc for reference information on all the API packages provided with both WebLogic Collaborate and WebLogic Process Integrator.

• WebLogic Process Integrator documentation:

  • BEA WebLogic Process Integrator Studio Guide explains how to use Studio to design workflows.

  • BEA WebLogic Process Integrator Worklist Guide explains how to use Worklist to view, perform, and work with tasks that are currently the roles to which you are subscribed.

  • BEA WebLogic Process Integrator Tutorial provides a tutorial on using the WebLogic Process Integrator software.