Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Web Services Architecture Defined
This section presents a comprehensive architecture for using ebXML and its related technologies to create B2B collaborative Web services. We begin with a high-level diagram describing the core engines necessary to execute a B2B collaboration followed by a more detailed look at each tier and the B2B standards being leveraged. Descriptions of each of the individual components and subsystems are expanded, followed by some general architectural concepts that apply to a B2B collaboration.
FIGURE 4 illustrates the logical view of the basic ebXML implementation, and illustrates the relationship between ebXML services and Web services.
Servlets in the Web tier are extended to handle XML documents, with the ability to interpret and parse XML business documents.
A collaboration tier, or business process layer, enables interactions between trading partners.
The CPA and BPSS XML documents are used to declaratively drive the functional flow of the MSH and process server engines.
A service-oriented fa_de provides a common interface for all back-end services. Whether processes are based on EJBs, C++, legacy, or others, they will look and act the same—Web services.
A choreography tier enables enterprise workflows based on the orchestration of back-end enterprise services.
)
FIGURE 4 ebXML Architectural
Overview.
FIGURE 5 takes a closer look at the architecture, identifying the open standards used with each layer. Yellow represents XML standards, while other colors represent Java technology standards. The flow through the tiers is summarized as follows:
An ebXML formatted message is sent from a trading partner to the MSH engine (deployed in the Sun ONE Application Server 7 as a set of servlets and EJB components.)
The MSH retrieves the message, passing back to the trading partner the required acknowledgments and persisting the message.
The MSH then passes the message on to the business process engine using JMS.
The process engine retrieves the message, checks the conversation ID, and refers to the BPSS instructions for what to do next.
Assuming an enterprise service request is required, the process engine sends a message to the application server queue.
A message driven bean (MDB) wakes up and processes the request. It uses the request data to format a SOAP call to the Enterprise Services Facade that was deployed as a WSDL service by the Sun ONE Application Server 7.
The WSDL service then uses JAX-RPC to convert the request into an EJB call to service request, and relay the results back to the originating trading partner.
NOTE
The WSDL facade enables a variety of clients types to access the service, including non-Java technology clients.
)
FIGURE 5
Architecture View, Next Level of Detail (Draft Version)
Overview
The Sun ONE Application Server 7 provides a J2EE infrastructure layer over the operating system. This includes a web server, an EJB container, a servlet engine, Web services, an Object Request Broker (ORB), J2EE Connectors, Java Message Service, and a transaction manager. Web services on the Sun ONE Application Server 7 are supported primarily through the implementation of different JAX* APIs. The Sun ONE Application Server provides a facility to publish Web services into an ebXML Registry and to discover the registered services. In addition, the Sun ONE Application Server enables the integration of reliable messaging into Web services using Sun ONE Message Queue 3.0.1.
The ebXML layer, which connects trading partners, is built on top of the Sun ONE Application Server 7 software infrastructure. Messaging is handled by the MSH engine, which executes based on the ebMS specification, and connects to the process server engine through the JMS interface provided by the Sun ONE Application Server 7. Collaboration is handled by the process server engine, which executes based on the BPSS specification, and by private processing configurations, which connect the process server to the back-end enterprise services. This layer also supports monitoring, error handling, logging, the ebXML Registry, and core components.
The Sun ONE J2EE infrastructure, along with the ebXML layer, make up the collaborative B2B infrastructure that can be reused to support the build out of various customized applications. Therefore, using the same underlying infrastructure, new applications can be built or changed simply by creating and loading XML documents that store the underlying compute instructions for a particular engine. A customization or application layer built on top on the ebXML infrastructure layer is composed of:
The XML-based CPA document, which is mapped to and instructs the MSH engine on how to operate.
The XML-based BPSS document is mapped to and instructs the business process manager (BPM) engine on how the execute the collaborative conversation with the trading partners.
The ebXML Registry schema provides layout and management of the services.
Core component documents the definitions that define the data schema being passed in each message. These data schemas might be UBL that is ebXML core component-compliant, but they might also take the form of OAGIS BODs, XML schema, or basic DTDs documents.
XML instance documents provide the dynamic data that flows in each message transfer while abiding by the schema definition being used.
Thus, the above set of XML documents defines the application data and process flow that executes on top of the ebXML layer and the Sun ONE Application Server.
Architectural Concepts
There are several concepts and techniques used to integrate ebXML technologies into a working prototype. This section discusses some of the underlying technology and methodology used in creating this ebXML prototype.
Synchronous and Asynchronous Messaging
Synchronous messaging means that every time a client accesses a Web services application, the client waits for a SOAP response. Both asynchronous and synchronous messaging support request-response operation, although synchronous services are designed to block and wait for the response before continuing. Web services that require serial processing (can not continue until the reply results are returned) should use synchronous communications. WS-I Basic Profile is based on synchronous communications designed to simulate remote procedure call (RPC).
Web services that are concerned with scalability and performance and can process requests in parallel should use asynchronous communications. Asynchronous messaging means that a client that invokes a Web service does not block the thread and wait on response operations, rather the client can continue doing other things and will be interrupted when the response is available. If a real-time response is required, asynchronous messaging can correlate messages and provide a request-response pattern. ebXML specifications support both asynchronous and synchronous processing, but recommend the use of asynchronous processing. Java API for XML Messaging (JAXM) predominantly uses an asynchronous model for communication. It uses the SOAP with Attachments API for Java (SAAJ) to read and write SOAP messages.
ebXML relies on asynchronous messaging, loosely coupled distributed communication. A component sends a message to a destination, and the recipient can retrieve or receive the message from the destination. However, the sender and receiver do not have to be available at the same time in order to communicate. In fact, the sender does not need to know anything about the receiver; nor does the receiver need to know anything about the sender. The sender and the receiver need to know only what the message format is and what destination to use. The Java Message Service is an integral component of an asynchronous messaging capability.
Note that messaging differs from synchronous (tightly coupled) technologies, such as remote method invocation (RMI), which expects a response and requires an application to know a remote application's methods. In Web services, SOAP and WSDL work together to expose a service as a SOAP call - another form of synchronous messaging.
Design and Development Time
At design and development time, a partner would typically perform the following tasks:
Design and model business processes, encoding them in a BPSS document.
Code technical requirements into a CPA document.
Publish these documents in ebXML Registry.
The company would then implement a business service interface (BSI) that integrates the ebXML MSH with back-end fulfillment systems. This BSI represents the combination of the process engine and the integration of the enterprise services. It could use many different techniques to integrate with back-end or legacy systems, such as Java Message Service, connectors, adapters, Web services invocations, and so on. The BSI implementation could also make use of emerging choreography standards, such as BPEL, BPML or WSCI, to orchestrate the back-end services used to fulfill ebXML transactions coming in through MSH. If the back-end services are already exposed as Web services, this integration will be facilitated more easily.
A potential trading partner would find BPSS and CPP documents in the ebXML Registry for a company with which they wish to do B2B trading. At that point, a negotiation process would settle typical business issues such as contracts, agreements, partner validation, and suitability. It would also produce a CPA document as an additional artifact to document the agreement on technical capabilities (for example, which transport protocol will be used, endpoint addresses and URLs, the level of security, whether nonrepudiation is required, and so on). You can expect that the negotiation process will be a face-to-face process (not automated) for quite some time, and that it will likely fall under the auspices of the purchasing or procurement department's mandate.
Once the negotiations are completed, both partners should use the CPA to configure their respective MSH implementations.
Runtime
At runtime, depending on which business process was implemented, one of the partner's back-end applications will initiate a transaction and pass this transaction request through to the BSI implementation. BSI uses MSH to establish and conduct a business collaboration or conversation with the other trading partner's MSH and BSI. As the collaboration proceeds, BSI, at both ends, also manages the state of the process/workflow/state independently for each partner. The ebXML Registry is not required at runtime unless the business transaction needs to dynamically refer to persistent content that is stored in the registry. If access to persistent content is required at runtime, the ebXML Registry serves as a loosely coupled database that is shared between partners and accessible through the Web.
Collaboration and Choreography
Transactions between trading partners can be characterized as a series of questions and answers, using an agreed-upon language and dictionary. Top-level XML documents operating in an ebXML framework provide a straightforward way to add trading partners or establish new business relationships. Many of the semantics and procedures are declared at the outset of the transaction. ebXML uses the concept of choreography to describe the flow of messages exchanged by trading partners.
Collaboration enables developers and architects to describe and compose a global view of the message exchange's dynamic, another important part of creating a meaningful collaboration. WSCI and Business Process Execution Language (BPEL) are standard XML syntaxes for service choreography or BPEL.
BPSS is the ebXML XML-based expression of a collaborative messages exchange among business partners. The viewpoint of BPSS is always on the exchange between the parties.
The object-oriented nature of this architecture means that new services can be created from existing ones. Services, and the modular components that comprise them, can be rearranged to create capabilities with relatively little effort.
Declarative Development
The declarative nature of this architecture is represented in the flexibility of execution within the MSH and business process engines. The MSH represents a customizable execution engine. CPPs, and CPAs XML documents can be thought of as scripts that program the engine to behave in a certain manner. For example, the CPA defines timeout parameters, handshake protocols, and other transaction-related behavior. While each trading profile (B2B relationship) will have unique properties, the underlying engine that powers it, the MSH, remains the same. The behavior of the process engine operates in a similar manner. Its execution is defined by the BPSS document, which defines how the two trading partners collaborate.
The declarative nature of this architecture provides tremendous productivity gains through the reuse and customization of the core engine. Rather than writing custom code at each endpoint to handle each trading partner interaction, declarative development means the a new script can change the way the engine executes between each set of trading partners.
Architectural Components
The Sun ONE Application Server B2B collaboration prototype consists of many different components. These include off-the-shelf products, open source products, and industry standard components such as the business object documents (BODs), UBLs, and core components. The remainder, such as collaboration details, trading partner agreements and enterprise mappings, are defined specifically for each implementation.
This section provides the details of each of the main components used in the Sun ONE Application Server B2B collaboration prototype.
NOTE
A future enhancement to the infrastructure is to include the Sun ONE integration server to act as the choreography engine, aggregating and controlling the flow of enterprise services in the private infrastructure.
OAGIS BODs
To ensure standard definitions between trading partners within an industry, UBL or BODs (which can be thought of as schemas) from organizations such as STAR, Covisint, ChemDEX, or other sanctioned organizations should be used. These standards bodies help ensure that terms such as "purchase order" and "warranty" are well understood throughout a particular industry. The STAR BODs along with DTD were used in this prototype.
Sun ONE Application Server 7
The foundation of this project is the Sun ONE Application Server 7, which manages message queues and flow. It includes a fast HTTP server and a high performance message queue. The Sun ONE Application Server 7 provides a complete Web services infrastructure including support for SAAJ, Java API for XML Parsing (JAXP), JAXR, JAX-RPC, SOAP, and WSDL.
The Sun ONE Application Server 7 provides Web server and servlet engine services in an integrated framework. This integrated design places the servlet engine close to the EJB components that it will interact with—useful in this case, because objects are frequently passed back and forth. In addition to potential performance gains, using the Sun ONE Application Server 7 offers high availability, with session failover provided by the session replication of a clustered environment.
The Sun ONE Application Server 7 also provides the MSH capabilities. It consists of a set of J2EE components that run within the application container. The MSH component manages communication between trading partners. MSH provides a mechanism to configure communications through an XML document, CPA. It defines the agreement on security, message reliability, transports protocol, as well as the BPSS definition.
The application server for the prototype system also provides the following services:
Support for J2EE 1.3 specification standards
Security (encryption, authentication, Secure Sockets Layer [SSL])
Session management (through stateful and stateless session beans)
Logging
Communications (such as HTTP tunneling)
Encapsulation and hosting of EJB components through standard container services
Zero-administration client
Message Service Handler (MSH)
The Sybase implementation of MSH comes as part of the Web Services Integrator (WSI) product. The version used for the collaborative B2B prototype is 2.5. MSH is part of an application server's Web container.
WSI 2.5 is compliant with version 2 of the MSH specification. It is implemented as a servlet, and is hosted by the servlet container application server. Business logic is implemented in a set of EJB components. WSI enhances MSH implementation to support security (including digital certificates), nonrepudiation, and integration with the BPSS execution environment, and provides a client interface for efficient interaction with the WSI environment.
MSH servlet. Implements MSH 2.0 specification, including reliable messaging.
MSH component. Implements MSH-related business validations, including interfacing for CPA management, digital certificates, and nonrepudiation.
Security component. Interfaces with certificate key store to support digital certificates.
Nonrepudiation. Implements desired level of nonrepudiation.
BPIO component. Interfaces between MSH environment and the process server that is executing the collaboration.
ebXML client interface. Provides a mechanism to interact with ebXML infrastructure for programmable exits and input to collaborations at runtime.
Process Integration Server
The process integration server manages the mapping of business transactions to back-end services. It is also responsible for transitioning through the workflow defined in BPSS and managing the timeouts, errors, and logs.
BPSS—Business Collaboration
The BPSS document defines the business process to be executed by the process engine. A multithreaded C++ engine, the process server manages processes between disparate environments. In the ebXML context, the process server interacts with WSI over JMS and Java Message Queue technology.
The process server executes BPSS choreography in the ebXML context using the BPSTranslator tool, which utilizes BPSS and XML schema definitions and private processing definitions to create an event model that can be executed. It also creates events for validating input and output document structures, along with managing the state between multiple transitions.
Database Server
A database is required to store participant, marketplace profile, and other system information. For the Sun ONE Application Server B2B collaboration prototype, a Sybase relational database management system (RDBMS) was used.
Registry and Repository
The architecture is designed such that the ebXML Registry manages documents associated with trading partners. The ebXML Registry does not participate during the runtime transaction. It is only involved during run-time identification of trading partners and management of the associated document. The implementation fully implements the approved OASIS ebXML Registry specification. It was developed using Java, J2EE technology, and JAX pack standards including JAXB, JAXR, and SAAJ. The implementation is cross platform, deployed to a servlet-based Web container as a web archive (WAR) file. For this prototype, the Apache Tomcat Web container included with the JAX pack is used as the WAR container. It communicates with standard Java database connectivity (JDBC) to the back-end database server, currently a Cloudscape database.
The ebXML Registry can be exposed as a Web service if a more granular approach is required. Both key services provided by the registry, the life cycle manager and query manager, can be used as Web services.
The implementation of the specification being used for this Sun ONE Application Server B2B collaboration prototype is the open source implementation OASIS ebXML Registry Reference Implementation Project available at http://ebxmlrr.sourceforge.net/.