bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Introducing WebLogic Integration

B2B Integration

Enterprises interact with customers, suppliers, and trading partners in different ways. Many businesses use electronic data interchange (EDI) for business communication. Using this technology, business systems exchange structured messages using agreed upon message standards over private networks run by EDI service companies. Other businesses engage in collaborative arrangements with a variety of trading partners over the Internet. In these arrangements, trading partners need to link existing back-end applications, databases, and customers together so they can engage in real-time business transactions using a variety of business protocols.

WebLogic Integration provides the next-generation infrastructure that enables this level of inter-enterprise integration. WebLogic Integration provides a B2B integration framework for messaging, connectivity, and business protocols that businesses can use to develop collaborative arrangements with numerous trading partners over the Internet. WebLogic Integration also enables businesses to integrate EDI environments with WebLogic Integration.

The following sections describe the B2B integration functionality provided by WebLogic Integration:

- B2B Integration Framework

- Integration with Business Processes

- APIs and Logic Plug-Ins for B2B Application Development

- Samples

- EDI Integration

B2B Integration Framework

The B2B integration framework provides the following key features to enable collaboration between trading partners:

- Conversation definition and monitoring

- Trading partner configuration and management

- Business protocol support

- Collaboration agreement definition and management

- Security services

- Zeroweight client support

The following sections provide details about each of these features.

Conversation Definition and Monitoring

In an e-business environment, collaboration between trading partners occurs through the exchange of business messages that contain XML or nonXML documents in a secure, choreographed arrangement called a conversation. A conversation is, quite simply, a series of business messages exchanged between trading partners.

Figure 3-1 Conversation Between Trading Partners

As Figure 3-1 shows, the composition of business messages and the sequence of an exchange is typically handled by collaborative or public business processes. The composition and sequence of messages can also be handled by Java messaging applications. Conversations can be complex and long-running, or they can be short-lived. Each conversation has a unique name. Each participant in a conversation has a conversation role, such as that of a buyer or a supplier in a supply-chain arrangement.

All the details of a conversation, including its name and version, the roles of the participants, and the business protocols it uses, are specified in a conversation definition. Integration specialists create conversation definitions and monitor running conversations using the WebLogic Integration B2B Console. The following figure shows configuration information for a trading partner.

Figure 3-2 WebLogic Integration B2B Console

Trading Partner Configuration and Management

An e-commerce community is formed when a trading partner joins other trading partners to pursue a common business objective. An e-commerce community can exist in different forms, and for different purposes. It might, for example:

- Span multiple departments within a company to manage inventory across the company

- Span multiple companies across firewalls and over the Internet to manage a supply chain or a multistep purchasing arrangement

- Include trading partners both within a company and in other companies, such that one or more trading partners interact with trading partners in other companies

To participate in the conversations of an e-commerce community, integration specialists use the B2B Console to configure trading partners. Specifically, they assign trading partners the names by which they will be known in the conversation, and they specifying the delivery channels to be used for the exchange of business messages.

A delivery channel defines how a trading partner sends and receives messages. It also specifies the business protocol to be used in the conversation (such as ebXML), the transport protocol (such as HTTP), and security parameters. Trading partners can configure their delivery channels to communicate directly with each other in a peer-to-peer configuration, or through an intermediary when deployed in a hub-and-spoke configuration.

Peer-to-Peer Configuration

In a peer-to-peer configuration, trading partners communicate with each other directly through their respective delivery channels, using the RosettaNet or cXML business protocol.

Figure 3-3 Peer-to-Peer Configuration

In this type of configuration, a single trading partner is the controlling entity, and the other trading partners are integrated with it. A peer-to-peer configuration might be used to integrate an enterprise with its suppliers in a supply-chain arrangement.

Hub-and-Spoke Configuration

In a hub-and-spoke configuration, trading partners communicate with each other through an intermediary, or routing-proxy delivery channel, using the XOCP business protocol.

Note: The XOCP business protocol is deprecated as of this release of WebLogic Integration. For information about the features that are replacing it, see the BEA WebLogic Integration Release Notes.

