This chapter provides a general overview of ebXML Protocol Manager and its place in the Java CAPS, including system descriptions, ebXML information, general operation, basic features, and how it operates with eXchange.
For more information about eGate and eXchange, see the corresponding user’s guides.
ebXML Protocol Manager works primarily with eGate and eXchange. You can use ebXML Protocol Manager to design eGate Projects to process and validate messages that employ the ebXML delivery protocol.
For more information on how eXchange operates with eGate, see the eXchange Integrator User’s Guide .
ebXML Protocol Manager is designed to work with the eXchange framework to expose all of its related Project components. This feature allows for you to expand and customize your Projects and provides end-to-end visibility of the business logic implemented by the current Project.
ebXML Protocol Manager has the following primary characteristics:
Uses a messaging service (also called business service ) that is, a sequence of events incorporating the rules set by the protocol specifications
Uses information in the message itself and in the eXchange Trading Partner profile to prepare messages according to ebXML standard
Works with eXchange common services to prepare and deliver messages, employing the following features:
Error handling
Message tracking
Trading partner profile database lookup
PKI security services, such as encryption and signature creation and verification
Electronic Data Interchange (EDI) has given companies the ability to eliminate paper documents, reduce costs, and improve efficiency by exchanging business information with Trading Partners in electronic form. However, in the last few years, the Extensible Markup Language (XML) has rapidly become a first choice for defining data interchange formats for new eBusiness applications on the Internet.
EDI implementations represent substantial investments in encoding B2B Protocols (B2B Protocols). Companies with a large stake in EDI integration do not want to abandon EDI, for obvious cost reasons.
XML does enable more open, flexible business transactions than EDI, and XML might also allow more flexible and innovative business models. But there are still challenges in standardizing the semantics of message design and creating uniform B2B Protocol requirements. These problems are independent of the syntax in which messages are encoded.
ebXML specifications provide a framework in which EDI’s investments in business processes (B2B Protocols in ebXML Protocol Manager) can be preserved in an architecture that also maintains and extends XML’s technical capabilities.
For more information on ebXML, including the Requirements Specifications, see the following Web site:
For more information on the Extensible Markup Language (XML), see the following Web site:
This model provides an example of the operations that may be required to configure and deploy ebXML applications and related components. These components can be implemented after initial system deployment, as needed.
Of course, there are more ebXML specifications than are shown in this simplified diagram. This model only provides a basic introduction to essential ebXML concepts. The numbers in the diagram call out steps in the process described under the next section.
The model operates as follows:
Company A has become aware of an ebXML registry accessible on the Internet.
Company A, after reviewing the contents of ebXML registry, decides to build and deploy its own ebXML-compliant application.
Custom software development is not a necessary prerequisite for ebXML participation. ebXML-compliant applications and components that provide necessary solutions are commercially available and easily found.
Company A then submits its own business profile information (including implementation details and reference links) to ebXML registry.
The business profile submitted to ebXML registry describes the company’s ebXML capabilities and constraints, as well as its supported business scenarios. These business scenarios are XML versions of the B2B Protocols and associated information bundles (for example, a sales tax calculation) in which the company is able to engage. After receiving verification that the format and usage of a business scenario is correct, ebXML registry sends an acknowledgment to Company A.
After additional communication is established, Company B accesses, in ebXML registry, the business scenarios supported by Company A.
If they decide they want to, Company B sends a request to Company A stating they want to engage in a business scenario using ebXML. Company B acquires the necessary ebXML-compliant applications in the same way as Company A.
Before starting the scenario, Company B submits a proposed business arrangement directly to Company A’s ebXML-compliant software interface. The proposed business arrangement outlines the mutually agreed-upon business scenarios and specific agreements.
The business arrangement also contains information pertaining to the messaging requirements for transactions to take place, contingency plans, and security-related requirements. Company A then accepts the business agreement.
Company A and B are now ready to engage in eBusiness transactions using ebXML.
As you can tell from this simple model, ebXML specifications provide the following advantages:
Standardized way of describing B2B Protocols and their associated information models
Registration and storing B2B Protocol and Information Meta Models so they can later be shared and reused
Discovery and sharing of information about each participant including:
Supported B2B Protocols
Business service interfaces offered in support of each B2B Protocol
Business messages exchanged between their respective business service interfaces
Technical configuration of any supported transport, security, and encoding protocols
Way to register the previously described information for later access and retrieval
Way to describe the execution of mutually agreed-upon business arrangements derived from information provided by each participant from the discovery of information; these arrangements are called Collaboration Protocol Agreements (CPAs)
Standardized business messaging service framework enabling interoperable, secure, and reliable exchanges of messages between Trading Partners
Reliable way for configuring the respective messaging services to engage in agreed-upon B2B Protocols, in accordance with constraints defined in any predefined business arrangement
To ensure consistent capitalization and naming conventions across all ebXML specifications, use the Upper Camel Case (UCC) and Lower Camel Case (LCC) capitalization styles.
These styles employ the following conventions:
UCC style capitalizes the first character of each word and compounds the name.
LCC style capitalizes the first character of each word except the first word.
When you are producing ebXML documents that follow DTD, XML Schema, and XML instance conventions, use the following rules:
Element names are in the UCC convention, for example:
<UpperCamelCaseElement/>
Attribute names are in the LCC convention, for example:
<UpperCamelCaseElement lowerCamelCaseAttribute="Item"/>
When you use UML and Object Constrained Language (OCL) to specify ebXML naming capitalization, observe the following rules:
For Class, Interface, Association, Package, State, Use Case, and Actor names, use the UCC convention, for example, ClassificationNode, Active, or InsertOrder.
For Attribute, Operation, Role, Stereotype, Instance, Event, and Action names, use the LCC convention, for example, name, notifySender, or orderArrived.
General rules for all names are:
Avoid acronyms, but in cases where you have to use them, keep the capitalization, for example, XMLSignature.
Do not use underscores ( _ ), periods ( . ), or dashes ( - ). For example, instead of using title.document, stock_sale_6, or dollar-value, use TitleDocument, stockSale6, and DollarValue.
eXchange Integrator provides an open Business Protocol framework to support standard EDI and B2B protocols, as well as packaging protocols. The eXchange product supports existing standard protocols, using an extensive set of prebuilt eInsight Business Processes (BPs). It also provides the tools and framework to create and adopt new protocols and to build custom BPs.
B2B modeling semantics are exposed so that eInsight Business Rules can be added and tailored to address the particular needs of providing eBusiness solutions. The tight integration with the rest of Java CAPS provides validation, logging, and reporting capabilities. Because each logical step within any Business Rule is accessible anywhere along the entire eInsight BP, the design tools provide complete end-to-end visibility.
For a complete explanation of eXchange and eInsight, as well as their operation, see the eXchange Integrator User’s Guide and eInsight Business Process Manager User’s Guide .
An eInsight BP is a collection of actions or operations that take place in your company, revolving around a specific business practice. These processes can involve a variety of participants and may include internal and external computer systems or employees.
In eXchange, you create a graphical representation of a business process called a BP model. When you are using the sample for a PM’s implementation scenario, the system uses the BPs necessary for scenario’s operation. The BPs specific to the sample scenario provided with the product have already been created for this scenario.
The architecture of eXchange centers around the concept of sending and receiving messages relative to one or more TPs. Each TP that you import or create and then configure corresponds to one of your business trading partners.
These TPs contain configurable transaction profiles for each individual TP relationship. You can configure TPs with Transaction Profiles and Schedules, within ePM, for use by run-time components.
Each Transaction Profile specifies which one or more BPs to use for the current transaction, where and how to receive inbound messages, how to configure and secure messages in their channels, and how and where to deliver outbound messages.
Using eXchange to create a business solution consists of the following phases:
Design phase within Enterprise Designer
Configuration/design phase within ePM
Run-time phase
ePM is a feature of eXchange you can use as a tool that allows you to configure eXchange for use with any of your PMs. You must set specific parameter values within ePM to ensure the correct operation of your Projects, for each protocol. This guide explains how to use and configure ePM, to set parameters relevant to this guide’s PM.
For more information on how to use ePM, see the eXchange Integrator User’s Guide.
eXchange is one of the products that make up the B2B Suite within the Java CAPS. The B2B Suite products, including eXchange, provide a Web-based TP configuration and management solution for automating and securely managing business partner relationships. The products also facilitate real-time interaction between the enterprise and its TPs, suppliers, and customers.
As a part of the Java CAPS, the B2B Suite provides the following benefits and features:
B2B services via eXchange
Protocol managing, specifically by the PMs
Protocol formats contained in the OTD Libraries
Trading partner management facility, that is, the ePM interface
Archiving tool, the Message Tracking feature
The B2B Suite is tightly integrated with the Java CAPS and runs as a group of components within the Java CAPS environment.