Home > Articles

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 4FIGURE 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.


The WSDL facade enables a variety of clients types to access the service, including non-Java technology clients.

Figure 5FIGURE 5 Architecture View, Next Level of Detail (Draft Version)


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.


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.


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.


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/.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020