Overview

 

Enterprises strive to integrate, automate, and streamline core internal and external business processes to improve their performance in today's dynamic business-to-business (B2B) electronic commerce (e-commerce) environment. These business processes drive a company's e-commerce interactions with their customers, partners, distributors, and suppliers; they can also streamline the company's internal business. Among the target business processes for B2B integration and automation are design and specification, manufacturing and testing, procurement, sales, fulfillment, customer service, and planning. To support these processes, B2B integration must support workflow processing, messaging and routing, and enterprise application integration.

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

WebLogic Collaborate is a software framework and a set of services built on top of BEA WebLogic Server^TM. It builds upon the WebLogic Server foundation by adding a framework for messaging, connectivity, and business protocols. It also integrates the WebLogic Process Integrator workflow capability for designing and managing business processes.

WebLogic Collaborate is implemented entirely in Java and leverages the J2EE standard APIs. XML is used as a standard format for documents exchanged by business partners. WebLogic Collaborate supports HTTP because the World Wide Web is the ubiquitous communication medium for e-business.

WebLogic Collaborate simplifies the implementation and development of business-to-business trading networks, providing opportunities to integrate internal business processes with inter-enterprise business message exchange. A variety of deployment models are supported.

The following sections provide an overview of the WebLogic Collaborate product:

• Feature Highlights for WebLogic Collaborate

• Meeting the Requirements of Your E-Business

• Documentation Roadmap for WebLogic Collaborate

 

---

Feature Highlights for WebLogic Collaborate

WebLogic Collaborate provides an infrastructure platform for integrating business processes that can span multiple corporate departments, multiple enterprises across the Internet, or both. The WebLogic Collaborate platform supports the building of mission-critical, scalable, real-world e-commerce collaborations. Its features include:

• An open, nonproprietary architecture that leverages Java, J2EE, XML, HTTP, HTTPS, and other industry standards to allow rapid system and cross-platform integration, with low barriers to entry.

• Support for multiple business protocols, including XOCP, RosettaNet, and cXML, thus providing the ability to exchange business documents in a secure manner with a variety of trading partners, accommodating the complexity of heterogeneous platforms, different message structures, and different processes in various e-business environments.

• A variety of connectivity options, allowing rapid connectivity among many trading partners for both automated and semi-automated interactions. Connectivity and subsequent business collaborations between trading partner applications are possible entirely within an enterprise or a company, between trading partner applications across company firewalls and over the Internet, or in a combination of the two.

• Support for rapidly enabling trading partners through no-cost lightweight client connectivity, using browser-based interfaces and file-sharing mechanisms.

• Peer-to-peer and mediated messaging models: peer-to-peer messaging allows direct messaging between partners, and mediated messaging supports tasks such as message routing, message content filtering, and value-added services.

• Tools and processes for the effective management of dynamic and diverse trading partner relationships.

• Robust support for secure, high-volume business transaction levels based on BEA's award-winning WebLogic Server^TM technology. BEA's proven, high-availability, 24x7-managed application server technology, with dynamic load-balancing, multithreading, and failover 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.

• Conversation coordination to manage the execution and interaction of trading partner applications within a conversation and to manage conversation life cycles.

• Integration with BEA WebLogic Process Integrator, the BEA workflow automation tool, providing a flexible and dynamic process-based approach to integrate public and private business processes.

• An SSL-based secure platform for conducting collaborations that supports digital signatures, digital receipts, nonrepudiation, and mutual (two-way) authentication using digital certificates among trading partners.

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

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

• Ability to build custom portals by leveraging BEA WebLogic Personalization Server^TM components

• Portal backbone

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

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

 

---

Meeting the Requirements of Your E-Business

WebLogic Collaborate manages enterprise-to-enterprise collaborations, allowing heterogeneous enterprises to interact in diverse business transactions, which can be complex and long-running. The following sections describe requirements for the framework to build such a B2B e-commerce environment, and they explain how WebLogic Collaborate meets these requirements:

• Connecting Trading Partners

• Defining Conversations and Roles

• Managing Business Processes

• Supporting Business Protocols

• Ensuring the Security of Transactions

• Defining Collaboration Agreements

• Managing Conversations

• Managing Systems and Applications

Connecting Trading Partners

A trading partner joins one or more other trading partners to form an e-commerce community with a specific business purpose. Business partners in an e-commerce community can range in size from large enterprises to small divisions within an enterprise. One of the basic building blocks of B2B e-commerce is the trading partner, specifically, the trading partner applications that form the nodes in system-to-system interactions among business partners. An e-commerce community formed by a group of trading partners can:

• Exist entirely within a company, spanning multiple corporate departments (the business purpose for such a community might be inventory management, for example)

• Span multiple companies across firewalls and over the Internet (the business purpose might be supply chain management or multistep purchasing interactions, for example)

• Include trading partners both within a company and in other companies (one or more of the trading partners within a company communicates with trading partners in other companies across the Internet)

