electronic business XML (ebXML)
 Requirements Specification

ebXML Requirements Specification

Working Draft 328 February March 2000

This version: 0.650 of 18 March February 2000

 Latest version:

 Previous version: 0.450 of 18 March February 2000

Team Leader: Mike Rawlins

Editor:  Mark Crawford

 Abstract*

This ebXML Requirements Specification represents the work of the ebXML Requirements Project Team.  It defines ebXML and the ebXML effort, articulates business requirements for ebXML, and defines specific requirements that will be used addressed by the various ebXML project tteams in preparing their deliverables. 

Status of this document

This is an ebXML Requirements Project Team Working Draft for review by members of the ebXML wWork gGroup and other interested parties in the general public.

It has been reviewed approved by the ebXML Requirements Project Team and the Requirements Project Team has  for submission to the full ebXML Work Group for comment and approval.agreed

 to its publication. Note that not that all sections of the draft represent the current consensus of the team. Different sections of the specification may well command different levels of consensus in the project team. Public comments on this draft will be instrumental in the project team's deliberations.

Please review and send comments to: ebXML-Requirements@lists.oasis-open.org

 

            Mike Rawlins, Requirements Project Team Leader, rawlins@metronet.com

            Mark Crawford, Requirements Project Team Editor, mcrawfor@mail.lmi.org

Sections which the rRequirements Project Tteam has not yet reached consensus, are marked with an asterisk (*) at the end of the section title.

 

1                    Introduction

1.1           Documentation Conventions

1.2           The ebXML Vision, Purpose, and Scope

1.2.1       ebXML Vision

`               1.2.2       ebXML Scope

1.3           The ebXML Requirements Document Specification Purpose and Scope

1.3.1       ebXML Requirements DocumentSpecification Purpose

1.3.2       ebXML Requirements DocumentSpecification Scope

1.4           References and Related Efforts

1.5           General ebXML Guiding Principles

2                    Business Requirements

2.1           General Business Requirements

2.2           Conducting Electronic Business using ebXML

2.3           Globalization

2.3.1                 Multilingual

2.3.2                 Internationalization

                2.4           Accessibility

2.4.1       Registry and Repository

2.5           Usability/Interoperability

2.5.1       Architecture

2.5.2       Transport, Routing, & Packaging

2.5.3           2.5.3    Extensibility

2.5.4           Leveraging Existing Technology

2.5.4.1      Compatibility with existing Technology & EB standards and practices

2.5.4.2    Migration from existing EDI and XML solutions

                2.5.4                 Extensibility

2.5.5  Migration from existing EDI and XML solutions

2.6           Security

                2.7          

2.7  Legal

2.5 

2.7.1                                2.8           Digital Signatures

2.89           Management

                2.9.1 Organizational Structure

                2.9.2 Participation

3                    ebXML TECHNICAL FRAMEWORK Requirements         

3.1           General Requirements

3.1.1       General Project Team Requirements

3.2           Requirements Project Team

3.3           Business Process Project Team

3.4           Technical Architecture Project Team

3.5           Core Components Project Team

3.6           Transport/Routing and Packaging Project Team

 

3.7           Registry and Repository Project Team

3.8           Technical Coordination and Support Project Team

3.9           Marketing, Awareness and Education

4                    ebXMLebXML Organizational and Procedural Requirements

5                    ebXML Project Team Deliverables

1         Introduction

Electronic Business Extensible Markup Language XML (ebXML) is an International Iinitiative established by the United Nations Centre for the Facilitation of Procedures and Practices for Administration, Commerce and Transport (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS) with a mandate to undertake a 15-18 month program of work. The purpose of ebXML initiative is to research and identify the technical basis upon which the global implementation of XML can be standardized. The goal is to provide an open technical framework to enable XML to be utilized in a consistent and uniform manner for the exchange of Electronic Business (EB) data in application to application, application to human and human to application environments thus creating a single global market™. ™

1.1        Documentation Conventions

This ebXML Requirements Specification document was produced using Microsoft Word saved as MS-DOS text with line breaks. The following highlighting is used for non-normative commentary in this document:

 

              [Issue -]: A recorded issue.

 

              [Ed. Note -]: Notes from the editors to themselves or the Working Group.

 

              [NOTE -]: General comments directed to all readers.

1.2        ebXML Vision, Purpose, and Scope

1.2.1       ebXML Vision

The ebXML vision is to deliver:

 

"A single set of internationally agreed upon technical specifications that consist of common XML semantics and related document structures to facilitate global trade."

 

This single set of ebXML technical specifications will create a Single Global Electronic Market™. ™.  To To create this single global electronic market, this single set of ebXML technical specifications: -

 

¨         is fully compliant with W3C XML technical specifications holding a recommended status., 

¨         provides for interoperability within and between ebXML compliant trading partner applications,.

¨         maximizes interoperability and efficiency while providing a transition path from accredited electronic data interchange (EDI) standards and developing XML business standards,. and

¨         will be submitted to an appropriate internationally recognized standards body for accreditation as an international standard.

1.2.2       ebXML Scope*

The ebXML initiative is targeted at every sector of the business community, from international conglomerate to small and medium sized enterprises engaged in business-to-business and business-to-consumer trade. With that audience in mind, the ebXML initiative is committed to developing and delivering products that will be used by all trading partners interested in maximizing XML interoperability within and across trading partner communities. 

1.3        ebXML Requirements Document Specification Purpose and Scope

The ebXML Requirements Specification purpose and scope are defined in the following sub-sections.*

1.3.1       ebXML Requirements Document Specification Purpose*

This document requirements specification has two primary purposes.  The first of these is to provide clearly articulated requirements from representatives of international business and accredited standards organizations to assist the ebXML project team members in developing their deliverables in a consistent manner. This document specification is also intended to convey to interested parties the purpose, scope, and vision of ebXML.

1.3.2       ebXML Requirements Document Specification Scope*

This ebXML rRequirements document Specification applies to the work underway within the current ebXML project teams.  Each project team has provided input to this document to ensure consensus with its contents.  In addition to the Requirements Project Team, project teams currently chartered by the ebXML steering committee are:

¨         Business Process Methodology

¨         Technical Architecture

¨         Core Components

¨         Transport/Routing and Packaging

¨         Registry and Repository

¨         Technical Coordination and Support

¨         Marketing, Awareness and Education

1.4        References and Related Efforts

ebXML Invitation - http://www.ebXML.org/documents/199909/ebXML_invitation.htm

 

ebXML Terms of Reference (TOR) - http://www.ebXML.org/documents/199909/terms_of_reference.htm

http://www.ebxml.org

 

Recommendations for ebXML Kickoff Meeting - UN/CEFACT/TMWG/N104 -

    http://www.ebxml.org/documents/contributions/tm104.pdf

 

United Nations Layout Key for Trade Documents, Recommendation No. 1, second edition, adopted by the Working Party on Facilitation of International Trade Procedures, Geneva, March 1981 Source: ECE/TRADE/137

 

Authentication of Trade Documents by Means Other Than Signature, Recommendation No. 14, second edition, adopted by the Working Party on Facilitation of International Trade Procedures, Geneva, March 1979 Source: TRADEWP.4/INF.63

 

 

Information technology -- Specification and standardization of data elements, International Organization for Standardization (ISO)/ International Electrotechnical Commission (IEC) [ISO 11179]

 

SIMAC Future Vision Statement - UN/CEFACT Ad Hoc Working Group on Simple-EDI and Forms and Web Based EDI (SIMAC) - http://www.unece.org/trade/untdid/download/99cp12.pdf

 

 

1.1.1        Related Efforts:

Customer Requirements  for the Next Generation of EDI Standards - CEFACT/TMWG/N027

          http://www.harbinger.com/resource/klaus/tmwg/TM027.PDF

CEN/ISSS XML/edi Initiative http://cen.isss.org

 

1.5        General ebXML Principles

General ebXML principles to be followed in developing ebXML deliverables are to create technical specifications that:

¨         Eenable simple, easy and ubiquitous use of XML for electronic business,

¨         Prprovide a global cross-industry open/interoperable standard for business-to-business and business-to-consumer trade,

¨         Ccoalesce the structure and content components of divergent XML standards into a single useable XML business standard,

¨         Pprovide impetus so that common resources currently engaged in short-term solutions shall be marshaled to reach a common long-term solution goal,

¨         Ssupport vertical and horizontal segments of industry and business participants,

¨         Aavoid imposing financial or software requirements constraints on ebXML users to buy, install or programmatically support any ebXML unique software products in the conduct of business information exchange,

¨         Mminimize cost of application-to-application exchanges,

¨         Mmeet the needs of all nationalities that use it,

¨         Pprovide multi-lingual support

¨         Aaccommodate national and international trade requirements

 

 

¨         Pprovide a migration path from accredited EDI and developing XML business standards, and

¨         Aapply when possible the simplification principles of SIMAC (document TRADE/CEFACT/1999/CRP.12

2         Business Requirements

This section describes the business requirements for business to be conducted electronically over a network.  The requirements are oriented toward using XML for electronic business, but most of the requirements are applicable to implementation with other technologies.

 

The scope of ebXML business requirements is generally to meet the needs for the business side of both business to business (B2B) and business to consumer (B2C) activities.  Consumer requirements of the B2C model are beyond the scope of the ebXML technical specifications.

 

[NOTE - for ease of reading, the term business is to be interpreted as interchangeable with for-profit, non-profit, not-for profit, and government entities.]

 

The business requirements to be addressed by the ebXML initiative are divided into nineseven core areas - General Business, Electronic Business, Globalization, Accessibility, Usability/Interoperability, Security,  and Legal, Digital Signature, and Organizational.  Each of these requirements is identified in the following sub-sections.

2.1        General Business Requirements

Business has a real need to use new technology with minimized investment to gain competitive advantage.  The advent of the Internet and World Wide Web has proven to offer such benefits.  However, these benefits are in need of functionally neutral standard method of moving data. Specifically, business needs a solution that provides: -

¨         aA single, consistent approach to using XML for electronic business processes in both the B2B and B2C environments,

¨         Ssupport for both vertical (e.g. industry, functional, organizational) and horizontal (e.g. cross-industry, multi-functional, organizationally neutral) solutions regardless of the sophistication of the user,

¨         Ssupport for a range of implementations from basic, low cost solutions appropriate for Small or Medium Enterprise (SME) deployment, to comprehensive, complex implementations using all optional features appropriate to large enterprises,

¨         Aa range of usage from using core features in ad hoc, informal exchanges at one end, to highly formal, structured exchanges derived from Unified Modeling Language (UML) models on the other end,

¨         Ssupport for current business models and practices as well as new ones developed through business process modeling,

¨         Aa superset business process meta model that supports individually developed business process models,

¨         Aa general specification for developing XML based schemata's,

¨         Ssyntactically neutral core components,

¨         XML syntax based core schemata's and tags to support individual trading partner business processes that -

-          eliminate duplication of effort

-          provide support for XML metadata, such as the ebXML version/release and information corresponding to existing EDI standards interchange headers

-          clearly identify core, mandatory features, and optional features

-          provide a mechanism for full specification of semantic meaning

¨         Aa single recognized international standards organization to oversee continued ebXML work responsibilities identified in items 1 and 2,

¨         Aan open development process with no barriers to entry,

¨         Oopen, readily accessible technical specifications and standards, and

¨         Aa solution that minimizes costs for development, maintenance, and use.

[NOTE - Business looks to XML as a means of gaining competitive advantage through leveraging new technology.  Minimizing the cost of doing business electronically is a key element in achieving a competitive advantage.  The cost of doing business electronically can be grouped into acquisition, development, deployment and customization, integration with business applications, and operations and support.  It is expected that using XML for electronic business will be less costly than traditional forms of EDI and other existing electronic commerce technologies in each of these areas.  This expected cost reduction is a driving force for considering XML over traditional EDI technologies.]

2.2        Conducting Electronic Business using ebXML

Business applications must be able to exchange structured business documents (encoded in XML) with a corresponding application of another enterprise to support a business process.  This exchange may either be completely without human intervention, as is the case with traditional EDI, or with some level of human intervention to correct missing or erroneous data.   Business applications may also need to exchange structured business documents with intermediaries such as portals and brokers. To accomplish these requirements, it is critical to have syntax neutral core components that define classes within objects, a modeling methodology and meta-model to ensure interoperability between different groups of trading partners, and information exchange mechanisms that provide for plug and play, shrink wrapped, syntactically neutral solutions.  Additionally, business applications must also:

¨         Be able to generate XML encoded business documents that may be displayed using a specific presentation format,; such as the appropriate U.N. Layout Key for Trade Documents or a trading partner specified format..

¨         Enable data entry of business documents using a specified presentation format,; such as the appropriate U.N. Layout Key for Trade Documents or a trading partner specified format. The data entry shall result in an XML encoded document representing the business information.

2.3        Globalization

Globalized solutions are critical in today's ever expanding marketplace.  The underlying purpose of ebXML is to facilitate international trade.  To achieve "a single global market" that such facilitation implies, it is critical to simplify existing exchange standards methodologies and harmonize divergent approaches.  This simplification and harmonization can be achieved through developing a business meta-model in conjunction with syntax neutral core components.  Both of these deliverables should accommodate divergent national and multi-national process requirements, and should support forward and backward compatibility with the developing ebXML technical framework. 

 

To simplify development efforts, all work shall use English. To support globalization, all ebXML technical specifications will be translatable into the other official UN languages- French and Russian. Translation into other languages will be the responsibility of the intended user, although such translations should be supported in the ebXML repository.  Regardless of language, and in keeping with the requirements of XML 1.0, all work will be compliant with Unicode and ISO/IEC 10646 for characters, Internet RFC 1766 for language identification tags, ISO 639 for language name codes, and ISO 3166 for country name codes.

2.4        Accessibility

Openness is a critical aspect of ebXML.  Business requires the ability to easily access ebXML technical specifications without regard to "membership", or payment of access and/or use fees.  This accessibility must be completely open to all potential users so as to eliminate the barriers for entry.  This accessibility, or openness, requires several key components to ensure viability.  Chief among these is an open, easily accessible registry and repository for the ebXML technical specifications.

2.4.1       Registry and Repository

A registry is required to allow process owners to submit or update their mapping templates.  This registry should have two interfaces - one for applications (Application Program Interface [API]) and one for humans (manual HyperText Transfer Protocol [HTTP]).  This registry should support an agreed upon security protocol.

 

A repository is required for storage, retrieval, and registration of various items that support performing business electronically.   There are two distinct sets of business requirements on the repository: a set dealing with managing the workflow of developing standard components that are stored in the repository, and a set dealing with application usage of the repository.

 

There are also short and long term registry and repository management issues. If ebXML is to exist beyond its initial 18-month timeframe, then ebXML should maintain responsibility for ebXML technical specifications in an ebXML supported repository.  However, if the decision is made that ebXML will not exist after the initial set of deliverables, then ebXML must determine if repository oversight responsibilities should transition to CEFACT, OASIS, XML.ORG, BizTalk, or some other existing XML business standards organization.

2.5        Usability/Interoperability

Usability and interoperability of the ebXML technical framework are critical business requirements.  Components of usability and interoperability are architecture; transport, routing, and packaging; extensibility; and leveraging existing technology.  Each of these is addressed in the following sub-sections.

2.5.1       Architecture

This is a primary requirement of the ebXML initiative. To maximize interoperability, the following requirements must be met.  As with other non-functional requirements, some aspects of achieving interoperability may conflict with other non-functional requirements.    Where a requirement is not met, software can usually be developed to provide a bridge.  However, such bridges may increase costs of development, implementation, or both, and conflict with cost minimization.  In other cases, achieving interoperability enhances other requirements.  For example, maximizing interoperability helps to achieve platform independence.   The ebXML architecture will support

¨         Common Business Processes - Both entities involved in the exchange of data must be engaged in executing the same transaction in the context of a business process.

¨         Common Semantics – Common meaning, as distinct from words, expression, or presentation.

¨         Common Language - Common vocabulary, with a one to one correspondence between words and meaning.  Also, a common spoken language

¨         Common Character Encoding

[NOTE - UNICODE, which is specified in the XML specification, provides this.]

¨         Common Expression - Common set of XML element names, attributes and common usage of those attributes, common approach to document structure.

¨         Common Security Implementations

¨         Common Data Transfer Protocol

¨         Common Network Layer

2.5.2       Transport, Routing, & Packaging

Any exchange of business information requires fully described transport, routing, and packaging methodologies. These descriptions should be based on a program language definition independent of the service interface required for systems to control the messaging system for the purpose of sending and receiving messages.  These descriptions should identify the behavior of the messaging system required to::

 

¨         Rrealize reliable secure sending and receiving of messages over the internet

¨         Ssupport syntax neutral definition of the information that needs to be held in the supporting messaging policy repository, and

¨         Ddetail the format and structure of the wrapper, header, and any other data within the message - to include signatures and encryption.

2.5.3       Extensibility

Businesses seek solutions that provide for a certain level of customization beyond core standards.  This extensibility is necessary to ensure internally unique business process requirements can be addressed beyond the scope of standards used for information exchanges between businesses.  EbXML must ensure extensibility is facilitated.

2.5.4       Leveraging Existing Technology

Leveraging existing technology encompasses both the ability to inter-operate with existing technology as well as the ability to migrate to the new technology.  Each of these is discussed in the following sub-sections.

2.5.4.1       Compatibility with existing Technology and EB standards and practices (W3C, RosettaNet, accredited EDI standards, etc.)

Businesses already have in place extensive EDI architectures and business solutions based on accredited EDI standards.  Additionally, many businesses are implementing XML solutions that are based on the technical specifications issued by the World Wide Web Consortium (W3C) and the XML based business standards of various competing XML groups—such as RosettaNet, CommerceOne, BizTalk, XML.ORG.  Although the ebXML solution will facilitate a single global market, and although its technical framework will provide a single set of technical specifications, businesses will still require the ability to inter-operate their existing EDI and XML solutions with solutions built on the ebXML framework..   

 

As part of compatibility, businesses require a technical framework that reuses common elements regardless of syntax.  To ensure a syntax neutral solution, ebXML must identify and define those items considered common across XML business data exchanges. Common items are  semantic units at any level that stay consistent across contexts, and  therefore are reusable both within and between business exchange messages.  Business process models will help define common items and provide their context. This context will in turn define the precise use of common items in messages exchanged among parties. ebXML should  describe these items in  terms independent of implementation syntax, and thus should apply equally  to XML (or SGML) documents, as well as EDI transactions. EbXML should adopt -- or if needed, develop -- a methodology to  consistently build or derive core components, including methods to encourage reuse and provide for extensions. ebXML should identify element names that can apply  across business processes and contexts, yet still allow for translation  into leading spoken languages. ebXML work will generate the content of core  components independent of implementation syntax, but with references to  data structures in XML messages and EDI transactions. ebXML will identify attributes that describe the context of the components also in terms independent of syntax.

 

 

 

2.5.4.2       Migration from existing EDI and XML solutions

Businesses seek maximum interoperability between their applications and trading partner applications.  This can be achieved by a single way of doing business electronically, i.e., a single standard for using XML for electronic business.  However, many businesses also have a considerable investment in existing standards based EDI and emerging XML business approaches.  These businesses require a mechanism and migration path for accommodating legacy EDI solutions based on accredited standards and XML solutions already in progress or implemented. Although migration from existing EDI and XML solutions is a key element of ebXML, the ebXML solution will ensure maximizing interoperability takes precedence in developing the ebXML technical specifications. 

 

[NOTE -Note: It is beyond the current scope of the ebXML initiative to develop specific migration and transformation methods.]

2.6        Security

Aspects of security may be required at both a session layer (i.e., for the duration of a network session in which data is exchanged) or be applied to a single, stand-alone document instance. In addition, application of security to a particular exchange or document instance must be determined by the business needs, and allow unrestricted and unsecured interchanges as the default.  All, some, or no security features may be required in any particular exchange of business information.  Additionally, the following requirements must be addressed -:

¨         Confidentiality - Only sender and receiver can interpret document contents

¨         Authentication of sender - Assurance of the sender's identity.

¨         Authentication of receiver - Assurance of the receiver's identity.

¨         Integrity - Assurance that the message contents have not been altered.

¨         Non-repudiation of Origin - The sender can not deny having sent the message.

¨         Non-repudiation of Receipt - The receiver can not deny having received the message.

¨         Archiving - It must be possible to reconstruct the semantic intent of a document several years after the creation of the document. 

[NOTE - This time period is subject to the archiving and record retention requirements of particular situations.  In general, businesses might require archiving and retrieval of up to 30 years after document creation.]

2.7        Legal

In many respects, legal requirements are duplicative of security requirements.  Beyond the security requirements identified in section 2.6, the following additional legal requirements exist -:

¨         Comply with the requirements of UN/CEFACT recommendation 14 - Authentication of Trade Documents by Means Other Than Signature

¨         Provide versioning support to facilitate reconstructing the semantic meaning of transactions in accordance with the underlying transaction format used.

¨         Ensure metadata solutions do not result in legal issues.

¨         ensure all transmitted data is well defined by a minimal set of metadata.

¨         ensure a mechanism provides for identifying completeness of a transaction.

2.8        Digital Signatures

Digital signatures, or electronic signatures, have security and legal implications that directly impact on electronic business requirements. As more and more government bodies define digital signatures, and enact legislation that adopts such techniques as having the same force of law as traditional signatures, new technology solutions must accommodate these business requirements.  The following definition is taken from California Civil Code (adding s. 1633) (1999 CA SB 1124) -

 

 

add lead in"Digital signature," for the purposes of this section, means an electronic identifier, created by a computer, that is intended by the party using it to have the same force and effect as the use of a manual signature. The use of a digital signature shall have the same force or effect as a manual signature if it embodies all of the following attributes:

 

(1) It is unique to the person using it.

 

(2) It is capable of verification.

 

(3) It is under the sole control of the person using it.

 

(4) It is linked to data in a manner that if the data is changed, the digital signature is invalidated."

 

The ebXML technical framework must support electronic transactions mustthat provide for digital signatures at an appropriate level within the transaction to meet requirements of both the sender and receiver in keeping with the forgoing definition and attributes.

2.9        Management

If ebXML is to be successful in both the short and long term, and if the ebXML technical framework is to be adopted by the international business community, then management issues associated with both organizational structure and participation must be addressed.  The following sub-sections identify the business requirements for each of these areas.

2.9.1       Organizational Structure

The ebXML initiative is an eighteen-month effort to develop a technical framework.  To ensure efficiency of operation and success in achieving the ebXML vision, sufficient organizational controls must be put in-place as quickly as possible.  Further, there exists the possibility that ebXML will become more than a short term initiative.  As such, long term requirements for managing ebXML must be defined and addressed in the near term to ensure a smooth transition from short to long term management.  Further, if such a long-term organization becomes reality, processes must be adopted for recasting ebXML as an internationally accredited standards body.

2.9.2       Participation

The ebXML initiative relies heavily on technical expert participation.  This participation must be free of organizational requirements that restrict or otherwise inhibit participation of anyone.  Further, participation should be limited to the individual and not at the organizational level.  This will ensure each technical expert is given an equal footing in the organization, management, and work effort of ebXML. 

 

3         ebXML Technical Framework Requirements

This section identifies specific requirements for achieving the ebXML technical framework through the work of each of the ebXML project teams.  These requirements have been developed in close coordination with those project teams to ensure consensus on their content.  These high level requirements are closely aligned with the business requirements in section two of this document and are consistent with the vision, purpose, scope and guiding principles contained in section one. These high level requirements are carefully designed to provide a road map for the respective project teams as they drill down to more detailed requirements in preparation for developing their ebXML deliverables. As each of these deliverables becomes a reality, they will contribute to the developing ebXML technical specifications as part of building the ebXML end state.

3.1        General General Requirements

The following gGeneral requirements, in conjunction with the business requirements stated in section two, are more detailed requirements that apply to each project team. These include all requirements necessary to achieve the technical architecture shown in fFigure 3-1.

 

Figure 3-1 ebXML Technical Architecture

 

 

At a general requirements level, it is also important to define how each of the functional components of fFigure 3-1 will interact to form the basis for determining ebXML compliance for both implementations and transactional exchanges. Figure 3-2 illustrates this requirement, and in conjunction with fFigure 3-1 graphically illustrate general technical requirements to be addressed by each of the ebXML project teams.

3.1.1       General Project Team  Requirements

Deliverables for each of the project teams must -:

¨         be developed in compliance with the purpose, scope, and guiding principles identified in Section 1, 

¨         meet the business needs articulated in section two,

¨         facilitate the general requirements in section 3.1,

¨         clearly identify core, mandatory features, and optional features, and

¨         support the requirements of each project team as identified in the following sub-sections.

 

Figure 3-2. ebXML compliance requirements

 

 

 

3.2        Requirements

The Requirements Project Team's initial task was to produce this ebXML requirements document.  In addition, the Requirements Project Team will:

¨         dDevelop follow-on requirements documents in support of the ebXML Executive Committee and ebXML Steering Committee that meet the requirements contained in section 4 of this document. 

¨         Rreview, evaluate, and assimilate follow-on requirements submitted by external organizations for consideration by ebXML

¨         Pprovide assistance as required to the Technical Coordination and Support Project Team on ebXML requirements issues

3.3        Business Process

The Business Process Project Team detailed requirements and deliverables will: -

 

¨         Pprovide a high-level business process methodology in terms of XML, e.g., DTD.

¨         Sselect a methodology with which to specify "vertical" business processes according to a uniform "template" (i.e., ebXML "superset") to support comparison.

¨         Eexplicitly specify the ebXML "superset" business process meta-model. In no instance shall this meta-model be subject to implied specification using instantiations or derivations.

¨         Iincorporate cross-industry methodologies for specifying business processes, e.g., Open Applications Group (OAG), RosettaNet, Health Level Seven (HL7), into the ebXML "superset."

¨         Sspecify reusable objects.

¨         Ccreate  a glossary of terms related to business process methodology: vocabulary,— e.g., such as functional, non-functional, vertical, message, segment, data type— shall be created and maintained using UN/CEFACT TMWG Unified Modeling Methodology document Annex 1 as a start.

¨         Ccreate a glossary of terms specific to each business process to be modeled.

¨         Ccreate a glossary of XML tags.

¨         Ssupport language neutral mechanisms for associating business vocabularies to repository semantic definitions.

¨         work Be developed in conjunction with the Registry and Repository Project Team to incorporate technical specifications, models, and required glossaries into the ebXML repository.

3.4        Technical Architecture Project Team

The Technical Architecture Project Team detailed requirements and deliverables will: -

-

¨         Provide a view for integration of business processes among ad-hoc or established independent business partners by electronic means

¨         Reduce the need for collaborative business partners to have individual and expensive prior agreement on how to integrate business processes

¨         Provide a high-level business-centric view of distributed e-business processes

¨         Support and represent business processes independent of the technical solution

¨         Provide and support a library of common, standard intra-business processes

¨         Allow for both business processes and enabling technologies to evolve independently while retaining long-term investments in both

¨         Integrate with new and legacy systems throughout the enterprise

¨         Leverage existing technologies and standards

¨         PProvide for naming conventions for technical and business content in the technical architecture

 

3.5        Core Components

The Core Components Project Team detailed requirements and deliverables will: -

¨         Identify a methodology for describing core components

¨         Define core component content and structure

¨         Support reuse and extensibility

¨         Sample and recommend for XML and EDI instantiation

The Core Components Project Team may determine the need to develop core components.  If that decision is made, then those core components will:

¨         bBe syntax independentt,

[NOTE - Core components will not be specifically aligned with any existing syntax based semantics such as ANSI X12 or UN/EDIFACT]

¨         Bbe defined to insure separation of common "fundamental" versus "extra" specific

¨         Iincorporate where appropriate ISO/IEC 11179 rules

¨          

¨          

¨          

¨         Uuse semantics solutions that accommodate currently defined accredited EDI semantics where they add value.,

¨         Uuse a single consistent set of terminology.

¨         Contain attributes that specify context

¨         

3.6        Transport/Routing and Packaging

The Transport/Routing and Packaging Project Team detailed requirements and deliverables will :-

¨         Specify how to envelope business documents in regard to: -

-          rRelated messages in a collection, and

-          pPhysical and/or logical addressing of destination for messages.

¨         Specify exchange at the application level

¨         Ssupport common mapping techniques

¨         Provide for flexible transaction boundaries

¨         Provide for reliable messaging and error handling

¨         Identify messaging routing

¨         Meet security requirements

¨         Provide for audit trails

¨         Define and meet acceptable levels of quality of service

¨         Support platform independent interoperability

¨         Support restart and recovery

[NOTE - Some applications could make use of the caller (client) being able to own and demarcate traditional transaction boundaries, either across trading partner ("servers") or across a single trading partner ("server").  However, other applications (such as in the Travel industry) require a model that facilitates a "verify and <action>" model that does not require the client to explicitly own any transaction demarcations.]

 

3.7        Registry and Repository

 

The Registry and Repository Project Team detailed requirements and deliverables will -:

¨         Identify the long termlong-term maintainer of this repository.

¨         Develop detailed blueprints for an ebxmlXML repository that

-          uses open management processes,

-          has open access,

-          has interfaces with other existing and planned XML business standards repositories,

-          accommodates -:

§         vVersioning

§         mMetadata Registry

§         mModel interchange (e.g. UML - XML schemas)

§         ttool- to- tool queries and exchanges

§         rrepository to repository queries and exchanges

§         tool to repository queries and exchanges

§         repository to tool queries and exchanges

-        enables model integration (e.g., how to create an XML schema from a UML diagram and vice-versa without loss or gain),

-          supports Web access,

-          includes -

§         a glossary of terms related to business process methodology: vocabulary (e.g., functional, non-functional, vertical, message, segment, data type  using TMWG Unified Modeling Methodology document Annex 1)

§         a glossary of terms specific to each business process to be modeled

§         a glossary of ebXML semantic tags

§         archives of previous ebXML technical specifications.

§         archives of previous ebXML technical specifications

-          develops open XML based structures for storing information within a repository,

-          supports legacy information, including historical EDI directories (X12, UN/EDIFACT, etc.),

-          stores a legacy data model (e.g., IDEF-1X) and retrieves it back out as a UML class diagram,

-          stores 100% of a UML model (OCL, use cases, state diagrams, interaction diagrams, etc.) and retrieves it back out in its entirety,.

-          enables businesses to interactively map internal application semantics to horizontal and vertical industry semantics (semantic equivalent mappings),.

-          identifies data context with respect to where it is being used in the business process,.

-          supports change or enhancement to an as a result of implementation issues,.

-          supports exact and fuzzy search capabilities,.

-          supports electronic work item proposals in any format,.

-          identifies all the vertical domains for each artifact (UML classes, XML declarations),.

-          differentiates work in progress to that which is an actual standard,.

-          supports existing software and standards that are already in place. (reuse-buy-build principle),

-          ensures changes in repository content are restricted to authorized individuals,.

-          ensures access is restricted as necessary,

-          provides predictable naming conventions based on a formal scheme,.

-          provides predictable version identifiers based on a formal scheme,.

-          provides dynamic mapping tools that automatically retrieve the most current file specification from a repository,.

-        supports real time file specification retrieval to understand how to correctly parse a file and write out a conformant file,.

-        identifies which trading partners are capable of engaging into a given electronic business transaction,.

-        identifies which trading partners provide certain products and services,.

-        identifies what networking schemes must be used to physically communicate with a trading partner,.

-          facilitates discovery by intelligent information agents,.

-          supports Internet 24x7 access, and.

-          has repository performance levels that support real-time interaction with business applications.

3.8        Technical Coordination and Support

The Technical Coordination and Support Project Team detailed requirements and deliverables will
address:  -

¨         Project Team output consistency

¨         Research both internal and external XML concepts and technologies in support of executive committee and project team requirements

¨         Ooutreach requirements and recommendations

¨         Aa clear definition of ebXML compliance

3.9        Marketing, Awareness and Education

The real success for ebXML will be in its adoption by the business community.  To help facilitate that adoption, the Marketing, Awareness and Education Project Team must ensure the business community is aware of :

 

¨         The contents of this requirements document

¨         The efforts of the various ebXML project teams

To achieve this awareness, the Marketing, Awareness and Education Project Team will develop requirements and deliverables that address -:

¨         Mmarketing and promotion of ebXML

¨         Rrecruitment of expanded participation by relevant bodies, companies, organizations, and other entities involved in EDI and XML development, standardization, and deployment, and

¨         Aawareness and education of ebXML technical specifications

4         ebXML Organizational and Procedural Requirements

The ebXML Work Group organization is best defined by figure 4-1.  This figure shows a schematic of interactions and how the process derives technical specifications.

 

Figure 4-1. ebXML Organization and Work Flow

 

 

 

 

This figure also provides the basis for developing organizational and procedural requirements.  The ebXML executive committee must put in place organizational and procedural processes as soon as possible.  These organizational and procedural processes are critical to enable the various ebXML project teams to make sound decisions in developing their requirements and deliverables.  These organizational and procedural processes must:

 

¨         Ffacilitate the efforts of the Requirements and Technical Coordination and Support Project Teams

¨         Ssupport each of the functional project teams to meet their requirements

 

In developing these organizational and procedural processes, they will

¨         ffollow the purpose, scope, and guiding principles identified in Section 1, 

¨         meet the business needs articulated in section two,

¨         facilitate the general requirements in section 3.1, and

¨         support the requirements of each project team as identified in section 3.

These organizational and procedural processes must provide for

 

¨         Aan open and consensus driven ebXML management process

¨         Aan open, timely, and consensus driven ebXML products development process that

-           is responsive to business needs

-          has sufficient controls to prevent creation of equivalent components

¨         Aan open, timely, and consensus driven ebXML technical specifications approval process that is responsive to business needs.

Additionally, the Executive and Steering Committees, in conjunction with the full ebXML Work Group must determine:

 

¨         tThe requirements for short and long term ebXML relationships with CEFACT, W3C, ANSI, ISO and other standards bodies

¨         Tthe requirements for short and long term ebXML relationships with OASIS, BizTalk, CommerceOne, RosettaNet, and other XML business standards bodies  must be defined

¨         Tthe appropriateness of moving ebXML technical specifications to recognized international standards under the cognizance of an international standards body

¨         who will beT the single body that is responsible for long term maintenance of the ebXML technical specifications, repository, and supporting mechanisms -  OASIS, UN/CEFACT, or ebXML.

¨         the process for long term maintenance of the ebXML technical specifications

¨         ebXML funding methodology

¨         the need for and definition of mMeasures of success

5         ebXML Project Team Deliverables

This section identifies the nature of ebXML Work Group deliverables to guide each work group in developing those deliverables.  These high level deliverables descriptions are intended to facilitate the efforts of the Technical Coordination and Support Project Team in ensuring consistency in the output of the various functional project teams.  These high-level deliverables descriptions are identified in figure 5-1.

 

Figure 5-1. ebXML Project Team

 

FOCUS AREA	WHAT IT DOES	HOW IT’S USED
Project Team Business Requirement   What is the contribution of your group to ebXML?	Picture Model of Your Project Team Deliverables	Business Method - How your deliverables will be used

 

 

To assist in visualizing the above figure 5-2 is a conceptual model of overall ebXML stack interactions

 

Figure 5-2. ebXML Stack Interactions

 

 

Business Applications and Delivery Systems (external to ebXML)

Business Process Methodology

Core Components

Registry and Repository

Transport/Routing and Packaging

Technical Architecture

Technology Base (external to ebXML)

 

Executive Committee

Steering Committee

Technical Coordination and Support

Requirements

Work Flow

Administration / Marketing

 

To ensure consistency across all deliverables, each project team will use the format of this requirements document to prepare all deliverables.  Further, each project team will submit, for Steering Committee approval, a list of all proposed deliverables.  That list, once approved by the Steering Committee, will be included as part of this requirements specification.