[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Version 0.40 ebXML Requirements document
Greetings,
Attached please find version 4.0 of the requirements document. Please note
- some holes still exist, and additional proofing will be required before we
publically release.
Mark
Mark Crawford
Research Fellow
______
LMI Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177 Fax (703) 917-7518
mcrawfor@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"
electronic business XML (ebXML)
Requirements Specification
ebXML Requirements
Working Draft 18 February 2000
This version: 0.40 of 18 February 2000
Latest version:
Previous version: 0.30 of 02 February 2000
Team Leader: Mike Rawlins
Editor: Mark Crawford
Abstract*
This ebXML Requirements Document represents the work of the ebXML Requirements
Project Team. It defines ebXML and the ebXML effort, articulates requirements for
ebXML, and defines requirements that will be used by the various ebXML teams in
preparing their deliverables.
Status of this document
This is an ebXML Requirements Project Team Working Draft for review by members of
the ebXML work group and other interested parties in the general public.
It has been reviewed by the ebXML Requirements Project Team and the Requirements
Project Team has 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
Sections which the requirements team has 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 PURPOSE AND SCOPE
1.3.1 ebXML Requirements Document Purpose
1.3.2 ebXML Requirements Document Scope
1.4 REFERENCES AND RELATED EFFORTS
1.5 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 Compatibility with existing Tech & EB standards and practices
2.5.4 Extensibility
2.5.5 Migration from existing EDI and XML solutions
2.6 SECURITY
2.7 LEGAL
2.7.1 Digital Signatures
2.8 MANAGEMENT
3 EBXML TECHNICAL FRAMEWORK REQUIREMENTS
3.1 GENERAL REQUIREMENTS
3.1.1 General Task Group Requirements
3.2 REQUIREMENTS TASK GROUP
3.3 BUSINESS PROCESS TASK GROUP
3.4 TECHNICAL ARCHITECTURE TASK GROUP
3.5 CORE COMPONENTS TASK GROUP
3.6 TRANSPORT/ROUTING AND PACKAGING TASK GROUP
3.7 REGISTRY AND REPOSITORY TASK GROUP
3.8 TECHNICAL COORDINATION AND SUPPORT TASK GROUP
3.9 MARKETING, AWARENESS AND EDUCATION
4 EBXML ORGANIZATIONAL AND PROCEDURAL REQUIREMENTS
5 EBXML TASK GROUP DELIVERABLES
1 Introduction
Electronic Business XML (ebXML) is an International Initiative established by UN/CEFACT and 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
marketT
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 MarketT. To
create this single global electronic market, this single set of ebXML technical specifications:
? is based on 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 EDI
standards and developing XML business standards.
? will eventually be submitted to an appropriate internationally recognized standards body for
consideration as an international standard.
1.1.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 Purpose and Scope*
1.3.1 ebXML Requirements Document Purpose*
This document has two primary purposes. The first of these is to provide clearly articulated requirements
from representatives of international business and standards communities to assist the ebXML task group
members in developing their deliverables in a consistent manner. This document is also intended to convey
to interested parties the purpose, scope, and vision of ebXML.
1.3.2 ebXML Requirements Document Scope*
This ebXML requirements document 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 Terms of Reference (TOR) http://www.ebxml.org
UN/CEFACT Techniques and Methodologies Working Group Document ??
Customer Requirements for OO-EDI
Others?
1.5 General ebXML Principles
General ebXML principles to be followed in developing ebXML deliverables are to create technical
specifications that:
? are simple, easy and ubiquitous,
? provide a global cross-industry open/interoperable standard for business-to-business and business-
to-consumer trade,
? coalesce the structure and content components of divergent XML standards into a single useable
XML business standard,
? provide impetus so that common resources currently engaged in short-term solutions shall be
marshaled to reach a common long-term solution goal,
? support vertical and horizontal segments of industry and business participants,
? avoid 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,
? minimize cost of application-to-application exchanges,
? meet the needs of all nationalities that use it,
? provide multi-lingual support
? accommodate national trade requirements
[Ed. Note - perhaps nationalities and multi-lingual support]
? provide a migration path from accredited EDI and developing XML business standards, and
? apply 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 and business to consumer 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 seven core areas -
General Business, Electronic Business, Globalization, Accessibility, Usability/Interoperability, Security
and Legal, 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 -
? a single, consistent approach to using XML for electronic business processes in both the B2B and
B2C environments,
? support for both vertical and horizontal solutions regardless of the sophistication of the user,
? support for a range of implementations from basic, low cost appropriate for Small or Medium
Enterprise (SME) deployment, to comprehensive, complex implementations using all optional
features appropriate to large enterprises,
? a range of usage from using core features in ad hoc, informal exchanges at one end, to highly
formal, structured exchanges derived from UML models on the other end
? support for current business models and practices as well as new ones developed through UML
modeling.
? a superset business process meta model that supports individual business process models
? a general specification for developing XML based schematas,
? syntactically neutral core components that can be used regardless of the underlying syntax,
? XML syntax based core schematas 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 the EDI interchange headers.
- Clearly identify core, mandatory features, and optional features
- provide a mechanism for full specification of the document semantics.
? a single recognized international standards organization to oversee responsibilities identified in
items 1 and 2,
? an open development process with no barriers to entry,
? open, readily accessible technical specifications and standards, and
? a 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 schemata's. 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 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 or a trading partner specified format. The data entry shall result in an
XML encoded document representing the business information.
2.3 Globalization
Globalization is 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
should 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 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. If ebXML is to exist beyond its initial 18-month
timeframe, then ebXML should maintain responsibility for ebXML technical specifications in an ebXML
managed repository. However, if the decision is made that ebXML will not exist after the initial set of
deliverables, then ebXML must determine if the repository should transition to CEFACT, OASIS,
XML.ORG, BizTalk, or some other existing XML business standards repository
2.5 Usability/Interoperability
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.
? Common Business Process - Both entities involved in the exchange of data must be engaged in
executing the same transaction as part 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 independent definition 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
realize reliable secure sending and receiving of messages over the internet, support for syntax neutral
definition of the information that needs to be held in the supporting messaging policy repository, and
details the format and structure of the wrapper, header, and any other data within the message - to include
signatures and encryption.
2.5.3 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 standards like organizations. 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 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.
[Ed. Note - the above paragraph was lifted (with slight modification) from the core components draft scope
statement of 2/18/2000]
2.5.4 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.5 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 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. Further, it is beyond the 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. 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 recommendation 14 for signatures
? 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.7.1 Digital Signatures
? electronic transactions must provide for digital signatures at an appropriate level within the
transaction to meet requirements of both the sender and receiver.
2.8 Management
2.8.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.8.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 task groups. These requirements have been developed in close coordination
with those task groups 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 task groups 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 Requirements
General requirements, in conjunction with the business requirements stated in section two, are more
detailed requirements that apply across the various task groups. These include all requirements necessary to
achieve the technical architecture shown in figure 3-1.
Figure 3-1 ebXML Technical Framework
At a general requirements level, it is also important to define how each of the functional components of
figure 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 figure 3-1
graphically illustrate general technical requirements to be addressed by each of the ebXML task groups.
3.1.1 General Task Group Requirements
Deliverables for each of the task groups 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
? support the requirements of each task group as identified in the following subsections
Figure 3-2. ebXML compliance requirements
3.2 Requirements Task Group
The Requirements Task Group's initial task was to produce this ebXML requirements document. In
addition, the Requirements Task Group will:
? develop 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.
? review, evaluate, and assimilate follow-on requirements submitted by external organizations for
consideration by ebXML
? provide assistance as required to the Technical Coordination and Support Task Group on
requirements issues
3.3 Business Process Task Group
The Business Process Task Group detailed requirements and deliverables will -
? provide a high-level business process methodology in terms of XML, i.e., DTD.
? select a methodology with which to specify "vertical" business processes according to a uniform
"template" (i.e., ebXML "superset") to support comparison.
? explicitly specify the ebXML "superset" business process meta-model. In no instance shall this
meta-model be subject to implied specification using instantiations or derivations.
? incorporate cross-industry methodologies for specifying business processes, e.g., Open
Applications Group (OAG), RosettaNet, HL7, into the ebXML "superset."
? specify reusable objects.
? create a glossary of terms related to business process methodology: vocabulary, e.g., functional,
non-functional, vertical, message, segment, data type shall be created and maintained using TMWG
Unified Modeling Methodology document Annex 1 as a start.
? create a glossary of terms specific to each business process to be modeled.
? create a glossary of XML tags.
? work with the Registry and Repository Task Group to incorporate technical specifications, models,
and required glossaries into the ebXML repository.
3.4 Technical Architecture Task Group
The Technical Architecture Task Group detailed requirements and deliverables will -
-
? Provide for naming conventions for technical and business content in the technical architecture
3.5 Core Components Task Group
The Core Components Task Group detailed requirements and deliverables will -
? be syntax independent, i.e., not specifically aligned with any existing syntax based semantics such
as ANSI X12 or UN/EDIFACT.
? be defined to insure separation of common "fundamental" versus "extra" specific
? respect ISO 11179 rules
[Ed. Note - do we accept this requirement? What is the impact of limiting ebXML to ISO 11179 rules?]
? use semantics solutions that accommodate currently defined accredited EDI semantics where they
add value.
? use a single consistent set of terminology.
In achieving these deliverables, the Core Components Task Group will -
? liaison with the Business Process Team regarding development of business process models that
identify potential reusable components. The business process team should develop the models that
define and describe business semantics, but still point out those semantics with potential for
reusability across messages.
? liaison with the Technical Architecture Team regarding Description of the overall framework and
conventions for expressing core components in XML messages both in the business and technical
content. For business content, the technical architecture team should distinguish between common
and business-specific components, if such a distinction is needed. The overall architecture for data
exchange will need flexibility to meet the demands of Web customers, yet still need to support
known business application and integration requirements as systems and tools mature.
? liaison with the Transport, Packaging, and Routing Team regarding description of common items
used in message headers, security features, transport protocols, and error messages. While some
core components may appear in transport, packaging, and routing operations, these messages will
likely have specific syntax and invocation requirements that will require separate processing from
the normal message body.
? liaison with the Registry and repository team regarding specifications for submission and retrieval
of core components in repositories. The registry and repository team should describe the processes
and methods for the identification or registration of core components in repositories.
3.6 Transport/Routing and Packaging
The Transport/Routing and Packaging Task Group detailed requirements and deliverables will -
? Specify how to envelope business documents in regard to:
- Related messages in a collection
- Physical and/or logical addressing of destination for messages
? Specify exchange at the application level
? Specify wire format mapping
? provide for flexible transaction boundaries
? provide for reliable messaging and error handling
? identify messaging routing
? meet security requirements
? provide for audit trains
? 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 Task Group
The Registry and Repository Task Group detailed requirements and deliverables will -
? identify the long term maintainer of this repository
? develop detailed blueprints for an ebXML repository that
- uses open management processes
- has open access
- has interfaces with other existing and planned XML business standards repositories
- accommodates:
? Versioning
? Metadata Registry
? Model interchange (UML - XML schemas)
? tool to tool queries and exchanges
? repository 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 as a start
? 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
- 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 is 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.
- has repository performance levels that support real-time interaction with business applications
3.8 Technical Coordination and Support
The Technical Coordination and Support Task Group 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
? outreach requirements and recommendations
? a 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 -
? marketing and promotion of ebXML
? recruitment of expanded participation by relevant bodies, companies, organizations, and other
entities involved in EDI and XML development, standardization, and deployment
? awareness 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.
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 task groups to make
sound decisions in developing their requirements and deliverables. These organizational and procedural
processes must
? facilitate the efforts of the Requirements and Technical Coordination and Support Project Teams
? support each of the functional project teams to meet their requirements
In developing these organizational and procedural processes, they will
? follow 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
? support the requirements of each task group as identified in section 3.
These organizational and procedural processes must provide for
? an open and consensus driven ebXML management process
? an open, timely, and consensus driven ebXML products development process that
- is responsive to business needs
- has sufficient controls to prevent creation of equivalent components
? an 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:
? the requirements for short and long term ebXML relationships with CEFACT, W3C, ANSI, ISO
and other standards bodies
? the requirements for short and long term ebXML relationships with OASIS, BizTalk,
CommerceOne, RosettaNet, and other XML business standards bodies must be defined
? the appropriateness of moving ebXML technical specifications to recognized international
standards under the cognizance of an international standards body
? who will be 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
? Measures of success
5 ebXML Task Group 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 Task Group
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
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.
ebXML Requirements Specification Version 0.40 of 18 February 2000 9
ebXML Requirements Specification Version .htm
ebXML Requirements Specification Version .doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC