General Webswell Connect 2 usage scenario
To get basic ideas behind usage of Webswell Connect 2 platform, have
a look at Figure 1. It describes elementary situation with 2
communicating parties involved in the data interchange. For
simplicity's sake we assume that there is Webswell Connect 2 installed on
both nodes (parties).
Figure 1 - elementary communication scheme
The business message lifecycle:
- Prior
any collaboration, both parties agree upon conditions of collaboration
defined in CPA (Collaboration-Protocol Agreement) document (for ebXML communication) or in a AS2 Partnership document (for AS2 communication)
- Business Application at Party A (ERP for example)
generates business data that needs to be delivered to other party
(an invoice, a purchase order etc.). Business content is coupled
with routing information saying where to send the data.
- Webswell Dispatcher reads data and forms ebXML or AS2 message, using settings
read from CPA or AS2 Partnership documents. The message is passed to the MessageServiceHandler
module for sending to other party.
- On Party B node, the MessageServiceHandler receives the message, validates it and passes it to Webswell Dispatcher.
- Webswell Dispatcher unwraps the business content and passed
it together with routing information to a Business Application (ERP)
for further processing.
Example of ebXML/AS2 eBusiness integration
The next example of Webswell Connect 2 usage illustrates a typical
real-life scenario where an enterprise (a headquarters with n
subsidiaries) communicate with its trading partners using various
methods, while there's another - internal integration within the
enterprise between the headquarters and the branches. Figure 2. shows
the high-level scheme of such scenario.
Figure 2 - integration scenario
Figure 3 shows block scheme of such solution. Apart from EbXML
communication there is EDI (AS2, or WebServices integration
) communication involved. To support different methods we need separate
module that wraps business content in needed form and provides needed
messaging functionality.
Figure 3 - complex integration solution
|
| Products downloads |
|
|
|
|
|
| Implemented standards |
| |
- ebXML Message Service Specification (ebMS) v2.0
The OASIS Standard that defines the message enveloping and header
document schema used to transfer ebXML messages over a communications
protocol such as HTTP or SMTP and the behavior of software sending and
receiving ebXML messages. The ebMS is defined as a set of layered
extensions to the base Simple Object Access Protocol (SOAP) and SOAP
with Attachments (SOAPAttach) specifications.
The standard specification can be found here.
- ebXML Collaborative Partner Profile Agreement (CPPA) v2
The OASIS Standard that defines Collaboration-Protocol Profile (CPP) of
business partners involved in the communication, Collaboration-Protocol
Agreement (CPA) document as a intersection of two partner's CPPs. CPP
and CPA contain detail of transport, messaging, security constraints,
and bindings to a Business Process Specification document that contains
the definition of the interactions between the two parties while
engaging in a specified electronic business collaboration.
The standard specification can be found here.
- ebXML Registry Services Specification (ebRS) v3.0 and ebXML Registry Information Model (RIM) v2.0
Standards that specify information model for the ebXML Registry and
define how to build registry services that provide information content
in the ebXML Registry.
The standards specifications can be found here.
|
| Technologies used |
| |
- Java Platform, Standard edition
- Java Servlet
- Jakarta Tomcat
- JAXR
- PostgreSQL database
- IzPack
|
| |
|
|
