Using the Sun ONE Application Server 7 to Enable Collaborative B2B Transactions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 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.