Introducing the C-Hub

 

The following sections introduce the c-hub component of the BEA WebLogic Collaborate system:

• C-Hubs

• Architecture

• Message Processing

• Configuration and Monitoring

• Repository

• Responsibilities and Tasks

Before you read this document, it is recommended that you read the BEA WebLogic Collaborate Getting Started document.

 

---

C-Hubs

The following sections describe c-hubs:

• C-Hubs and C-Enablers

• C-Hub Services

C-Hubs and C-Enablers

An electronic marketplace, or e-market, is an environment through which companies conduct business-to-business e-commerce. E-markets offer a set of services to conduct, manage, and orchestrate conversations between various trading partners.

WebLogic Collaborate offers a flexible, extendable, and scalable solution for implementing e-markets. A WebLogic Collaborate system consists of the following main parts:

• A c-hub

• One or more c-enablers

The following figure shows an example of the relationships among c-hubs, c-spaces, and c-enablers. Each trading partner uses a c-enabler to join a c-space, which exists in a c-hub. By joining a c-space, the trading partner can participate in conversations with other trading partners.

Figure 1-1 Architecture of a Possible WebLogic Collaborate Configuration

 

In the figure, c-enabler #3 is colocated with the c-hub, which means that they are deployed on the same BEA WebLogic Server^TM instance. A c-hub runs on a single WebLogic Server instance, and a WebLogic Server instance can host a single c-hub. However, multiple c-enablers can run on a single WebLogic Server instance, as illustrated by c-enablers #1 and #2 in the figure. Instead of running on WebLogic Server, a c-enabler can run on WebLogic Express as illustrated by c-enabler #4.

A c-hub node (the machine on which a c-hub is running) can host one or more c-enablers, as illustrated by c-enabler #3. In the figure, the c-enablers are deployed on various WebLogic Servers or WebLogic Express, but all the c-enablers participate in the same c-space. A non-XOCP client can also participate in a c-space.

A c-hub represents an e-market owner and can host multiple c-spaces. Each trading partner can subscribe to business conversations, which are communicated through a mediated messaging system, and define local workflow and actions to execute upon receipt of business events (messages or documents).

The c-enabler is a 100-percent Java class library that is deployed at each participant node to allow access to c-spaces hosted on a c-hub. The c-enabler is typically downloaded with authorization from the e-market administrator. For a detailed description of c-enablers, see the BEA WebLogic Collaborate C-Enabler Administration Guide.

For a complete explanation of e-markets, collaboration, and other related concepts, see the Overview section in BEA WebLogic Collaborate Getting Started.

C-Hub Services

A c-hub provides the following shared services to c-enablers:

• Subscription management

• Conversation coordination

• Security

• Administration

• Routing and filtering

• Logging

• XML services

 

---

Architecture

The following figure shows the c-hub architecture. WebLogic Collaborate runs on WebLogic Server. The c-hub can integrate with any packaged, custom, or mainframe applications running on WebLogic Server.

Figure 1-2 C-Hub Architecture

 

 

---

Message Processing

The following figure illustrates how a c-hub processes a message.

Figure 1-3 Message Processing

 

The following steps describe the preceding figure:

1. The transport service reads the incoming message and forwards it to the appropriate decoder based on the message protocol, such as XOCP or RosettaNet. The URL on which the transport service receives the message identifies the protocol and the c-space. For information about business protocols, see Configuring Business Protocols.

2. The decoder processes the protocol-specific headers, identifies the sending trading partner, enlists the sending trading partner in a conversation, prepares a reply to return to the sender, and forwards the message to the scheduling service.

3. The scheduling service enqueues the message to store it for subsequent retrieval and forwards the message to the router.

4. The router determines the trading partners to whom the message should be routed and forwards the message to the routing service. You can use logic plug-ins to add recipients to or delete recipients from the list. For information about routing, see Routing and Filtering XOCP Business Messages. For information about logic plug-ins, see Developing Logic Plug-Ins in the BEA WebLogic Collaborate Developer Guide.

5. The routing service performs the final validation of the message recipients, stores the message for delivery to each validated recipient, and forwards one copy of the message to the filter for each validated recipient.

6. The filter receives the message for a specific recipient and determines whether or not to send the message to the recipient. You can use logic plug-ins to affect how this decision is made. If the message is going to be sent to the recipient, the filter forwards the message to the scheduling service. For information about filtering, see Routing and Filtering XOCP Business Messages. For information about logic plug-ins, see Developing Logic Plug-Ins in the BEA WebLogic Collaborate Developer Guide.

7. The scheduling service performs additional internal operations related to quality of service issues and conversation management. The scheduling service forwards the message to the encoder. For information about quality of service, see the BEA WebLogic Collaborate Developer Guide.

8. The encoder transforms the message as necessary to support the business protocol and forwards the message to the transport service.

9. The transport service sends the message to the recipient.

 

---

Configuration and Monitoring