A trading partner must have a special identity that defines where it fits with the business purpose of the e-community. In the WebLogic Collaborate environment, a trading partner refers specifically to an entity that has an agreement with another entity to participate in a specific business exchange, or conversation, in a specific role that is defined for the conversation.

To meet the requirements of today's diverse B2B e-commerce activities, an enterprise must be able to use a variety of connectivity options. Such flexibility is necessary if a company wants to participate in business transactions with a large set of trading partners with diverse processes and protocols.

To that end, a WebLogic Collaborate trading partner application can be configured to communicate directly with other trading partners in a peer-to-peer mode, or through an intermediary in the hub-and-spoke mode, or both. These different configuration modes allow for either direct or mediated messaging between trading partners. An intermediary in the message flow can perform tasks such as routing and filtering of messages, or it can provide services to the trading partners in the conversation. For more details about modeling your WebLogic Collaborate configurations, see Configuration Models.

 

Some business partners may have modest back-end integration requirements, or may need to participate in collaborative processes without installing the WebLogic Collaborate software. WebLogic Collaborate supports lightweight clients to give small and medium-size enterprises, or enterprises with little or no back-end integration requirements, a simple integration path through which they can participate in e-business communities. Such enterprises can use a Web browser or a file-sharing client to communicate with business partners who deploy WebLogic Collaborate as their trading partner server. The instance of WebLogic Collaborate to which they connect acts as a server for their needs. For details about setting up and configuring trading partner lightweight clients, see Using BEA WebLogic Collaborate Samples.

The following figure illustrates a simple scenario in which WebLogic Collaborate is deployed in peer-to-peer relationships between customers and suppliers in a value chain. A customer or supplier trading partner can support multiple peer-to-peer business partnerships with other trading partners.

Figure 1-1 Peer-to-Peer Messaging Among Trading Partners

 
 
 

The following figure illustrates a scenario in which WebLogic Collaborate is deployed as a Net Market, providing intermediary services to several trading partners. For example, this might be an auction service, in which the Net Market is the auction broker.

Figure 1-2 Mediated Messaging in a Net Market

 

Defining Conversations and Roles

When trading partners join other trading partners to form an e-community with a specific business purpose, they participate in a conversation. In WebLogic Collaborate, a conversation:

• Is a series of business messages exchanged between trading partners

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

• Has a unique conversation name

The business messages that can be exchanged between participants in the conversation are determined by the roles the trading partners play in the conversation. The roles and other details of a conversation are specified in a conversation definition using the WebLogic Collaborate Administration Console. A conversation is an active instance of a conversation definition.

A conversation definition:

• Has a unique name and version.

• Defines two or more roles to be used by trading partners in a conversation. The kinds of messages trading partners may send and receive are dictated by their roles in the conversation.

• Is linked to a business protocol.

• Typically references a WebLogic Process Integrator collaborative workflow template for each role. The message choreography for a conversation is described in these collaborative workflow templates.

  Note: Using BEA WebLogic Process Integrator is the recommended approach to composing business messages and choreographing their exchange in conversations. Alternatively, you can write Java WebLogic Collaborate messaging applications that use the WebLogic Collaborate Messaging API or the cXML API. When you use such messaging applications, conversation definitions do not reference a workflow template.

For details about writing messaging applications using the WebLogic Collaborate Messaging API and the cXML API, see Programming BEA WebLogic Collaborate Messaging Applications and Implementing cXML for BEA WebLogic Collaborate, respectively.

When you use WebLogic Process Integrator to compose business messages and manage their exchange in a conversation, each trading partner who participates in the conversation in a given role must implement the collaborative workflow required for its role. Collaborative workflows encapsulate the processes required to handle the right business messages at the right time for a given trading partner's role in a conversation.

For example, the following figure represents a simple conversation with two participating roles, buyer and supplier, and hypothetical workflows for the two roles.

Figure 1-3 Collaborative Workflows in a Query Price and Availability Conversation

 

In this figure, note the following:

• The business messages—Two business messages, PriceAndAvailabilityQuote and PriceAndAvailabilityResponse, are exchanged between trading partner applications.

• The buyer and supplier roles—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 collaborative workflows—Each role has its own set of tasks required to send and receive the right business messages at the right times. In the WebLogic Collaborate environment, a trading partner implements a collaborative workflow for a particular role in a conversation.

Managing Business Processes

Using BEA WebLogic Process Integrator^TM is the recommended approach to composing business messages and choreographing their exchange in conversations. Alternatively, you can write Java WebLogic Collaborate messaging applications that use the WebLogic Collaborate Messaging API or the cXML API. This section discusses the approaches to developing and managing messaging applications in WebLogic Collaborate.

Workflows are business processes. Business processes can span multiple applications, corporate departments, and business partners (trading partners) behind a firewall and over the Internet. An enterprise's business processes can be divided into two broad categories: public and private.

Public and Private Business Processes

