BEA Logo BEA WebLogic Collaborate Release 1.0.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

 

   WebLogic Collaborate Doc Home   |   Getting Started   |   Previous Topic   |   Next Topic   |   Contents   |   Index

Overview

 

The BEA WebLogic CollaborateTM 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 ServerTM 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

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

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

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

 


Understanding the Architectural Requirements of an E-Market

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

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

Repository Service

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

In addition, the repository:

Administration Services

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

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:

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:

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:

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

XML Services

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

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:

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:

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:

 


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 procedures described in this section include:

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:

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:

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:

The trading partner application must implement the following functionality:

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:

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:

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:

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:

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:

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:

  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: