B2B Testbed "" NIST
Approach ""
[skip navigation]

About the Testbed

Testbed Projects



Date created: 5/10/2003
Last updated: 6/2/2004

The testbed effort consists of a number of activities that take place concurrently:

Planning
INTEROPERABILITY DEMONSTRATION AND TESTING
Architecture Development


Interoperability Demonstration and Testing

Our two major focuses in the actual demonstration and testing activities were to show how a Web-based interoperability demonstration and testing infrastructure may satisfy needs of the customers and software vendors and how the business messages content testing may be performed to assure conformance to intended semantics.

As an illustration of the first focus area, the following is a description of an actual BPSS interoperability demonstration episode:

  • STAR/XML initiative uses BPSS specification to specify scenarios of collaborations. Software vendors are including support for BPSS in their products. Customers and vendors desire to assess the functionality and interoperability aspects of these BPSS implementations:
    • Users: did we define the collaboration properly?
    • Vendors: do our implementations work using real scenarios?
    • Both: is there interoperability among different instantiations of products using the standards?
  • Goal of the BPSS interoperability demonstration was to explore the following scenario:
    • Take a real business process, analyze and model it using a modeling tool, define the XML documents and BPSS schema required by the process, and execute the collaboration using products from different vendors.
    • Show that both ends of the applications can collaborate with each other.
    • We used sample deliverables from the STAR/XML consortium using Business Object Documents [BODs] conforming to OAGIS specifications and ebMS and BPSS as the B2B execution framework
  • The result of the interoperability demonstration is summarized here and illustrated in the figure below:
    • We were able to take Process Parts Order business process definition and define the business scenario using OAGIS BODs and ebXML BPSS to specify the characteristics of the collaboration.
      • The business process was modeled using Mega International's Modeling tool which also generated the specified BPSS schema.
    • The BPSS schema were loaded into execution engines from Fujitsu and Sybase to validate that the schema, as generated by a 3rd party modeling tool, is recognized by the B2B servers
    • The Parts Order binary-collaboration scenario was implemented using two BP engines -- using ebXML messaging with Guarantee delivering and Security for transport
    • We were able to demonstrate that each of the BP engines properly executes the intent of the BPSS schema, within the scenario.
    • We were able to demonstrate that the BP engines interoperate for the given scenario.

Resulting architecture for BPSS interoperability demonstration in collaboration with STAR/XML initiatived

As an illustration of the second focus area, the following is a description of an actual content checking capability in a specific context:

  • The US Air Force (USAF) is in the process of building an Enterprise Portal that would allow the vendors (i.e., suppliers to the Air Force) to establish a B2B interaction with this customer. The USAF with help from its integrator (i.e., Lockheed Martin) will publish business document formats (i.e., BOD schema) to be used by these vendors when communicating to the portal. It is desirable to assure that every individual vendor's use of the BOD schema is conformant to the intended usage. The question is how can USAF portal help the vendors make sure that their BOD usage is conformant.
  • Goal of the Collaborative Content Checking (CCC) demonstration for the USAF Portal scenario is focused on the following:
    • Allow the customer to select a real BOD schema or data type definition (DTD) that encodes the busines document format and semantics.
    • Allow the customer (i.e., USAF Portal administrator) to log on to a CCC site. Let the customer specify his testing profile by specifying the company, name, password to setup the customer area.
    • Allow the customer to create a new test entry for the selected schema or DTD. The test entry is created using a constraint specification language. The customer uploads the CCC test entry to the CCC repository.
    • Allow the vendor to select a customer profile. After logging on to the CCC site, the vendor selects the customer profile from a list.
    • Allow the vendor to select the test entry corresponding to the BOD that is used.
    • Alllow the vendor to post a BOD instance for testing. The vendor submits the BOD instance content using the CCC user interface. The CCC processes the business document with respect to the selected test entry and provides a conformance report.
  • The result of the interoperability demonstration is summarized here and illustrated in the figure below:
    • We were able to use the Schematron constraint specification language to generate content constraint statements in the form of an XSL/XPATH document conformaing to the Schematron specification
    • We were able to prototype a collaborative content checking Web-based application and protocol
    • We were able to demonstrate the capability using example BOD instances from the USAF Portal integrator and example constraint statements.

Example of Schematron rules used in the collaborative content checking demonstration for the USAF Portal effort


"Certain commercial equipment, instruments, or materials are identified in this paper to specify the experimental procedure adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the materials or equipment identified are necessarily the best available for the purpose."