Business processes can be designed as public or private processes.

Public processes are interface processes. Their definitions and designs are known, understood, and agreed upon by the organizations using them, and may be customized or standardized across an industry or industry segment, as in the case of RosettaNet Partner Interface Processes (PIPs). They are part of a formal contract between trading partners that specifies the content and semantics of message interchanges. These processes can be implemented in different ways by different trading partners.

In the context of WebLogic Collaborate, when collaborative workflows are intended to be reused in multiple conversations with different business partners, they should be designed as public processes.

Participants in a conversation can also implement private, noncollaborative workflows, which can integrate their back-end processing. Private processes are the business processes conducted within an organization. Their definitions and designs are specific to that organization and are not visible outside it. Within trading partner enterprises, private processes interface with public processes and with back-end business systems. In the context of public processes, private processes can be thought of as subworkflows or subprocesses that implement tasks that are part of the public workflow. For example, a trading partner may implement a private workflow that works in conjunction with a collaborative workflow and that implements the processes that occur locally to a trading partner, but that are not necessarily dictated by the conversation definition.

Using BEA WebLogic Process Integrator

WebLogic Process Integrator is a workflow automation tool. It automates and integrates a business process by managing the sequence of activities in the process and invoking the appropriate resources required by the activities or steps in the process. The components of WebLogic Process Integrator include a workflow design tool (the WebLogic Process Integrator Studio), a GUI monitoring tool (the WebLogic Process Integrator Worklist), and the Process Engine that monitors and controls workflows.

In the WebLogic Collaborate environment, a WebLogic Process Integrator collaborative workflow is a workflow that implements a role in a conversation definition for a trading partner. The message choreography for a WebLogic Collaborate conversation is defined by collaborative workflow templates: one template is defined for each role in the conversation definition, as described in Defining Conversations and Roles.

WebLogic Collaborate provides a plug-in to the WebLogic Process Integrator Studio tool that extends the already powerful business process design tool with functionality that allows you to create collaborative workflows. Using the plug-in functionality, you can compose and extract the contents of business messages, specify the message delivery Quality of Service (QoS), handle message tokens, and so on.

For details about how to use WebLogic Process Integrator, and how it is integrated in the WebLogic Collaborate environment, see Creating Workflows for BEA WebLogic Collaborate.

In summary, business processes in the WebLogic Collaborate environment are defined and managed using WebLogic Process Integrator, which provides the following:

• A visual design tool for creating workflows

• Functionality in the design tool for associating the workflows with a WebLogic Collaborate conversation definition

• A run-time process engine for executing workflows

• Integration with back-end applications via the use of workflow actions

• Worklist: A utility for running workflows interactively

• Process monitoring capabilities

Using the WebLogic Collaborate Messaging API

As an alternative to using WebLogic Process Integrator, a trading partner can implement Java-based XOCP messaging applications based on the WebLogic Collaborate Messaging API. This API was available as the C-Enabler API in WebLogic Collaborate Release 1.0. You can use WebLogic Collaborate Messaging API with WebLogic Collaborate Release 2.0. For details about migrating your C-Enabler API applications from WebLogic Collaborate Release 1.0 to Release 2.0 and for information about using the WebLogic Collaborate Messaging API with Release 2.0, you should see Programming BEA WebLogic Collaborate Messaging Applications and Migrating BEA WebLogic Collaborate to Release 2.0.

Using the cXML API

WebLogic Collaborate supports multiple business protocols for sending and receiving messages (see Supporting Business Protocols). For the cXML (Commerce eXtensible Markup Language) protocol, WebLogic Collaborate provides a cXML API which provides classes that allow the sending and receiving of cXML messages, the creation and manipulation of cXML documents, the mapping of a collaboration agreement to a message, and so on. For details, see Implementing cXML for BEA WebLogic Collaborate.

Supporting Business Protocols

A business message is the basic unit of communication among trading partners and is exchanged as part of a conversation. A business message contains one or more XML business documents, one or more attachments, or a combination of both. The contents and format of a business message depend on the business protocol chosen for the conversation (see Business Messages for details).

A business protocol is associated with a business process, which governs the exchange of business information between trading partners. It specifies the structure of business messages, 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. You bind a business protocol to a conversation definition and a delivery channel for a trading partner. A business protocol is bound indirectly to a collaboration agreement through both the associated conversation definition and associated trading partner's delivery channel (see Defining Collaboration Agreements).

WebLogic Collaborate supports the following business protocols:

• XOCP (eXtensible Open Collaboration Protocol)

• RosettaNet

  • RosettaNet Implementation Framework (RNIF) 1.1

  • RosettaNet Implementation Framework (RNIF) 2.0

• cXML (Commerce eXtensible Markup Language)

By providing the ability to send and receive messages according to these standard protocols, WebLogic Collaborate gives an enterprise a great deal of flexibility and opportunity in organizing its B2B e-commerce by reducing the need for trading partners to standardize on any single protocol.

You can also customize and extend the supported business protocols beyond their out-of-the-box functionality by using WebLogic Collaborate's logic plug-ins. Logic plug-ins are Java classes that can intercept and process business messages at run time. WebLogic Collaborate provides system logic plug-ins, which you can supplement by writing custom logic plug-ins. The system logic plug-ins for XOCP include XOCP Router and XOCP Filter. They are directly involved in the processing of message recipients based on Xpath expressions in the repository. Custom logic plug-ins can perform a wide range of services that are unrelated to routing or filtering, as well as routing and filtering operations. For example, a custom logic plug-in might be used, for billing purposes, to track the number of messages sent from each trading partner.

For details about administering both system and custom logic plug-ins, see Administering BEA WebLogic Collaborate and BEA WebLogic Collaborate Administration Console Online Help. If you want to write custom logic plug-ins, see Programming BEA WebLogic Collaborate Logic Plug-Ins.

XOCP

The eXtensible Open Collaboration Protocol (XOCP) is a BEA-specific business protocol. The XOCP business protocol supports the standards-based ebXML Transport, Routing, and Packaging (TRP) protocol. XOCP provides the following messaging characteristics:

• Message multicasting

  Message multicasting is the ability of the XOCP messaging service to multicast a message from one trading partner to many trading partners, within the constraints of an existing conversation.

  For example, consider the following scenario:

  WebLogic Collaborate is deployed in a hub-and-spoke configuration, where 10 trading partners, configured as spokes, communicate via an intermediary (that is, through a trading partner configured as a hub).

  The business purpose of this e-community is participation in a Query Price and Availability conversation that has two roles: buyer and supplier. One trading partner is in the role of the buyer, and nine are suppliers. The buyer trading partner can, through the intermediary, multicast the Query Price and Availability message to all the trading partners who have agreements to be suppliers in a Query Price and Availability conversation with the intermediary.

• 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

  E-commerce conversations can be complex and long-lived. XOCP is designed to manage long-lived conversations. When a conversation terminates, all trading partners who are participating 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 Quality of Service that allow you to set and control the characteristics of XOCP messages being sent, such as:

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

    Note: Message durability is controlled at the message level by this QoS setting only when you deploy WebLogic Collaborate in nonpersistent mode. When you deploy WebLogic Collaborate in persistent mode, all state records, including messages, are read from and written to a persistent storage database and are not cached in memory. Therefore, all messages are persisted. In other words, when WebLogic Collaborate is deployed in persistent mode, message durability is controlled by the database-based state management mode rather than by the message durability QoS setting. For details about persistent and nonpersistent modes, see Configuring Persistence and Recovery in Administering BEA WebLogic Collaborate.

  • Timeout—Specifies how long a trading partner application waits before terminating all processing related to the business message.

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

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

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

RosettaNet

WebLogic Collaborate supports sending and receiving RosettaNet messages according to both RNIF 1.1 and RNIF 2.0. It also supports interoperability with other RosettaNet partners. In addition, a WebLogic Collaborate plug-in to WebLogic Process Integrator extends the WebLogic Process Integrator functionality with features that allow WebLogic Process Integrator workflows to participate in RosettaNet Partner Interface Processes (PIPs).