Figure 3-4 Hub-and-Spoke Configuration

In this type of configuration, a single trading partner is the hub that mediates the exchange of messages between the other trading partners enlisted in the conversation. The hub trading partner can perform such tasks as routing and filtering messages, or it can provide customized services to the other trading partners in the conversation. A hub-and-spoke configuration might be used to link buyers and sellers in an electronic marketplace.

Business Protocol Support

Trading partners can use any of the following business protocols supported by WebLogic Integration:

- RosettaNet Implementation Framework 1.1 and 2.0—An industry-wide standard that defines communication protocols for supply-chain partners on a global basis. RosettaNet provides specifications for the RosettaNet Implementation Framework (RNIF), the Partner Interface Processes (PIPs), and business and technical dictionaries.

- cXML (Commerce eXtensible Markup Language)—A protocol that is designed to link buyers and suppliers in arrangements created to allow buyers to browse catalogs and submit purchase orders to suppliers. Buyers can browse a supplier's catalog directly, or businesses can use an Ariba Commerce Server Network to mediate messages between buyers and suppliers. The B2B integration framework provides a cXML API so that trading partners can send and receive cXML messages.

Note: The cXML business protocol is deprecated as of this release of WebLogic Integration. For information about the features that are replacing it, see the BEA WebLogic Integration Release Notes.

- XOCP (eXtensible Open Collaboration Protocol)—A BEA-specific protocol that is designed to manage long-lived conversations. XOCP supports message multicasting. It also enables businesses to define a number of Quality of Service (QoS) settings, including message durability, length of the timeout period, and number of retry attempts.

Note: The XOCP business protocol is deprecated as of this release of WebLogic Integration. For information about the features that are replacing it, see the BEA WebLogic Integration Release Notes.

- ebXML—WebLogic Integration supports the ebXML Message Service Specification v1.0, which defines the message enveloping and header document schema used to transfer ebXML messages with a communication protocol such as HTTP. A trading partner that deploys WebLogic Integration can use ebXML to interoperate with a trading partner that deploys the trading partner lightweight client, WebLogic Integration - Business Connect.

Collaboration Agreement Definition and Management

Collaboration agreements are a central component of B2B integration because they tie together all the pieces that we have been discussing: conversations and roles, collaborative business processes, and trading partners and delivery channels. Integration specialists use the B2B Console to define collaboration agreements, which map trading partners to the roles specified in conversation definitions. Collaboration agreements reference the delivery channel each trading partner uses, and the business process each role uses to define the sequence in which a role exchanges business messages with other roles in a conversation.

Security Services

The security services provided by the B2B integration framework are built on top of the security services provided by WebLogic Server. They include the following features:

- An SSL-based secure platform for conversations

- Certificate verification that can be used to authenticate the identities of trading partners

- Digital signatures that can be attached to business messages being exchanged by trading partners

- Support for nonrepudiation of origin and nonrepudiation of receipt, which are often required by law for critical business messages

- Data encryption for business protocols that require this support

Zeroweight Client Support

Note: The trading partner zeroweight clients are deprecated as of this release of WebLogic Integration. For information about the features that are replacing them, see the BEA WebLogic Integration Release Notes.

The B2B integration framework provides support for zeroweight clients so that small and medium-size enterprises, or enterprises with few or no back-end integration requirements, can participate in e-business communities simply and inexpensively. Such enterprises can use a Web browser or a file-sharing client to communicate with other trading partners, one of which must have WebLogic Integration deployed. By using zeroweight client support, trading partners can enlist other partners in shared business processes without requiring them to commit any in-house technical resources, and they can leverage their integration solutions across a wider audience.

Integration with Business Processes

WebLogic Integration provides a plug-in framework for creating collaborative or public business processes that implement the various roles in a conversation. To create public processes, integration specialists do the following:

- Define a trading partner conversation using the B2B Console. Information about the conversation includes a definition of the roles, and references to the business protocols and public business processes used by the roles in the conversation. This information is stored in the WebLogic Integration repository.

- Define public processes using the WebLogic Integration Studio, specifying workflow actions, events, and the node properties required to implement each role in a conversation.

- Once the public processes are tested and the conversation runs successfully, export the repository information to an XML file using the B2B Console. Other trading partners can then import the file and use it to set up their environment so they can participate in the conversation.

Public business processes are typically integrated with private business processes. The design and definition of private processes are specific to a particular organization. Private processes are not visible from outside an organization, and they are usually integrated with back-end business systems. As Figure 3-1 shows, a private process can execute an internal business activity, such as retrieving information from a database, and then it can return the result to a public process, which, in turn, forwards the result to a trading partner.

APIs and Logic Plug-Ins for B2B Application Development

WebLogic Integration provides the following application programming interfaces (APIs) and Java classes that developers can use for the creation of B2B applications:

- Managed Beans (MBeans)—BEA implementation of the Java Management Extensions (JMX) Managed Beans API. This API enables developers to create custom applications to monitor aspects of run-time conversations, such as message traffic and run-time statistics for server nodes, delivery channels, business transaction definitions, trading partners, and business messages. The functionality provided by the API is comparable to that provided by the B2B Console.

- Messaging API—Used to develop XOCP applications to exchange business messages. An XOCP application implements a trading partner role to manage a conversation and to handle business messages.

Note: The Messaging API and XOCP business protocol are deprecated as of this release of WebLogic Integration. For information about the features that are replacing them, see the BEA WebLogic Integration Release Notes.

- Logging API—Used to develop B2B applications that can write error, warning, and information messages to a message log.

- Logic plug-ins—Java classes that an intermediary can use to intercept a business message and then to perform additional processing on the message, such as routing and filtering the message, integrating the message with a back-end system, validating the content of the message, or logging the message in a transaction log.

Samples

WebLogic Integration provides the following samples that integration specialists can use to model B2B integration solutions:

- Hello Partner

- Channel Master

- RosettaNet 2.0 Security

- Zeroweight Client

- Messaging API

- ebXML

Hello Partner

The Hello Partner sample demonstrates how two or more trading partners can participate in business communication in a hub-and-spoke configuration. Each trading partner includes public and private business processes.

The public processes handle communication between the partners, exchanging messages using the XOCP protocol. The private processes handle the message content processing. The private processes interact with the public ones to deliver messages to trading partners, and with an associated Java application to process message content.

Note: The XOCP business protocol is deprecated as of this release of WebLogic Integration. For information about the features that are replacing it, see the BEA WebLogic Integration Release Notes.

Channel Master

The Channel Master sample shows how a large trading partner uses WebLogic Integration to automate its supply chain.

The interactions between the trading partners occur in the following sequence:

1. The channel master buyer broadcasts a query for the pricing and availability of a particular item to two supplier trading partners. The broadcast provides an example of multicast communication using the XOCP protocol.

   Note: The XOCP business protocol is deprecated as of this release of WebLogic Integration. For information about the features that are replacing it, see the BEA WebLogic Integration Release Notes.

2. The two supplier trading partners send a reply quote with the price and availability of the requested item to the buyer trading partner, demonstrating point-to-point communications with the buyer.

3. The buyer selects a supplier and sends a purchase order.

4. The selected supplier returns a purchase order acknowledgment.

The interactions between the buyer and the selected supplier also demonstrate point-to-point communication.

RosettaNet 2.0 Security

The RosettaNet sample shows how WebLogic Integration can be used to implement RosettaNet 2.0 PIP 3A2 and PIP 0A1 using workflows. This sample shows two trading partners exchanging business messages that conform to the RosettaNet 2.0 PIP 3A2 standard.

The interactions between the trading partners occur in the following sequence:

1. A customer trading partner sends a price and availability request to a supplier trading partner.

2. The supplier returns an acknowledgment, indicating that it received the request.

3. The supplier then returns a price and availability response.

4. The customer sends an acknowledgment to the supplier, indicating that it received the response.

Zeroweight Client

Note: The trading partner zeroweight clients are deprecated as of this release of WebLogic Integration. For information about the features that are replacing them, see the BEA WebLogic Integration Release Notes.

