Home > Articles

Using the Sun ONE Application Server 7 to Enable Collaborative B2B Transactions

This Sun BluePrints OnLine article describes a design for a comprehensive Web services application architecture that enables businesses to publish, find, and execute collaborative B2B workflows with trading partners. It describes how businesses should capture their offerings in a declarative Web services format and decouple them from the tightly bound code that exists in point-to-point solutions. This article is written for system architects and professional service engineers who have a solid understanding of Web services technologies, including WS-I Basic Profile and electronic business eXtended Markup Language (ebXML) specifications. This article is targeted to the introductory level of expertise.
Like this article? We recommend

Like this article? We recommend

B2B Requirements

Web services are driving collaborative business-to-business (B2B) uses of the Internet. Open, Extensible Markup Language (XML)-based standards that define business process flow, security, message reliability, data content, and trading partner agreements enable Web services to provide a common interoperable B2B architecture, eliminating the need for point-to-point solutions with trading partners. By migrating from private networks and point-to-point solutions, organizations can extend their enterprise services to partners while reducing development and management costs, enhancing business agility, and increasing functional capabilities. Just as HTML drove a common browser interface across the Internet, Web services technologies are driving B2B interoperability.

This Sun BluePrints™ OnLine article describes a design for a comprehensive Web services application architecture that enables businesses to publish, find, and execute collaborative B2B workflows with trading partners. It describes how businesses should capture their offerings and capabilities in a declarative Web services format and decouple them from the tightly bound code that exists in point-to-point solutions.

This article is written for system architects and professional service engineers who have a solid understanding of Web services technologies, including WS-I Basic Profile, electronic business eXtended Markup Language (ebXML) specifications, and the Java Web Services Developer Pack (WSDP) technologies. To successfully implement the recommendations presented in this article, you should have experience in these areas. Background information about Web services is available from the Sun Web site and at other URLs listed in "Related Resources" on page 37.

This article describes the problems and requirements of today's B2B solutions and describes how Web service specifications can help architects design interoperable solutions. In addition to describing requirements, Web service technologies, and architectures, this article details a prototype that implements these technologies.

The article contains the following sections:

  • "B2B Requirements" on page 2

  • "ebXML Concepts" on page 8

  • "Web Services Architecture Defined" on page 14

  • "Sample B2B Collaborative Prototype" on page 23

B2B Requirements

Interoperable B2B solutions have a unique set of requirements that cause enterprise developers or architects who are accustomed to being able to manage both end points of an interaction to change the way they think about system management. In a B2B scenario, the underlying language, architecture, platform, and even service name of a trading partner can change at any time. Thus, to build B2B solutions, two unique issues must be addressed: the agreement on the collaborative messaging standards, and a normalization of the various enterprise service names that exist across companies in a given industry.

This section addresses the service normalization problem by introducing an enterprise services facade, a common industry-based public interface, and an enterprise mapping layer. It also addresses the interoperability requirements through sections on message collaboration and certification and testing.

  • Common enterprise facade. Organizations use an array of architectures and applications to perform their enterprise business functions. Applications that are often used include those that use the Java™ 2 Platform, Enterprise Edition (J2EE™) technology, and enterprise resource planning (ERP), as well as other applications (both packaged and customized) that are each customized for a specific business requirement. Based on this variety, exposing these enterprise services and building collaborative systems with trading partners can be difficult. Web services can help by building a common abstraction or facade to the various types of back-end systems so that all enterprise services can look the same.

  • Industry-based normalized public interface. Just building a services facade is not enough. Because every business has a unique combination of applications and information services, each enterprise will have vastly different Web services facades. It is impractical and undesirable to create hard-coded interfaces between every back-end system in a trading community. Although proprietary methods, such as electronic data interchange (EDI), have taken this approach to link business systems, each is enabled on a point-to-point basis. To more efficiently build a collaborative B2B infrastructure for a given industry, a shared public interface needs to be defined. Many industry standards bodies, like STAR in the automotive industry, are working to create a common set of data and interfaces for their individual industries. The effort can be considered a normalization process to identify a set of common data structures and interfaces required for the trading environment. Once complete, these common public trading interface definitions can be used to build a common infrastructure that each organization can leverage.

  • Private mapping layer. Once an industry-based public interface is available and the back-end enterprise services are wrapped with a common facade, a mapping layer can be developed to connect the two. To adapt to a common public trading interface, the creation of a private mapping layer for each company is required. In combination with these industry specific standards bodies, Web services technologies can then be used to provide the public infrastructure that enables dynamic, collaborative, trading environments. This article addresses how to use Web services to create both an enterprise services facade and the common industry collaborative trading infrastructure.

  • Message collaboration. In addition to addressing the task of efficiently integrating private enterprise services across an industry in a collaborative B2B environment, many other difficulties must be overcome as application solutions are extended from the back-end corporate enterprise through the firewall to trading partners. Interoperability and agreement on security, reliable messaging, and trading partner agreement mechanisms are the most critical architectures requirements. Asynchronous messaging, error handling, and support for attachments are also key features of a B2B collaborative solutions. For trading partners to interoperate using Web services, a standard must be selected that addresses a well defined approach to each of these capabilities. This enables the development of the handshaking of interoperable end points using different underlying architectures.

  • Certification and interoperability testing. Finally, another unique requirement of building a common B2B architecture is certification of interoperability. Beyond finding a standard that satisfies all of the necessary requirements, certification and testing organizations must be available to certify that interpretations of the specifications are common and that the implementations are interoperable. The number of certified implementations of a given standard demonstrates adoption in the competitive marketplace for a specification. Architecture, requirements, standards knowledge, and certification availability were all key elements that went into the selection of Web services and the design of the architecture described in this article.

Web Services Standards Selection

Selecting the correct standard is a challenging and dynamic process. With over 60 specifications, and new ones arriving monthly, finding the correct specification that addresses the B2B collaborative environment can be daunting. Another important issue is choosing between competing specifications. The first step in this process is to eliminate unproven specifications, using industry standards whose implementations are certified as interoperable. This narrows the set primarily to two sets of specifications that meet the requirements: WS-I Basic Profile and ebXML. At the writing of this article, both sets of specifications were required to satisfy all of our architectural requirements and build the B2B collaborative solution. The strength of the WS-I Basic Profile specifications is in building the underlying packaging specification and exposing the enterprise services facade discussed in the requirements. ebXML's strengths are that it was created for the purpose of building B2B infrastructures, and it extends the capabilities of WS-I Basic Profile. ebXML provides the specifications for requirements such as reliable messaging, collaboration, and nonrepudiation.

One of the key decisions in selecting the final WS-I Basic Profile specifications was the number of available certified implementations. For example, ebXML reliable messaging had nearly three dozen certified implementations at the time of this article. No other specification had more than a single implementation available. Another observation in making the selection was that the ebXML and WS-I stacks have architectural differences, but are merging toward common standards. For example, once the Simple Object Access Protocol (SOAP) became the recognized standard around packaging, ebXML dropped its original packaging mechanism and adopted SOAP. It is expected the same approach will be taken once standards around reliable messaging and security are reached. A final criterium was based on the history and completeness of each specification. ebXML originated as a B2B technology and addresses more of the B2B requirements, like trading partner configurations, where the WS-I stack originated as a SOAP-based API and does not provide standards for many of the B2B requirements.

The following diagram describes the specification that was selected to satisfy the requirements of the B2B solution and how it was selected.

Figure 1FIGURE 1 Selecting a Specification to Satisfy B2B Requirements

Collaborative ebXML Prototype

To satisfy the requirements of a B2B Web services solution, the prototype presented in this article demonstrates how to discover and execute trading agreements using XML documents that are easy to create, modify, and support. In addition, it is infrastructure-neutral. The core technologies you use to create these XML documents can be from any technology or vendor, as long as they conform to the defined Web services standard protocols.

The prototype defines a standardized, interoperable framework that can be leveraged and reused as a collaborative B2B infrastructure in any given vertical industry. An application server is an essential component and building block of this architecture. Sun™ ONE Application Server 7 software and J2EE technologies are the foundation of this project. They provide the core capabilities such as managing message queues and flow that are required for a reliable messaging system.

The prototype is designed to support both public and private interfaces. The private interface is an enterprise facade or standardized API to the proprietary back-end systems. It is implemented using Web services (WS-I Basic Profile) standards. The public interface is a connection between trading partners, implemented using ebXML standards. Direct connections between trading partners are quickly discovered, negotiated, and deployed using ebXML.

The capabilities of this reusable infrastructure are primarily provided by the prototype's ebXML framework. It provides a standardized, cross-language, solution for complex B2B and application-to-application (A2A) environments. This framework can extend a corporate service oriented architecture (SOA) to B2B trading partners, providing a low-cost, open standards-based alternative to EDI. The framework also supports attachments through asynchronous messaging, and each end-point acts as both a sender and receiver.

ebXML enhances the reliability of basic Web services through the support of guaranteed, in-order delivery of messages, semantics to support security including nonrepudiation, error handling, and logging support. The ebXML framework implements specifications for messaging services, registry services, and business process collaboration. It is based on open standards, providing a practical way to execute businesses transactions between trading partners.

Sun ONE Application Server 7 and Web Services Technologies: ebXML and WS-I (Basic Profile)

The Sun ONE Application Server 7 provides a J2EE platform for deploying and monitoring large-scale Web applications and services that access disparate data and systems through JavaServer Pages™ (JSP™) technology, Java servlets, or Enterprise JavaBeans™ (EJB™) architecture. The Sun ONE Application Server 7 features an implementation of J2EE 1.3 and Java Web Services Developer Pack (WSDP) to provide standard implementations of Web services standards including web services description language (WSDL), SOAP, ebXML, and universal description, discovery, and integration (UDDI), and it is the foundation for the ebXML implementation described in this article.

The Sun ONE Application Server 7 is a comprehensive environment for WS-I BP and ebXML. ebXML defines standards by extending WSDL, SOAP, and UDDI standards to achieve e-business partner interoperability for document exchange. ebXML message service extends SOAP 1.1 with Attachments for use as the base messaging protocol to achieve reliability and other quality of service aspects:

  • Through Java Messaging Service (JMS) support within the Sun ONE Application Server 7 product, Web services can connect to information systems by a simple point-to-point messaging approach. Through the J2EE Connector Architecture, enterprise connectors can interface an EIS system either to Web applications or to Web services. Finally, the application server includes a high-performance HTTP server.

  • Components can be wrapped or adapted to the J2EE platform, providing a standard approach across both new and legacy code. Specifically, legacy components that do not expose a J2EE interface in compliance with the J2EE Connector Architecture can be wrapped or adapted to existing J2EE components.

  • The Sun ONE Application Server 7 supports Java API for XML Registries and Repositories (JAXR) clients to access an ebXML Registry through a third-party JAXR provider. The ebxmlrr-client is a package that provides an implementation of the JAXR API that is compatible with the OASIS ebXML Registry V2.x (version 2.0 and 2.1) standard. The ebxmlrr-client package also includes a registry browser application that can graphically browse any OASIS ebXML V2.x registry.

  • The Sun ONE Application Server 7 Web container provides a comprehensive framework for supporting ebXML and Web services. This framework has the following characteristics:

    • The Web container provides the infrastructure support for the ebXML message service handler (MSH).

    • There is support for the WS-I Basic Profile: XML Schema 1.0, SOAP 1.1, WSDL 1.1, and UDDI 2.0.

    • There is support for the corresponding Java technologies to the WS-I Basic Profile technologies, including: Java API for XML-based RPC (JAX-RPC) and SOAP with Attachments API for Java (SAAJ).

ebXML Components

The ebXML infrastructure is composed of several independent, but related, components. They can be used individually, or together. Specifications for the individual components are fashioned as stand-alone documents. The specifications are totally self-contained; nevertheless, design decisions within one document can and do impact the other documents.

  • The ebXML Messaging Service (ebMS) provides the message packaging, routing, and transport facilities for the ebXML infrastructure.

  • ebXML core components represent common data items that capture business concepts. This catalog of XML schemas can be assembled like building blocks, creating the intended message for a business process.

  • The ebXML Collaboration Partner Profile and Agreement (CPP and CPA) describe partner interactions for the e-business scenario in a complete manner.

  • The ebXML business process specification schema (BPSS) describes, in detail, how trading partners take on shared roles, relationships, and responsibilities to facilitate interaction with other trading partners.

  • An ebXML Registry enables the storing and sharing of information between parties to allow e-business collaboration. Sun ONE Application Server 7 supports client access to an ebXML Registry through an open-source, third-party provider.

The Sun ONE Application Server 7 implementation highlights a compelling capability of ebXML—using XML documents to declaratively program the environment.

The declarative development aspects of this Sun ONE Application Server B2B collaboration prototype mean that XML documents define new Web services applications, trading partner agreements, and business partner collaborations. Once the ebXML architecture is in place, all changes are made with XML documents.

The following sections provide an overview of ebXML concepts, a high-level description of the prototype architecture, and more detailed information about building the prototype, including code snippets.

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