The C-Hub Administration Console enables you to create, configure, and monitor a c-hub. For information about the C-Hub Administration Console, see Using the C-Hub Administration Console, which is Part II in this document.

The Bulk Loader enables you to create and configure a c-hub. For information about the Bulk Loader, see Working with the Bulk Loader.

You can create c-hub management applications that use the c-hub MBeans to monitor c-hub run-time activities. MBeans function as a monitoring API that is based on the Java Management Extensions (JMX) published by Sun Microsystems, Inc. For information about working with the c-hub MBeans, see the BEA WebLogic Collaborate Developer Guide.

 

---

Repository

The repository is a database that stores configuration information for the c-hub object. The following figure shows the relationships among elements in the repository. Solid lines represent inclusion, which means that if you remove an element, all the inclusion elements are also deleted. For example, if you remove a c-space, then all the collaborators for that c-space are also removed. Dashed lines represent reference, which means that if you remove an element, the elements referenced by the removed element are not removed. For example, if you remove a business protocol, the reference to the business protocol definition is removed, but the business protocol definition remains.

Figure 1-4 Element Relationships

 

To manage the information in the repository, you can:

• Use the C-Hub Administration Console as described in Using the C-Hub Administration Console, which is Part II in this document.

• Use the Bulk Loader as described in Working with the Bulk Loader.

The following sections provide overviews of the main elements in the repository:

• C-Hubs

• C-Spaces

• Conversation Definitions and Roles

• Document Definitions

• Trading Partners and Trading Partner Protocols

• Logic Plug-Ins

• Business Protocols and Business Protocol Definitions

• Message Definitions

C-Hubs

Description:	The c-hub is the root definition in the repository. Most high-level elements such as c-spaces, conversation definitions, trading partners, document definitions, logic plug-ins, and business protocol definitions stem from this root.
Relationships:	There is a one-to-many relationship between a c-hub and the other elements in the repository. For example, one c-hub can host multiple c-spaces; but for every c-space, there is only one c-hub. Likewise, one c-hub can host multiple trading partners; but for every trading partner, there is only one c-hub.
Interface:	C-hubs are represented by the HubMBean interface in the com.bea.b2b.management.hub.runtime package. C-hub management applications use HubMBean objects to monitor c-hubs.

 

C-Spaces

Description:	A c-space is a virtual place where predefined trading partners can conduct and coordinate conversations with each other. A c-space has a specific business purpose and logically represents an electronic marketplace or common trading environment. It provides the administration capability, conversation coordination, and underlying messaging services that are used to create a dynamic business-to-business integration environment. Each c-space/business protocol combination has a unique URL. A trading partner uses this URL to access a particular c-space using a particular business protocol.
Relationships:	There is a one-to-many relationship between a c-hub and c-spaces. A c-hub can host multiple c-spaces; but for every c-space, there is only one c-hub. There is a one-to-many relationship between a c-space and business protocols. There is also a one-to-many relationship between a c-space and collaborators. For example, one c-space can include many business protocols and many collaborators.
Interface:	C-spaces are represented by the CSpaceMBean interface in the com.bea.b2b.management.hub.runtime package. C-hub management applications use CSpaceMBean objects to monitor c-spaces.

 

Conversation Definitions and Roles

Description:	A conversation is a series of predefined message exchanges between trading partners that take place in a c-space in the context of a predefined business model. Each message in the conversation can cause any number of back-end transactions. A conversation definition is a set of roles pertaining to one conversation. A role is the subscription unit in a conversation. To participate in a conversation, a trading partner subscribes to a specific role that is defined in the conversation definition associated with the conversation. A role is defined by a sequence of documents that can be sent or received by a trading partner in the conversation. The role defines what a trading partner can do, such as buy or sell. Each conversation definition has two or more roles.
Relationships:	There is a one-to-many relationship between a c-hub and conversation definitions. A c-hub has multiple conversation definitions; but for every conversation definition, there is only one c-hub. A trading partner uses a subscription to relate a conversation definition to a c-space. There is a one-to-many relationship between a conversation definition and roles. A conversation definition has multiple roles; but for every role in the conversation, there is only one conversation definition.
Interface:	Conversation definitions are represented by the GlobalConversationMBean interface in the com.bea.b2b.management.hub.runtime package. C-hub management applications use GlobalConversationMBean objects to monitor global conversations.

 

Document Definitions

Description:	A document definition is a schema (such as a DTD) that defines a valid document.
Relationships:	There is a one-to-many relationship between a c-hub and document definitions. A c-hub has multiple document definitions; but for every document definition, there is only one c-hub. There is a many-to-many relationship between document definitions and message definitions. For example, a document definition can be used in many message definitions. And a message definition can be referenced by many document definitions.
Interface:	None.

 

Trading Partners and Trading Partner Protocols

