This topic provides an introduction to implementing ebXML solutions with WebLogic Integration. It contains the following sections:
This topic focuses on information that is relevant to ebXML solutions only. Before you begin, be sure to read the Introduction to learn basic concepts for integrating trading partners using WebLogic Integration. In addition, for a hands-on walkthrough of building example ebXML solutions, see “Tutorial: Building ebXML Solutions” in Tutorials for Trading Partner Integration.
An ebXML solution is any WebLogic Integration solution that involves exchanging business messages with trading partners using the ebXML business protocol. This topic describes ebXML and how it is supported in WLI. It contains the following sections:
The ebXML business protocol is sponsored by UN/CEFACT and OASIS. The ebXML Web site (http://www.ebxml.org) describes ebXML as “a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. Using ebXML, companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes.”
WebLogic Integration supports the following ebXML specifications:
These specification defines the message envelope and header document schema used to transfer ebXML messages with a communication protocol such as HTTP. They provide a set of layered extensions to the base Simple Object Access Protocol (SOAP) and SOAP Messages with Attachments specifications. The ebXML Message Service provides security and reliability features that are not provided in the specifications for SOAP and SOAP Messages with Attachments. For more information, see ebXML specifications page on the ebXML web site.
Information about SOAP, including the following documents, can be found at the World Wide Web Consortium (W3C) Web site (http://www.w3c.org):
This topic describes supported and unsupported ebXML features in this release of WebLogic Integration.
WebLogic Integration supports the following ebXML 1.0 and ebXML 2.0 features:
For more information, see Trading Partner Integration Security.
|
|
For more information, see Reliable Messaging.
|
|
This release of WebLogic Integration does not support certain optional features of ebXML2.0, including:
This release does not provide XML DSIG at each payload level of an ebXML message.
This topic describes ebXML concepts that you need to understand before implementing ebXML business processes in WebLogic Integration. It contains the following sections:
The ebXML protocol layer provides the ability to send and receive messages via the Internet according to the ebXML Message Service specifications for transport, message packaging, and security. The ebXML 1.0 and 2.0 message service specifications are independent of the communication protocol used. WebLogic Integration supports the HTTP(S) communication protocol.
A business message is the basic unit of communication between trading partners. Business messages are exchanged as part of a conversation. The roles in a conversation are implemented by business processes, which choreograph the exchange of business messages.
The following figure represents the structure of a business message exchanged in a conversation based on the ebXML business protocol.
An ebXML business message contains one XML business document and one or more attachments. An ebXML message is a communication protocol-independent MIME/Multipart message envelope, referred to as a message package. All message packages are structured in compliance with the SOAP Messages with Attachments specification.
The message package shown in the preceding figure illustrates the following logical MIME parts:
MessageHeader
element that specifies details such as from and to business IDs, service that relates to the business process, and action that relates to a node in the business process. The SOAP Header is a generic mechanism for adding features to a SOAP message.WebLogic Integration provides a mechanism in Workshop business processes for retrieving the ebXML message envelope that relates to the Header container from incoming business messages. For more information, see @com.bea.wli.jpd.EbXML and @EBXMLControl.EbXML in the Java Docs for WebLogic Integration Classes.
An ebXML message can have any combination of payloads. The payloads can be all binary, all XML, or a mixture of both. Any payload is sent as a MIME attachment to the SOAP message—the SOAP body is not used to carry the payload.
WebLogic Integration provides a MessageAttachment[]
data type that business processes can use to retrieve payloads from an ebXML message, particularly when payloads consist of mixed data types or when the number of payloads or the order of payloads is not known in advance. It provides methods for determining the content of a payload (isXmlObject
and isRawData
) and retrieving the contents of the payload (getXmlObject
and getRawData
) as untyped XML data (XmlObject
data type) or non-XML data (RawData
data type). To learn about working with MessageAttachment
objects, see
Using Message Attachments.
The ebXML business protocol supports reliable messaging, an optional but important capability that allows you to configure different levels of quality of delivery service. Reliable messaging has a reliability versus performance trade-off, as increasing the level of guarantee increases run-time requirements on system resources. Configure reliable messaging in the WebLogic Integration Administration Console, as described in “Defining an ebXML 1.0 or 2.0 Binding” in Trading Partner Management in Using WebLogic Integration Administration Console Help.
Of the eight qualities of service policies defined in the ebXML 2.0 Specification, WebLogic Integration supports the following four (non-multihop) policies, which determine how acknowledgements and duplicate messages are handled:
This topic describes Workshop business processes that implement ebXML conversations. It contains the following sections:
When designing business processes for ebXML solutions, consider the following guidelines:
eb:Action
element in the message header of the ebXML message, which becomes important in cases where multiple message exchanges occur within the same conversation. You can use one of the following values in the ebxml-action-mode
business process property:default
—Sets the eb:Action
element to SendMessage
(default name) and onMessage
is the control callback method name.non-default
—Sets the eb:Action
element to the name of the method (on the ebXML control) that sends the message in the initiator business process. For sending a message from the initiator to the participant, this name must match the method name of the Client Request node in the corresponding participant business process. For sending a message from the participant to the initiator, the method name in the callback interface for the client callback node in the participant business process must match the method name (on the ebXML control) in the control callback interface in the initiator business process.
Using non-default
is recommended to ensure recovery and high availability. If unspecified, the ebxml-action-mode
element is set to non-default
.
setProperties
method (only applicable to the ebXML control using
@EBXMLControl.EbXML).Note: | To ensure proper routing, the ebXML service name specified in the initiator and participant business processes must match. In addition, for non-default action mode, the method names in the ebXML control instance in the initiator business process must match the method names in the corresponding participant business process. |
onAck
and onError
nodes.XMLObject
and provide explicit casting in the business process, as in the following example:127.0.0.1:7001
. The delivery-semantics is Once and Only Once. The ebxml service name can be anything as long as it is same for both the initiator and participant business processes. For more information, see Default TPM Repository Settings.In WebLogic Integration, initiator business process use an ebXML control to enable Workshop business processes to exchange business messages and data with trading partners via ebXML. You use ebXML controls only in initiator business processes to manage the exchange of ebXML business messages with participants. The ebXML control provides methods for sending business messages, acknowledgements, and errors, and it provides callback methods to handle responses from participants.
For detailed information about using the ebXML control in business processes, see the following topics:
For an introduction to initiator business processes, see Initiator and Participant Business Processes.
In WebLogic Integration, you can easily create a new ebXML participant business process using a Workshop template, the ebXML participant business process file. This template provides a head start for building public participant business processes for ebXML conversations. Although this file is not required to build ebXML participant business processes, it includes the nodes and business process annotations needed to integrate easily with ebXML initiator business processes, as well as standard choreography patterns such as acknowledgements, time-outs, retries, and errors. For information about using participant business processes, see Building ebXML Participant Business Processes and @com.bea.wli.jpd.EbXML in the Javadoc for WebLogic Integration Classes. For an introduction to participant business processes, see Initiator and Participant Business Processes.
This topic provides a high-level, end-to-end overview of the tasks involved with implementing an ebXML solution. It includes the following topics:
Note: | This topic describes, in a general way, the tasks that are typically involved in implementing an ebXML solution. The process of implementing ebXML solutions is iterative, and it can vary in scope and sequence depending on your unique business requirements and environment. |
Before you begin implementing an ebXML solution, we recommend that you review the following documents:
Once you have decided to use ebXML as the business protocol for your trading partner integration (as described in Phase 1: Plan the Solution), you need to plan the solution by determining certain factors in your implementation:
The Tutorials for Trading Partner Integration provide examples of different ebXML solutions. For more information, see Tutorial: Building ebXML Solutions.
After planning your ebXML solution, you build the business processes that implement the design patterns you are using. For more information about design-time tools, see Phase 2: Design, Build, and Test the Solution. For conceptual information about ebXML business processes, see ebXML Business Processes.
The Tutorial: Building ebXML Solutions in Tutorials for Trading Partner Integration (available at http://dev2dev.bea.com/code/wli.jsp) provides a detailed examples of the typical tasks required to build an ebXML solution.
To build an ebXML solution, you would typically complete the following steps:
serviceName
attribute (and others if needed) in the
@EBXMLControl.EbXMLebxmlServiceName
attribute (and others if needed) in the
@com.bea.wli.jpd.EbXML.Once you have built and tested your ebXML solution, you deploy the solution in a production environment. For more information about deployment tools, see Phase 3: Deploy the Solution. For detailed information about deploying WebLogic Integration solutions, see Deploying WebLogic Integration Solutions.
To deploy an ebXML solution, you would typically complete the following steps:
Note: | If you have already defined trading partner information in your development environment, you can export this information to an external file, and then import this file into the production environment. For more information, see Importing and Exporting Data in Trading Partner Management in Using WebLogic Integration Administration Console Help. |
Once you have deployed your ebXML solution, you would typically monitor run-time performance, message volumes, resource utilization, and other factors to ensure optimum operation on your solution. For more information about monitoring tools, see Phase 4: Administer and Tune the Solution.
For instructions on monitoring trading partner integration resources, see Viewing Statistics and Monitoring Messages in Trading Partner Management in Using WebLogic Integration Administration Console Help.