RosettaNet is a self-funded, nonprofit consortium of major companies (from the information technology, electronic component, and semiconductor manufacturing industries) working to create and implement industry-wide, open e-business process standards. These standards form a common e-business language, aligning processes between supply chain partners on a global basis. (For complete details about the RosettaNet organization, see http://www.rosettanet.org.) To support its mission, RosettaNet provides specifications for the RosettaNet Implementation Framework (RNIF), the Partner Interface Processes (PIPs), and business and technical dictionaries.

RosettaNet (http://www.rosettanet.org) defines its Partner Interface Processes (PIPs) as follows:

"RosettaNet PIPs are specialized system-to-system XML-based dialogs that define business processes between trading partners. Each PIP specification includes a business document with the vocabulary, and a business process with the choreography of the message dialog. PIPs fit into seven clusters, or groups of core business processes, that represent the backbone of the supply chain network. Each cluster is further subdivided into segments, which are cross-enterprise processes involving more than one type of supply chain partner. Within each segment are individual PIPs."

PIPs contain one or more Activities, and Activities, in turn, specify Actions. PIPs apply to the following core processes:

• Administration

• Partner, Product, and Service Review

• Product Introduction

• Order Management

• Inventory Management

• Marketing Information Management

• Service and Support

• Manufacturing

The RNIF provides exchange protocols for implementation of the PIPs. The RNIF specifies information exchange between trading partner servers using XML, covering transport, routing and packaging, security, signals, and trading partner agreements.

For details about RosettaNet support in WebLogic Collaborate, see Implementing RosettaNet for BEA WebLogic Collaborate.

cXML

WebLogic Collaborate provides a cXML API so that trading partner servers running WebLogic Collaborate can send and receive cXML messages according to the cXML standard. The cXML API provides classes that allow the sending and receiving of cXML messages, the creation and manipulation of cXML documents, the mapping of a collaboration agreement to a message, and so on.

The http://www.cxml.org Web site defines cXML as follows:

"cXML is a streamlined protocol intended for consistent communication of business documents between procurement applications, e-commerce hubs, and suppliers."

cXML transactions consist of documents that are simple text files with well defined format and content. Most types of cXML documents are analogous to hardcopy documents traditionally used in business. The main types of cXML documents are Catalogs, Punchouts, and Purchase Orders. cXML defines a common DTD for business messages.

The cXML protocol is designed to link buyers and suppliers in scenarios where buyers browse catalogs and submit purchase orders to suppliers. A buyer can browse a supplier's catalog directly; alternatively, an Ariba exchange (Ariba Commerce Server Network) mediates messages between buyer and supplier.

For details about cXML support in WebLogic Collaborate, see Implementing cXML for BEA WebLogic Collaborate.

Business Messages

A business message is the basic unit of communication among trading partners. It is exchanged as part of a conversation. A business message contains one or more XML business documents, one or more attachments, or a combination of both.

The contents and format of a business message depend on the business protocol chosen for the conversation. In WebLogic Collaborate, the primary method used to prepare a business message to be sent to one or more trading partners is the WebLogic Process Integrator collaborative workflow.

This section describes the basic structure of business messages exchanged in the WebLogic Collaborate environment. For details about using the WebLogic Process Integrator Studio to compose and manipulate business messages, see Creating Workflows for BEA WebLogic Collaborate.

XOCP Business Messages

The XOCP business protocol supports the open standard ebXML Transport, Routing, and Packaging (TRP) protocol (see http://www.ebxml.org for the "ebXML Message Service Specification"). The ebXML TRP protocol defines a wire format and protocol for a message service to support XML-based electronic messages.

The following figure represents the structure of a business message exchanged in a conversation based on the XOCP protocol.

Figure 1-4 XOCP Business Message

 

Note the following parts:

• Message envelope—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 (see Messaging Service). The envelope is not part of the transport protocol.

• Message headers that include the following:

  • Transport, Security, and Qualities of Service (QoS) headers—Contain the data required to deliver a message, such as sender and recipient identities, content length and type, and status code.

  • Conversation header—Contains conversation information, sender information, message ID, creation timestamp, and other data. Message attributes can be set by the originating trading partner, or by logic plug-ins, such as the XOCP router or XOCP filter (see Programming BEA WebLogic Collaborate Logic Plug-Ins).

  • Routing header—Contains an expression that identifies a group of recipients for a multicast message.

• Payload—Includes one or more business documents, zero or more attachments, or a combination of both. A business document is an XML document, and an attachment can be any binary (nonXML) part of the message.

  In WebLogic Collaborate, the primary method used to prepare a business message payload to be sent to one or more trading partners is the WebLogic Process Integrator collaborative workflow. That workflow includes a process that adds XOCP headers to an XOCP business message.

RosettaNet Business Messages

WebLogic Collaborate supports sending and receiving RosettaNet messages according to the RosettaNet Implementation Framework, versions 1.1 and 2.0. A business message exchanged in a conversation based on the RosettaNet 1.1 protocol is called a RosettaNet Object (RNO). The entity exchanged in a conversation based on the RosettaNet 2.0 protocol is called a RosettaNet Business Message (RBM).

A WebLogic Collaborate plug-in to WebLogic Process Integrator extends the WebLogic Process Integrator functionality with features that simplify the development of RosettaNet business messages and Partner Interface Protocols (PIPs).

The following figure represents the structure of a RosettaNet Object exchanged in a conversation based on the RosettaNet 1.1 business protocol.

Figure 1-5 RosettaNet Business Message

 

Note the following parts:

• Headers—A RosettaNet Object always contains a Preamble Header and a Service Header.

• Service Content—The payload part of the message. The Service Content contains either an action or a signal message.

• RosettaNet Version, Digital Signature, Content Length, and Digital Signature Length—These parts of the message are in binary format.

The RosettaNet Implementation Framework 2.0 introduced the following notable differences in the composition of a RosettaNet Business Message (RBM):

• Attachments are supported for RosettaNet Implementation Framework 2.0 as an optional part of the RosettaNet message. Attachments are not file type-specific, and may contain binary data. One or more attachments may be included in the payload part of the message.

• The Service Header and Content in RosettaNet Business Messages can be encrypted. Using the WebLogic Collaborate Administration Console, you can configure the system to encrypt the Service Content, Service Header, and any attachments when a message is sent.

• In addition to the Service and Preamble Headers, the RosettaNet Implementation Framework 2.0 defines a Delivery Header.

cXML Business Messages

WebLogic Collaborate supports sending and receiving cXML messages. cXML request and response transactions belong to one of four general types: Profile, PunchOut, Order, or Subscription transactions. The following figure represents the structure of an XML request business message exchanged in a conversation based on the cXML business protocol.

Figure 1-6 cXML Business Message

 

Note the following parts:

• Header containing From, To, and Sender fields:

  • From—Contains information about the originator of the request (the buyer).

  • To—Contains information about the destination of the request (the supplier).

  • Sender—Contains information about the entity that is relaying the request. Typically, this entity is an Ariba exchange (Ariba Commerce Server Network), which mediates messages between buyer and supplier.

• Request containing a Request Type

  A Request Type field contains information about the type of request contained in this message. For example, a request type may be PunchOutSetupRequest. Associated with each request type is one if three operation entities: create, edit, or inspect.

Ensuring the Security of Transactions

Reliable and secure communications are a crucial element in the B2B e-commerce environment. This is true whether e-business collaborations are between partners within an organization or between partners that span multiple organizations across firewalls and over the Internet.

WebLogic Collaborate security is built on top of the security features provided by WebLogic Server; it provides advanced security support and services. WebLogic Collaborate provides support for the following security features:

• An SSL-based secure platform for B2B e-commerce conversations

• Mutual, two-way authentication using digital certificates

  WebLogic Collaborate provides support for certificate verification to authenticate the identities of trading partners. Using the WebLogic Collaborate Administration Console, administrators can configure a certificate verification provider implementation to verify a digital certificate submitted by a trading partner.

• Digital receipts

  A digital signature can be attached to a business document by the parties in a business collaboration. WebLogic Collaborate supports digital signatures at the application level; a trusted third party creates digital receipts.

• Nonrepudiation

  Nonrepudiation of origin and nonrepudiation of receipt is a legal requirement for critical business messages. Nonrepudiation of origin links the message received and the sender of the message, and nonrepudiation of receipt links the message processed and the recipient of the message. To support nonrepudiation, WebLogic Collaborate provides the following services:

  • Digital signature—Used to digitally sign a business document before it is sent to the recipient.

  • Secure timestamp—Used to sequence the occurrence of events in the business transaction.

  • Audit log—Used to store digitally signed business messages with a secure timestamp. Audit logging is necessary for nonrepudiation.

• Data encryption

  WebLogic Collaborate provides a data encryption service for business protocols that require this type of support.

For a comprehensive discussion about WebLogic Collaborate security, and details about configuring security services, see Using BEA WebLogic Collaborate Security.

Defining Collaboration Agreements

A critical component of B2B e-commerce is the establishment and management of agreements among business partners. In the WebLogic Collaborate environment, these agreements take the form of collaboration agreements between trading partners. Using collaboration agreements, trading partners agree on the interactions between them, in particular, the conversations in which they participate, and each trading partner's message sending and receiving characteristics.

Parties in Collaboration Agreements

A conversation definition defines two or more roles to be used by trading partners in a conversation. A party in a collaboration agreement binds a role from the conversation definition to a trading partner. For example, consider a collaboration agreement based on the Query Price and Availability conversation described in Defining Conversations and Roles. There are two parties in this collaboration agreement: one buyer and one supplier (see Figure 1-7).

Delivery Channels in Collaboration Agreements

A trading partner's message sending and receiving characteristics are encapsulated in a WebLogic Collaborate delivery channel. There is generally one delivery channel per trading partner for each business protocol supported by the trading partner.

Note: Trading partners using the XOCP business protocol require two delivery channels: one hub and one spoke. For details about configuring delivery channels in hub-and-spoke mode, see Hub-and-Spoke Configuration.

An application for a trading partner communicates, through its delivery channel, with another trading partner's delivery channel. The interactions can be direct, that is, peer-to-peer between trading partners, or they can be indirect, that is, they can be conducted through an intermediary (routing proxy) delivery channel.

For details about peer-to-peer and hub-and-spoke configurations for WebLogic Collaborate components, see Configuration Models.

You configure and monitor the components of delivery channels using the WebLogic Collaborate Administration Console. A delivery channel includes the following information:

• Business protocol binding (XOCP, cXML, RosettaNet1.1, or RosettaNet2.0)

• Transport protocol (HTTP) and the target Uniform Resource Identifier (URI)

• Security options (digital signatures, digital certificates, and nonrepudiation)

• Reliable messaging options (timeout and retries)

• Message encoding (base64)

Collaboration Agreements in Peer-to-Peer Configurations

Take the Query Price and Availability conversation described in Defining Conversations and Roles as an example. The delivery channels for the participating trading partners isolate the communication details between them.

The following figure illustrates the components of a collaboration agreement between two trading partners participating directly with each other in a business conversation. The trading partners are configured in a peer-to-peer configuration. In this case, the target trading partner for business messages is the other trading partner in the collaboration agreement.

Figure 1-7 Components of a Collaboration Agreement

 

The preceding figure illustrates how each trading partner's delivery channel and the conversation definition (which defines the roles in the conversation) relate to the collaboration agreement between the trading partners.

Collaboration Agreements in Hub-and-Spoke Configurations

When WebLogic Collaborate is configured so that trading partners participate in conversations through an intermediary (or routing proxy), collaboration agreements are created between each trading partner and the intermediary. In this case, trading partners identify the intermediary trading partner (that is, the routing proxy delivery channel) as the target for their business messages.

If, for example, the Query Price and Availability conversation between Trading Partner A and Trading Partner B goes through an intermediary trading partner (Intermediary A), two collaboration agreements are created.

The following figure illustrates the collaboration agreements created between Trading Partner A, Intermediary A, and Trading Partner B for a Query Price and Availability conversation in which Intermediary A is an intermediary trading partner.

Figure 1-8 Collaboration Agreements Between Trading Partners in a Hub-and-Spoke Configuration

 

Note the following in the preceding figure:

• The delivery channel for the trading partner (Intermediary A) in the role of routing proxy has collaboration agreements with both the supplier and buyer trading partners.

• In the collaboration agreement named QueryPrice_101, Trading Partner A is the buyer and Intermediary A is the supplier (in effect, the proxy supplier).

• In the collaboration agreement named QueryPrice_202, Trading Partner B is the supplier and Intermediary A is the buyer (in effect, the proxy buyer).

Managing Conversations

Critical to managing successful relationships between trading partners is the ability to provide robust services to ensure the integrity of business messages while they are being exchanged in various types of trading partner collaborations. WebLogic Collaborate provides a messaging service and a conversation coordination service, as described in the following sections.

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.

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

• Support, in native mode, for multiple XML-based business protocols, including XOCP, RosettaNet 1.1, RosettaNet 2.0, and cXML

• Support for blocking and nonblocking message delivery

• Quality of Service (QoS) capabilities for XOCP-based messages, including the ability to establish durability, confirm receipt, track messages, message timeout, retry, and other settings for messages exchanged among trading partners

• Routing and filtering capabilities, controlling which trading partners receive messages

• Accommodation of the insertion of user-written code to customize the handling of incoming or outgoing messages or to perform messaging-related operations, thus extending the functionality of standard business protocols

Conversation Coordination Service

Business conversations can be complex and long running—some conversations may last several days. Conversations always have life cycles, which are explicitly demarcated by a beginning and an end. The WebLogic Collaborate software provides a conversation coordination service.

The WebLogic Collaborate conversation coordination service is business protocol-specific. Business protocols define their conversation termination protocols in different ways. In the case of XOCP-based conversations, the conversation coordinator does the following:

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

• Enlists new trading partners in the conversation

• Removes trading partners from the conversation if they submit requests to leave the conversation

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

• Allows monitoring of the active conversations for a trading partner

Managing Systems and Applications

Except for workflows, WebLogic Collaborate system components are configured and managed primarily through the WebLogic Collaborate Administration Console, which works together with a repository service.

Business process (workflow) management is achieved through tight integration of WebLogic Collaborate with WebLogic Process Integrator. The WebLogic Process Integrator software provides business partners with a workflow process engine that controls the execution of local business processes and manages the integration of back-end enterprise applications with business processes. See Managing Business Processes for more details.

This section describes the following WebLogic Collaborate management services:

• Repository Service

• Administration Services

  • WebLogic Collaborate Administration Console

  • Bulk Loader

  • Java Management Extensions Management Beans

• Logging Service

The following figure represents the WebLogic Collaborate services described here and in Managing Conversations.

Figure 1-9 WebLogic Collaborate Services

 

Repository Service

The repository service stores data into the repository. This data is required by trading partners to engage in business-to-business collaborations, and includes:

• Trading partner-specific information

• Conversation definitions

• Collaboration agreements

• Business protocol definitions

• Document definition (DTD) names

• Document and configuration information

• Data used for message routing and filtering operations

In addition, the repository:

• Is accessible through the WebLogic Collaborate Administration Console for system administration, creation of collaboration agreements by business developers, and monitoring of trading partners, conversations, collaboration agreements, and so on

• Supports the import and export of data using the WebLogic Collaborate Administration Console and a Bulk Loader utility

• Supports Oracle, Microsoft SQL Server, and Cloudscape as primary data stores

For details about the repository and the Bulk Loader, see Working with the Repository and Working with the Bulk Loader in Administering BEA WebLogic Collaborate.

Administration Services

The WebLogic Collaborate administration services support multiple system management functions, including configuring, administering, and monitoring trading partners, conversations, collaboration agreements, and more.

Through these services, a WebLogic Collaborate administrator can create, configure, and manage the components of the WebLogic Collaborate system. Business developers can set up collaboration agreements and monitor system status. In addition, business partners can use the administration services to start and end trading partner sessions, leave or end conversations, and enable, disable, start, or shut down delivery channels.

WebLogic Collaborate Administration Console

Primary access to the administration services in WebLogic Collaborate is through the Web-based WebLogic Collaborate Administration Console. All configuration information is stored in the WebLogic Collaborate repository, which is supported by a database management system. The components of the WebLogic Collaborate system that you can configure and monitor include the following:

• Trading partners

• Conversations

• Collaboration agreements

• Business protocols

• Logic plug-ins

To facilitate data and business process exchange among trading partners, the import and export functions of the WebLogic Collaborate Administration Console allow you to export repository data to an XML file, and import data from an XML file to your WebLogic Collaborate repository.

You can select the scope of the exported data from the repository such that the XML file you create contains either all the data in the repository, or only data related to one of the following entities: trading partners, conversation definitions, collaboration agreements, business protocol definitions, or logic plug-ins.

For complete details about using the WebLogic Collaborate Administration Console, see Administering BEA WebLogic Collaborate and BEA WebLogic Collaborate Administration Console Online Help.

Bulk Loader

In addition to using the WebLogic Collaborate Administration Console to export and import data from and to your WebLogic Collaborate repository, you can use the Bulk Loader facility (from the command line) to export and import repository data. Like the import and export functions of the WebLogic Collaborate Administration Console, the Bulk Loader utility supports export of either all the data in the repository or only a subset of the data to the XML file. For details about the Bulk Loader, see Using the Bulk Loader in Administering BEA WebLogic Collaborate.

Java Management Extensions Management Beans

For monitoring only, WebLogic Collaborate supports user-written applications that use Java Management Extensions (JMX) Management Beans (MBeans) to view data and statistics maintained by the administration services.

Trading partners can use the JMX MBeans through an MBean server (a repository for MBeans), which is included in the administration services package, to send and receive messages to and from the administration services.

For details about programming management applications, see Programming BEA WebLogic Collaborate Management Applications.

Logging Service

WebLogic Collaborate provides a logging capability for error and information messages. All WebLogic Collaborate log messages are time-stamped, and can be sent to the WebLogic Server log, or to a separate log file. For details, see Writing Messages to the BEA WebLogic Collaborate Log.

 

---

Documentation Roadmap for WebLogic Collaborate

The following table shows where, in WebLogic Collaborate documentation, you can find more detailed information about various features of your WebLogic Collaborate software.

To learn more about . . .	Consult . . .
Installation	Installing BEA WebLogic Collaborate BEA WebLogic Collaborate Release Notes
Migrating from WebLogic Collaborate 1.0 to WebLogic Collaborate 2.0	Migrating BEA WebLogic Collaborate to Release 2.0
WebLogic Collaborate terminology	BEA WebLogic Collaborate Glossary
Administration (configuration and monitoring)	Administering BEA WebLogic Collaborate BEA WebLogic Collaborate Administration Console Online Help Using BEA WebLogic Collaborate Security
Administration (setting up trading partner lightweight clients)	Trading Partner Lightweight Client Sample in Using BEA WebLogic Collaborate Samples
Business processes and collaborative workflows	Creating Workflows for BEA WebLogic Collaborate Implementing RosettaNet for BEA WebLogic Collaborate Implementing cXML for BEA WebLogic Collaborate
Security	Using BEA WebLogic Collaborate Security
Business protocol support (XOCP, RosettaNet, cXML)	Creating Workflows for BEA WebLogic Collaborate Implementing RosettaNet for BEA WebLogic Collaborate Implementing cXML for BEA WebLogic Collaborate Programming BEA WebLogic Collaborate Logic Plug-Ins
Sample applications shipped with WebLogic Collaborate	Using BEA WebLogic Collaborate Samples
Browser and file-sharing clients	Trading Partner Lightweight Client Sample in Using BEA WebLogic Collaborate Samples
Programmer reference and APIs	BEA WebLogic Collaborate Javadoc
WebLogic Collaborate configuration models and architecture	Getting Started Using WebLogic Collaborate, in this document Configuration Tasks in Administering BEA WebLogic Collaborate
BEA WebLogic Process Integrator	The BEA WebLogic Process Integrator document set is available at the following URL: http://download.oracle.com/docs/cd/E13214_01/wlintegration/v2_0/processintegrator/index.htm This set includes the following documents: Using the BEA WebLogic Process Integrator Studio explains how to use the Studio to design workflows. Using the BEA WebLogic Process Integrator WorkList explains how to use the Worklist to view, perform, and work with tasks that are currently associated with the roles to which you are subscribed. Learning to Use BEA WebLogic Process Integrator provides a tutorial on using the business process management software.
Message routing and filtering using logic plug-ins	Programming BEA WebLogic Collaborate Logic Plug-Ins
Advanced programming options	Programming BEA WebLogic Collaborate Management Applications Programming BEA WebLogic Collaborate Logic Plug-Ins Writing Messages to the BEA WebLogic Collaborate Log Programming BEA WebLogic Collaborate Messaging Applications