The Zeroweight Client sample demonstrates how communication can take place between a requestor and a replier trading partner when they do not have WebLogic Integration installed. Communication is achieved using two types of zeroweight clients. The requestor trading partner uses a Web browser client, and the replier uses a file-sharing client.

In the sample, the requestor uses a Web browser to access JSPs served from a remote installation of WebLogic Integration that is configured to handle zeroweight clients. The JSPs create mailboxes that the replier then accesses using its file-sharing client.

Messaging API

Note: The Messaging API is deprecated as of this release of WebLogic Integration. For information about the features that are replacing it, see the BEA WebLogic Integration Release Notes.

The Messaging API sample demonstrates two message delivery methods: synchronous messaging and deferred synchronous messaging. When synchronous messaging is used, a trading partner that sends a message waits for a return from the receiving partner before it continues to execute other tasks. When deferred synchronous messaging is used, the sending partner does not wait for a return from the receiving partner, but continues executing other tasks.

The interactions between the trading partners occur in the following sequence:

1. Partner 1 sends a deferred synchronous message to Partner 2. A logic plug-in delays the delivery of the message for fifteen seconds. Logic plug-ins are Java classes that can intercept and process business messages at run time

2. During the delay, Partner 1 sends a synchronous message to Partner 3.

3. When control returns to Partner 1, it checks to see that the first message was received by Partner 2.

4. Partner 3 sends a reply to Partner 1.

5. Partner 2 then sends a reply to Partner 1.

ebXML

The ebXML sample demonstrates two workflows: one designed for the role of initiator; the other, for the role of participant in a Query Price and Availability (QPA) conversation. Both workflows are designed and used to manage an ebXML-based business process between two trading partners, each of which deploys WebLogic Integration.

EDI Integration

Electronic data interchange (EDI) is a means by which businesses communicate with each other electronically in a structured, standardized way. In an EDI environment, businesses place orders or perform financial transactions by exchanging business messages between computer systems. EDI messages are structured according to an agreed upon message standard, and are processed automatically without human intervention. The structured data in EDI messages is exchanged over private networks called value added networks (VANs). VANs are managed and supported by EDI service companies, and function like electronic post offices, routing electronic messages from sender to recipient systems.

EDI integration functionality connects EDI environments with WebLogic Integration, making it possible to integrate XML-based transactions with EDI-based transactions.

Figure 3-5 EDI Integration

To connect EDI and WebLogic Integration, WebLogic Integration provides provides two components:

- BEA EDI Connect for WebLogic Integration (purchased separately and delivered as Power.Enterprise!, an EDI-capable system)

- BEA WebLogic Adapter for Power.Enterprise!, which supports versions 3.0 and 3.1 of Power.Enterprise! and is delivered with BEA WebLogic Platform. This component, in turn, provides J2EE CA-compliant service and event adapters that connect to Power.Enterprise!.

WebLogic Integration also includes an application view that integration specialists can use to integrate business processes with the EDI system. Using the application view service in a business process, applications can invoke specific functionality in the EDI system using an XML message.

Using the application view event, the EDI system can propagate information to WebLogic Integration using an EDI message. The conversion from EDI to XML, and vice versa, is handled by the EDI-to-XML transformation engine bundled with Power.Server!, the EDI server provided by Power.Enterprise!

Sample EDI Application

WebLogic Integration provides an EDI sample application that demonstrates how WebLogic Integration with the EDI Connect for WebLogic Integration add-on can be used to exchange EDI purchase-order information over a VAN. In the sample application, a supplier trading partner uses the EDI integration functionality of WebLogic Integration to connect to a buyer over a VAN.

The interactions between the buyer and supplier occur in the following sequence:

1. A buyer trading partner submits an EDI purchase order, over a VAN to the supplier.

2. The EDI-to-XML transformation engine bundled with Power.Server! converts the purchase order to XML.

3. The XML document triggers a business process in the supplier application. The business process generates an XML purchase order acknowledgment.

4. The supplier forwards the acknowledgment to the transformation engine which converts it to EDI, and then forwards it over a VAN to the buyer.