Description:	A trading partner is a representation of an object, such as a company, that is authorized to participate in one or more c-spaces. A trading partner needs a separate authorization for each c-space that it participates in. A trading partner uses the c-enabler to subscribe to conversations that are communicated through a mediated messaging system on the c-hub. A trading partner protocol defines additional information that might be needed by the protocol that a trading partner uses. Trading partner protocols are required only for non-XOCP business protocols. For information about configuring non-XOCP business protocols, see Configuring Business Protocols.
Relationships:	To participate in conversations in a c-space, a trading partner must register as a collaborator on a c-hub. C-hub administrators define and manage collaborator registration. Before registering on a c-hub, a trading partner must first establish a business relationship with the e-market owner. There is a one-to-many relationship between a c-hub and trading partners. A c-hub has multiple trading partners; but for every trading partner, there is only one c-hub. There is a many-to-many relationship between trading partners and c-spaces, and between trading partners and conversation definitions. For example, multiple trading partners can join one c-space, and one trading partner can join multiple c-spaces on the c-hub. A trading partner needs a separate c-enabler for each c-space that the partner joins. Trading partners can participate in multiple conversations within a c-space. To participate in a conversation, the trading partner must subscribe to a role in a conversation definition. To participate in a non-XOCP conversation, a trading partner might need to define a trading partner protocol. There is a one-to-many relationship between a trading partner and trading partner protocols. There is a many-to-one relationship between trading partner protocols and a business protocol definition. For example, one trading partner can define several different trading partner protocols for participating in several different types of conversations. Each trading partner protocol must reference one business protocol definition, and each business protocol definition can be referenced by multiple trading partner protocols.
Interface:	Trading partners are represented by the CollaboratorMBean interface in the com.bea.b2b.management.hub.runtime package. C-hub management applications use CollaboratorMBean objects to monitor trading partners.

 

Logic Plug-Ins

Description:	A logic plug-in is a component that provides additional processing for information that passes through the c-hub. For information about logic plug-ins, see Developing Logic Plug-Ins in the BEA WebLogic Collaborate Developer Guide.
Relationships:	There is a one-to-many relationship between a c-hub and logic plug-ins. A c-hub can have many logic plug-ins; but for every logic plug-in, there is only one c-hub.
Interface:	None.

 

Business Protocols and Business Protocol Definitions

Description:	A business protocol specifies a URL and refers to a business protocol definition. Each c-space/business protocol combination has a unique URL. A trading partner uses this URL to access a particular c-space using a particular business protocol. A business protocol definition specifies how the c-hub processes business messages, including how to read the messages and how to route the messages to the recipients. A business protocol definition also specifies persistence, retries, and quality of service. For information about business protocols, see Configuring Business Protocols.
Relationships:	A c-space has a one-to-many relationship with business protocols, and a c-hub has a one-to-many relationship with business protocol definitions. Business protocol definitions have a many-to-one relationship with a business protocol. For example, a c-space can include many business protocols and a c-hub can include many business protocol definitions. Each business protocol can reference one business protocol definition. And each business protocol definition can be referenced by many business protocols.
Interface:	None.

 

Message Definitions

Description:	A message definition defines the business content (business documents and attachments) of a business message. A message definition consists of ordered message parts: XML-type message parts, which are business documents and require document definitions. Binary-type message parts, which are attachments and require no other information.
Relationships:	A c-hub has a one-to-many relationship with message definitions. Roles have a many-to-many relationship with message definitions. For example, a c-hub can include many message definitions. Each role includes messages that refer to message definitions. A message definition can be associated with roles in multiple conversation definitions.
Interface:	None.

 

 

---

Responsibilities and Tasks

The following responsibilities are associated with c-hubs:

• E-Market owners design c-spaces and negotiate with trading partners to participate.

• Flow designers design business processes, workflows, and rules; and define the associated conversations, roles, and documents.

• Business developers configure the elements in the repository.

• System administrators install, set up, and monitor c-hubs and c-spaces; and monitor log files at run time.

• Application developers develop applications that run in the WebLogic Collaborate system, including external management applications to monitor c-hubs at run time.

Working with a c-hub involves the following tasks:

• Installing the WebLogic Collaborate software according to the instructions in the BEA WebLogic Collaborate Installation Guide.

• Configuring a c-hub according to the instructions in Setting Up the C-Hub.

• Populating the repository with configuration information using the C-Hub Administration Console as described in Using the C-Hub Administration Console, which is Part II in this document. Populating the repository includes the following tasks:

  • Creating and configuring the c-hub

  • Creating and configuring one or more c-spaces

  • Adding trading partners and defining trading partner protocols

  • Adding business protocols and business protocol definitions

  • Adding document definitions, message definitions, and conversation definitions

  • Defining subscriptions

• Monitoring the c-hub at run time using one of the following:

  • The C-Hub Administration Console as described in Monitoring the C-Hub.

  • Management applications that retrieve c-hub run-time information by using the c-hub MBeans and MBean server. For more information, see the BEA WebLogic Collaborate Developer Guide.