[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 firstname.lastname@example.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