Previous PageTable Of ContentsNext Page

4.0  EMERGING INDUSTRY FRAMEWORKS/REPOSITORIES


It is astonishing to think about the number of new software technologies that have emerged in recent years. With each new technology, we have to separate marketing hype from reality and understand where and how these new technologies can be applied to, our enterprise needs. This section covers some of the key emerging integration framework initiatives and their underlying enabling technologies.

 

Figure 4.0-1  Integrated Framework Standards


It is important to note that the standardization activities covered in this section address such areas as Frameworks, Repositories, Content Definition, Application Integration, etc. as illustrated in Figure 4.0-2.

 

Figure 4.0-2  XML/EDI Standardization Activities


The purpose of the above diagram is to illustrate that separate specs and standards are being developed for each of the boxes shown above. Note that some standardization activities are attempting to address all of the above areas, while other activities are just focusing on particular areas. The key framework (or related) initiatives covered in this section are as follows:


4.1  RosettaNet
"Founded in June 1998, RosettaNet is an independent, self-funded, non-profit consortium dedicated to the development and deployment of standard electronic commerce interfaces to align the processes between IT supply chain partners on a global basis. RosettaNet's global initiative is to adopt and deploy open and common business interfaces, enabling small and large buyers and sellers of computer technology to do electronic business more efficiently."

"More than 200 companies representing $1 trillion in annual information technology and electronic components revenues currently participate in RosettaNet's standards development, strategy and implementation activities." More information on RosettaNet can be found on the World Wide Web at http://www.rosettanet.org."


4.1.1  RosettaNet Organization
RosettaNet's structure includes CEO, VicePresident of Operations, Project Coordinator, Chief Architect, Project Facilitator, Project Leader, Project Management Team, RosettaNet Managing Board, Architect Partners (Coalition Partners, Supply Chain Partners, and Solution Partners), Project Team Architects, and Business Research Team. Of these members we will focus on the Architect Partners and the RosettaNet Managing Board which will be defined in the following paragraphs.

The CEO is a Dedicated role responsible for overall execution of the RosettaNet Initiative according to the direction, budget, and priorities set by the RosettaNet Managing Board. Currently Jennifer Hamilton is chief executive officer of RosettaNet. Ms. Hamilton is an executive on loan from Quantum Corporation.

The RosettaNet Managing Board consists of twenty-eight members representing the IT community. The Managing Board is the governing body for the initiative providing its overall direction and strategy. It is responsible for Initiative funding, project prioritization, interface promotion and implementation, and interface design approval. Managing Board members designate part-time volunteers from their companies for at least three projects a year which staff RosettaNet project teams and are responsible for the creation of the Partner Interface Processes (PIPs) and dictionaries. EC Managing Board Members include: AMD, Cisco Systems, Hitachi Semiconductor, IBM, INTEL, Kemet, Lucent Technologies, Micron, Motorola, National, NEC Corporation, Philips Semiconductor, Pioneer, Texas Instruments, Toshiba America Electronic Components.

Architect Partners are the participating Initiative companies responsible for providing Project Team Architects and serve as initiative champions, as well as providing interface design approval. These include Coalition, Supply Chain, and Solution Partners.

Coalition Partners provide a support base for the PIP implementation. To qualify as a Coalition Partner, your organization must be a trade association or government agency that is not for profit. The goal of the Coalition Partner membership is to enlarge the support base and constituency of RosettaNet. Coalition Partners include: AFDEC, ASC X12, CommerceNet, CompTIA, CTC, EIDX, ITAA, NEDA, NEMI, NIST, OAG, OBI, SIIA, and Uniform Code Council to name a few.

Supply Chain Partners provide subject matter expertise for the interface development project teams. To qualify as a Supply Chain Partner, your organization must fall in the Electronic Component or Information Technology supply chain and your organization must be a manufacturer, distributor, reseller, shipper or end user. The goal of the Supply Chain Partner membership is to provide the subject matter expertise and human resources for the interface development project teams. Supply Chain Partners designate part-time volunteers from their companies for at least three projects a year which staff RosettaNet project teams and are responsible for the creation of the PIPs and dictionaries. Each Supply Chain Company contributes $10,000 per year to support RosettaNet activities. Supply Chain Partners include: Fujitsu, Lexmark, Seagate Technology, Sun Microsystems, TTI, and Western Digital to name a few.

Solution Partners provide tools and services to aid companies in adopting RosettaNet interfaces. Solution Partners do not have voting privileges or access to PIP workshops, but are encouraged to participate in industry feedback phases and join with Supply Chain Partners to implement PIPs. To qualify as a Solution Partner, your organization must be a systems integrator, software developer, consultant or other organization that provides tools and/or services that enable supply chain partners to implement RosettaNet business process interfaces. Typically, software developers, systems integrators and consultants are represented in this category. These partners will be trained in RosettaNet methodologies and will have an opportunity to certify software as RosettaNet-compliant. The annual membership fee is based on the company's annual worldwide revenue. Solution Partners include: Anderson consulting, CommerceOne, Dun & Bradstreet, Edifecs, GE Information Service, Harbinger, J.D. Edwards, PeopleSoft, RSA Security, SAIC, Sterling Commerce, Viacore, webMethods, and XMLSolutions to name a few.

Combined, all of these members develop and use the frameworks and guidelines in e-business transactions. E-business guidelines are developed from RosettaNet e-business framework specifications. The guidelines define how computer systems will execute the business processes and form the rough draft of the PIP detailed specification. Implementation guidelines are provided to interested partners. The guidelines are used to validate the information exchanged between companies, create the data content, and support the management and creation of internal tools used within a member company. Companies may extend the implementation guideline for their own individual needs but they may not override RosettaNet specifications. The final guidelines are then exchanged between member companies allowing for validation of message extensions during an e-business exchange.


4.1.2  RosettaNet Scope
RosettaNet's mission is to develop a standard set of parameters under which e-commerce can be conducted in real time over the Web.


4.1.2.1  Core Components
RosettaNet's Development Process includes Business Process Modeling and Analysis, PIPs, and Data Dictionaries all implemented within a set of related architectural components termed a framework. RosettaNet has used heavily many components of the Open Buying Initiative (OBI) in development of their Implementation Framework. For example, OBI data formats and process descriptions where broadened to be applicable to agent software components and service software component use.


4.1.2.1.1  Business Process Modeling
Business Process Modeling is used to identify and quantify the individual elements of a business process, creating a clearly defined model of the supply chain partner interfaces, as they exist today. This is called "As Is" modeling. This model reflects the results of extensive research at every level of the supply chain and is then analyzed to identify any misalignments or inefficiencies.


4.1.2.1.2  Business Process Analysis
Through the analysis of the detailed "As Is" model, a "generic To-Be" process emerges, showing the opportunities for re-alignment in the form of a Partner Interface Process (PIP) target list, and estimating the business impact of implementing the resulting PIPs (savings as a function of time and money).


4.1.2.1.3  PIP Development
The purpose of each PIP is to provide common business/data models and documents enabling system developers to implement RosettaNet e-Business interfaces, each of which includes the following:

RosettaNet develops PIPs through extensive process modeling to determine how partners (manufacturers, distributors, resellers, carriers and end-users) in the IT supply chain interact with each other as they carry out day-to-day business activities in each of six high-level business process areas -- Partner/Product Review, Product Introduction, Order Management, Inventory Management, Marketing Information Management, and Service and Support.

The first step in the development of a PIP guideline is for the users to capture the current "As-Is" business processes to create an understanding of the current partner business processes, their employee role interactions and business information needed to exchange information. Users then create a "To-Be" model that comprises partner roles and partner interface processes. The to-be model will define partner roles and structured properties that they exchange when they interact. The defined properties are captured in two property databases:  technical specification property database and a business property database.

The process model is no used as functional requirements for a networked application execution process model, called a "PIP Blueprint" that specifies how agents and services execute partner processes in a networked system. The agents and service software exchange messages in transactions that are sequenced by execution processes. Finally, the PIP guideline is used to create a PIP specification. This specification includes business message guidelines (HTML format) needed to carry the business processes contained in the PIP and corresponding DTDs for each message guideline.

Currently RosettaNet messages are created using the set of elements and codes defined in business and technical dictionaries. This set is used as a baseline from which teams create specific message exchange specifications. The values and codes that can be assigned to each of the data elements are precisely defined within the PIP implementation guideline. These guidelines are sent from RosettaNet to supply chain partners and solution partners. The guidelines define the vocabulary, structure and allowable data element values and value types for each message exchanged during the execution of a PIP and can be used to validate received messages by translation systems.

PIP specifications contain three parts: the Preamble Header, the Service Header, and the Service Content. All three are packaged for transport as Multipurpose Internet Main Extensions (MIMEs) messages. Each business message consists of a message header and a message body. Both the header and the body are complete, valid XML documents and are encoded within a multipart/Related MIME message. The Preamble Header section contains elements that are global to the RosettaNet service and are common to the Service Header and Service Content. Each message body and header has its own DTD. Since RosettaNet validates the grammar, sequence, schema, and then content the header is validated first (grammar and sequence validation) followed by the body (schema validation). This allows the message to have content errors but since the header has been parsed a failure message may be sent by the recipient to the sending party.


4.1.2.1.4  Dictionaries
As part of RosettaNet's foundational projects, two data dictionaries are developed to provide a common set of properties required by PIPs. The first is a technical properties dictionary (technical specifications for all product categories), and the second is a business properties dictionary, which includes catalog properties, partner properties (attributes used to describe supply chain partner companies) and business transaction properties. The Information Technology (IT) technical dictionary provides for a common platform to conduct business processes in an effort to try to eliminate disparity and provide for all partners to use a common language in which to do business. The Business properties dictionary defines business properties within PIPs, which describe the content of the Business Documents, which are to be exchanged between partners. This dictionary defines the business properties and allows for reuse of the properties in multiple PIPs. Business Dictionary content is approved during the approval of the PIP Blueprint and Business documents. These dictionaries, coupled with the RosettaNet Implementation Framework (exchange protocol), form the basis for each RosettaNet Partner Interface Processes.

Master dictionaries are used to define properties for products, partners, and business transactions. The master dictionary, coupled with an established implementation framework (exchange protocols), is used to support the e-Business dialog known as the Partner Interface Process or PIP. RosettaNet PIPs create new areas of alignment within the overall EC and IT supply-chains e-Business processes, allowing EC and IT supply-chains partners to scale e-Business, and to fully leverage e-commerce applications and the Internet as a business-to-business commerce tool. Previously, every distributor and manufacturer had its own proprietary dictionary of terms resulting in redundant, overlapping efforts by individual companies as well as confusion in the procurement process due to each company's unique terminology. With the RosettaNet technical dictionary, these companies will now be able to use a common platform to conduct business processes. For example, when introducing a new product, information describing that product will only have to be entered once by the manufacturer and will then appear consistently throughout distributor and reseller catalogs. RosettaNet is quick to point out that the dictionary's hierarchical structure is far more than a compendium of words and meanings. Layers within layers of descriptive fields refer to product type, multiple specifications and their definitions, terms to explain dimensions and their units and a value domain field for listing model variations. Another aspect of the RosettaNet dictionary is providing a precise language that enables fast and economical machine-to-machine translation of the words into foreign languages. This flexibility, which is characterized as essential to RosettaNet's overall mission to globalize the IT supply chain's business processes, promotes international, multilingual e-business initiatives that cross all geographic boundaries. Businesses can now understand each other and seamlessly integrate their business transactions.


4.1.2.1.5  Framework
RosettaNet's framework architecture (E-business Process), based on ISO Open Systems Interconnect (OSI) reference model, defines layers, which provide application, transport functionality, and defines the activity that occurs within the OSI application and session layers. The framework enables RosettaNet's networked applications to execute and validate PIP specifications. The RosettaNet Implementation Framework Specification defines the OSI application into the following layers:

RosettaNet is primarily in the business of creating PIP guidelines with which their partner organization members agree to conduct e-business. RosettaNet expects members of the industry to implement the guidelines in a manner that is compatible with their existing information systems and their future information system plans. It is also expected that industry members will build application systems that can accommodate both RosettaNet guidelines and other existing industry guidelines that are used in commercial applications that are outside of RosettaNet's scope.


4.1.2.2  RosettaNet Process Methodology
RosettaNet's framework is centered on the development of common e-business processes that they term Partner Interface Process. Simply put, a PIP is XML based dialogs that define business processes conducted between trading partners. PIPs are both machine-readable (i.e., XML DTDs) and human-readable. Members use PIP guidelines to configure specific e-business processes with other organizations. These e-business processes include the use of networked computer applications that span partner organizations in the supply chain and adhere to RosettaNet network application architecture specifications.

The RosettaNet business model is intended to enable supply chain business partners to execute interoperable e-business processes by continuously developing, maintaining and distributing PIP implementation guidelines. According to the RosettaNet Implementation Framework Specification, RosettaNet adopts existing e-business standards, guidelines, and specifications wherever possible and creates new e-business framework specifications where necessary. They frameworks are generic in nature so that they can be used for all types of e-business applications. According to the specification, there are five conceptual parts to the RosettaNet business model:

All guidelines and translations are defined within RosettaNet's e-business model as being distributed as machine-readable documents. This allows companies to quickly configure their RosettaNet-compliant applications to execute and validate new or updated PIP specifications.


4.1.3  RosettaNet Development Activities
The following section provides an overview of key development activities within RosettaNet. Topic areas covered in this section include the implementation of eConcert, current and planned future RosettaNet standards development activities.


4.1.3.1  Implementation Phase - eConcert
Launched in June 1998, RosettaNet has just concluded the pilot phase, eConcert, of its development cycle in February 2000. The pilot phase saw participants link full production systems. eConcert focused on the development of RosettaNet frameworks for catalog information, and software, memory and laptop technical specifications. This project was designed to streamline the search, ordering, shipping, and licensing of information technology products. RosettaNet's first industry projects included:

"eConcert involved project planning by many different departments and third-party solution providers. These collaborators created an internal network infrastructure, described all products and components consistent with RosettaNet dictionaries, developed interfaces to ERP and workflow systems, and implemented software that controls access to Web and database servers." This involved aligning internal business processes with one or more published PIPs, preparing internal systems to exchange one or more PIPs with another supply chain partner, and adopting the Guidelines for Trade Data Interchange (GTIN) part numbering schema, the Data Universal Numbering System (DUNS) number, the UN:  Standard Products and Service Code (UNSPSC) product classification code, and the RosettaNet Technical Specifications Dictionary (at least for PIP exchange purposes - not necessarily for internal usage). Members reporting readiness of internal business process alignments with selected PIPs were Avnet, Cisco Systems, Compaq Computer, Computacenter, Federal Express, GSA, Insight, MicroAge, NEC Technologies, Netscape, Solectron, Tech Data and UPS. Trading partners that have reported readiness and are also exchanging PIPs in pilot or production mode include Intel and Arrow Electronics, Hewlett-Packard and SAP, 3Com and CompUSA, and Ingram Micro with CompUSA.


4.1.3.2  Current and Future Efforts
European activity will be a goal for implementation in the year 2000 for RosettaNet. In December 1999, RosettaNet announced that it had opened a European Office and appointed Thierry Ceillier as Director of European Partner Relations. Headquartered near Geneva, Ceillier will manage the RosettaNet effort to identify and integrate specific European requirements of companies participating in a global initiative to align supply chain interface e-Business processes within the Information Technology (IT) and Electronic Component (EC) industries. He will also manage the European Partner Relations in these two industries.

Other initiatives that RosettaNet is focusing on for the year 2000 include:


4.1.4  Challenges
Currently RosettaNet's PIP's include only those for catalog information and computer specifications. To become a force in the years to come they must achieve buy in from more and diverse business entities in the world marketplace.

Development mimics the organization of today's standards bodies. While they boost of short turnaround times for implementation of new PIPs and changes to existing PIPs, as they grow this may not remain efficient. We may see either a return to today's EC/EDI Standards Body turn-around times or the emergence of industry specific standards organizations. In addition as more and more companies are added will the simplicity of the current PIP structure be maintained or will their develop the duplicity in documented processes to meet the global industry/company needs that we see today in our e-commerce standards.

Is this the creation of the 21st century VAN?


4.1.5  Summary
Currently focusing on the electronic business interfaces in the EC and IT supply chains, RosettaNet is attempting to develop a common business environment in which these companies may operate, however they plan to quickly spread into other supply chain markets. RosettaNet is defining master dictionaries to define properties for products, partners, and business transactions. These dictionaries coupled with RosettaNet's Partner Interface Processes (PIPs) are intended to allow "EC and IT supply chain partners to scale e-Business, and to fully leverage e-commerce applications and the Internet as business-to-business commerce tools." According to a recent RosettaNet press release, "More than 200 companies representing $1 trillion in annual information technology and electronic components revenues currently participate in RosettaNet's standards development, strategy and implementation activities." An admirable start but are we now seeing a true revolution or yet another consortium of companies beginning to cloud the e-business community. One has to wonder where this will all lead. With existing standards bodies like ANSI/X12 and UNEDIFACT no closer to merging into one EC/EDI language we now have organizations like RosettaNet, Organization for the Advancement of Structured Information Standards (OASIS), and ebXML coming to light promising electronic architectures with which to improve the e-business environments. Are we seeing a true evolution or just a muddling of the e-business waters? The true evolution, if it is to occur, will result in a merging of the languages, platforms, and environments into a single global standard promoting a malleable language, message transport and protocols, digital security, and infrastructure architecture that allows for business, both large and small, room for innovation.


4.2  ebXML - Electronic Business XML Initiative
This section discusses the impetus behind the ebXML initiative and the makeup of the ebXML organization (see http://www.ebxml.org). In this section, we will also look at where this work is headed and provide a recommendation for DoD participation and/or involvement relating to the ebXML initiative.

The ebXML initiative is a joint effort of the United Nations Center for Facilitation of Procedures and Practices for Administration, Commerce and Transport (UN/CEFACT) and OASIS with the collaboration of cross-industry electronic business experts and e-commerce initiatives to establish a global framework specification to standardize XML business specifications for the exchange of electronic business data. ebXML is currently focusing on areas such as the transport and routing, business process methodology, technical architecture, and the core components needed to facilitate trade worldwide. ebXML can be best defined as a vendor, platform, operating system and data source/destination neutral method for exchanging electronic business data on a global scale.

The purpose of the ebXML initiative is to research and identify the technical basis upon which the global implementation of XML can be standardized. The mandated projected goal of 18 months, convening in late November 1999, is to provide an open technical framework specification enabling XML to be utilized in a consistent and uniform manner. ebXML will attempt to standardize the exchange of electronic business data in application to application, application to person, and person to application environments.

The ebXML initiative is chaired by a senior member of the UN/CEFACT Steering Group, Klaus-Dieter Naujok of the Harbinger Corporation, with Dr. Robert Sutor of IBM, who is also the Chief Strategy Officer of OASIS, as the Vice Chair. The two main organizations involved with development of the ebXML initiative are briefly explained in the next section.


4.2.1  ebXML Organization
As mentioned previously, the ebXML initiative is a joint effort of the UN/CEFACT and OASIS. Note that both UN/CEFACT and OASIS are discussed in detail in Sections 2.2 and 4.5 respectively. Figure 4.2.1-1 shows a simplified view (and strong points) of the two organizations that founded the ebXML initiative.

 


Figure 4.2.1-1  The Founding Organizations for the ebXML Initiative


UN/CEFACT - the joined forces with OASIS to initiate a worldwide project to standardize XML business specifications. UN/CEFACT has established the ebXML Working Group to develop a technical framework that will enable XML to be used in a consistent manner for exchanging all electronic business data. The Steering Group has requested a moratorium on XML development among its member groups to allow the ebXML initiative to take the lead as the lone standard for cross-industry XML.

OASIS - The Organization for the Advancement of Structured Information Standards dedicated solely to product-independent data and content interchange, and focusing on product interoperability, OASIS embraces the complete spectrum of structured information standards including XML. OASIS operates XML.org, the first global XML industry portal featuring the XML.org Registry and Repository that offers automated public access to XML schemas for electronic commerce, business-to-business transactions, and tools and application interoperability. OASIS has joined with UN/CEFACT and end user organizations, including those mentioned below, to create a global XML standard; thus the ebXML.


4.2  Additional Support and Endorsement
Support for and endorsement of the ebXML initiative is being voiced by a wide variety of companies and organizations from around the world including:

· ASC X12 (Accredited Standards Committee X12)

· Australian Customs

· DISA (Data Interchange Standards Association)

· DataChannel

· FORESIGHT

· GENCOD-EAN France

· JIPDEC (Japan)

· Kraft Foods, Inc.

· Ontology.Org

· PeopleSoft, Inc.

· Swisscom Ltd.

· Trinary Systems

· XML/EDI Group

· XML Solutions

 

A comprehensive list of participants is available from the ebXML.org Website.

The Data Interchange Standards Association (DISA) is uniquely poised to support the development of robust industry specifications that harness extensible markup language (XML), Internet technology and EDI. Moving aggressively ahead to pursue ground breaking technological developments impacting the e-business community, the newly appointed president and CEO of DISA, Kerry Stackpole states "As DISA propels global e-commerce, we remain committed to building productive partnerships with complementary initiatives and organizations such as the electronic business XML initiative."

DISA endorses the ebXML initiative to design electronic business XML specifications, and is currently facilitating for organizations such as ASC X12, the Interactive Financial Exchange, the Mortgage Industry Data Standards Maintenance Organization and the Open Travel Alliance, who are highly focused on the integration of XML.

ASC X12 - The Accredited Standards Committee X12 is working to represent X12 semantics in an XML format to support the data transfer needs of a broad base of users, including small and medium sized enterprises, ASC X12 is anxious to participate in the ebXML initiative.

ASC X12's strategic policy statement of endorsement to support the work of ebXML reads, "Building on the momentum of two successful meetings of the newly-formed ebXML Work Group, the Steering Committee of ANSI ASC X12 has voted to endorse the mission, goals and efforts of ebXML. X12 will ensure that its XML efforts are consistent with the work and recommendations of ebXML. Furthermore, X12 encourages XML education, development of business requirements, and participation in the ebXML initiative."

As noted by William J. Kammerer of the FORESIGHT Corporation, "the case for ebXML is so compelling that at the February 2000 Denver X12 Trimester meeting, all attention was paid to ebXML."

Kirk Chan, Manager of Product Strategy for PeopleSoft states, "PeopleSoft applauds the ebXML standardization efforts--ultimately our customers will benefit most. With XML rapidly becoming the lingua franca for electronic commerce, broad international standards will help customers running PeopleSoft Applications for e-business to establish relationships with suppliers, partners and customers without regard to the size of the enterprise."

The scope of the ebXML initiative, which follows, is in no doubt a huge undertaking of which we will attempt to provide an acceptable overview of work requirements, accomplishments, and work still in progress.


4.2.3  Scope of the ebXML Initiative
A primary objective of Electronic Business eXtensible Markup Language is to lower the barrier of entry to electronic business in order to facilitate trade, particularly with respect to small and medium sized enterprises (SMEs) and developing nations. According to ebXML marketing information, the value of ebXML is to:

ebXML delivers its value by utilizing available technologies and e-commerce expertise in the following areas:

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 marketplace, which will provide architecture with the following attributes:

The ebXML organization is comprised of several working groups, each with specific areas of concentration. The Working Groups, also referred to as "Project Teams" are as follows:

The subsequent subsections 4.2.3.1 - 4.2.3.8 discuss each working group in detail.


4.2.3.1  Requirements
Project Leader - Mike Rawlins, Rawlins EDI Consulting.

The ebXML Requirements Project Team is focusing on the following three key areas:

With a single point of focus, the team will strive to collate requirements developed within the work group and to solicit requirements from the other work groups, with an initial draft by December 20, 2000. The ebXML Requirements Specification Working Draft is currently available at the ebXML Website at http://www.ebXML.org with periodic updates as information becomes available.


4.2.3.2  Business Process Methodology
Project Leader - Paul Levine, Telecordia.

The vision of ebXML with respect to business processes is that organizations be able to express their business processes according to a specification to insure that they are understandable by other organizations. This shared understanding in turn would help integrate the business processes of trading partners.

Business process models would provide meta-data for technology mapping and structures for the component library. Messages containing business and technical content, sent and received by host services, would support the common technical architecture. This common architecture, in turn, would define the distributed repository, syntax and schema, registry, security and transport services.

The scope and key issues of the Business Process Task Group include:


4.2.3.3  Technical Architecture
Project Leader - Duane Nickull, XML Global.

Duane Nickull states, "Ideally, a move towards ebXML will preserve the semantic information derived from mature EDI formats. The 20 years experience of EDI will immensely benefit the ebXML initiative."

The focus of the Technical Architecture team is a goal to support automated generation of XML schema, including DTDs now supported by XML and the upcoming XML-Schema specification. With a recommendation for populating schema through an automated process that takes advantage of common components and technology mapping, this would allow developers to concentrate on common components and businesses to respond more quickly and effectively to new opportunities.

Technical Architecture Design Rules would include the following recommendations/proposals:

Develop clear visual representation/documentation of the architecture for software vendors, conforming organizations and corporate clientele. Define technical requirements for repositories. Leverage existing technologies and standards.


4.2.3.4  Core Components
Project Leader - Lisa M. Shreve, SysCom Strategies Inc.

The mission of the ebXML Core Components Project team includes the following:

The Guiding Principles/Requirements of the Core Components consist of the following:


4.2.3.5  Transport/Routing and Packaging
Project Leader - Rik Drummond, Drummond Group.

This project team is focused on defining the requirements for a universal business-grade transport system to support the movement of ebXML and non-ebXML objects. Existing transport standards will be evaluated against the requirements for suitability as the ebXML transport mechanism to enhance implementation.

This team outlined a layered ebXML message with message structure information at the top followed by message headers and a message body. The headers would include transport routing, application routing, digital receipts requests, intermediate status requests, workflow data and security protocols. The message body would include signature and encryption-description blocks and content sections known as body parts.

The team's project overview as presented is to:

The project team's objectives are the following:


4.2.3.6  Registry and Repository
Project Leader - Scott Nieman, Norstan Consulting.

The objective of the project team is to "define the business and functional requirements for an ebXML registry and repository" and "XML-based interfaces to interact with the registry and repository."

The team's mission is to deliver requirements and specifications for the creation and use of a registry and repository. The registry and repository will be comprehensive, distributed, business analysis driven, and support the runtime and development viewpoints of the ebXML architecture.

This team specifically recommended against setting up a new ebXML repository but instead suggested adopting the XML.org repository begun by OASIS. The group, like others in the ebXML project, also proposed following an object-oriented approach, specifically the XML meta-data interchange developed by the Object Management Group (OMG), or the XMI specification for registry and repository efforts.

The business requirements for the repository are presented as the following:

Project deliverables of the Registry and Repository Project team include the following:

What are Registries and Repositories?

Registries and repositories are two mechanisms that offer assistance to the problem of making available for widespread machine based use the fruits of efforts to standardize commonly used semantics. For those familiar with existing EDI Standards, a repository is related to the data dictionaries and directories a standards organization uses to store descriptions of approved semantics.

Just as with the data dictionaries and repositories of an EDI Standards organization, the repository is dynamic. In both cases, new development and maintenance introduce changes to the content. In traditional EDI, the state of the dictionaries and directories at given points in time are published, and given a unique reference identification. Using these published documents, parties to information exchange have a basis upon which to implement systems, which properly reflect the semantic intent of data exchanged in compliance with these published snapshots of the ever-changing dictionaries and directories.

A Registry is the electronic equivalent of the act of publishing a snapshot of the dictionaries and directories in the EDI standards environment. No further change is allowed to the information pointed to by a registered identifier. Just as with standards, registered identifiers may become obsolete, but a replacement for the obsolete information requires registration of a new identifier. A registry must include a secure mechanism for verifying that registered content is not altered after registration. In addition, a unique naming service for registration names must exist.


4.2.3.7  Technical Coordination and Support
Project Leader - Dick Raman, EDI-TIE.

The purpose of the Technical Coordination and Support Project Team is to coordinate the work among the ebXML technical project teams in order to identify inconsistency among their deliverables. Other responsibilities include defining that ebXML is compliant in regard to implementing ebXML deliverables. Further, the team shall research external work related to the overall ebXML deliverables in regard to their applicability and benefits to the ebXML work efforts.


4.2.3.8  Marketing, Awareness and Education
Project Leader - Ann Bullen, PricewaterhouseCoopers.

The real success for ebXML will be in its adoption by the business community. The mission of the ebXML Marketing, Awareness and Education team is to stimulate, inform and communicate to the business community the opportunities, benefits and outcomes of the ebXML project. In order to achieve success, the Marketing, Awareness and Education team will develop requirements and deliverables that address the following:


4.2.3.9  Proof-of-Concept Pilot Development and Demonstrations
Project Lead - Sun Microsystems Representative.

This newly formed work group, which is lead by a representative from Sun Microsystems, is to facilitate the development of ebXML proof-of-concept pilot demonstration systems. There is currently an open invitation from participants in the ebXML effort to suggest/participate with this effort. A proof-of-concept demonstration for the routing and enveloping of ebXML messages based on sample OpenTravel Alliance (OTA) business messages were exchanged between a small company and a large enterprise at the conclusion of the May ebXML meeting. The messaging prototype implemented the draft ebXML specification for exchange of business documents between trading partners using the very popular Internet Web and E-Mail protocols, HTTP and SMTP.


4.2.4  EDI Specific Points
Excerpts from the ebXML Requirements Specification Version 0.60 March 3, 2000 emphasizes that EDI is very much a part of the initiative. Some of the EDI specific points include the following:

As stated previously, work within ebXML will be a "work in progress" tentatively accommodating 18 months. The schedule for the planned ebXML development meetings is provided in the next sub-section of this report.


4.2.5  ebXML Development Meetings
Meetings of the ebXML initiative are held every quarter. It is the intention to hold these meetings at different locations around the world in order to encourage and facilitate global participation.

The next meeting will be in Brussels, Belgium, May 8-12, 2000. The tentative schedule for the remainder of year 2000 and first half of 2001 is:

Date

City

· August 7-11. 2000

USA (city to be determined)

· November 6-11, 2000

Tokyo, Japan

· 1st Quarter 2001

TBD

· 2nd Quarter 2001

TBD

 

4.2.6  Challenges
While the ebXML initiative identifies with the need for standardization in applying XML for the exchange of electronic business data, unfortunately it seems, not everyone is willing to cooperate, compromise, or share their experiences and goals for standardization. It is interesting to note the following quote from the "XML Standard is Near" article by Alan Kotok in the March 3, 2000 issue of Planet IT. "Despite the broad representation of interested parties at the initial meeting for ebXML, two major players were absent from the second meeting in February: Microsoft's BizTalk and RosettaNet. BizTalk offers a framework based on a flavor of XML called XML-Data Reduced, as well as its BizTalk repository. RosettaNet is perhaps the most advanced XML vocabulary, and although it focuses on the computer business, it offers a methodology that other industry groups can readily adopt." The ebXML Core Components team has addressed the important need to ensure participation from organizations such as RosettaNet, OBI, and BizTalk, among others.


4.2.7  Summary
In summary, as the concepts of this paper and the work being done within the ebXML are considered, one might question the effect or impact that this initiative may have on current business practices within the DoD. It is encouraging to note the level of intensity at which ebXML is attempting to address issues regarding XML-based standardization for the exchange of electronic business data. Issues of the utmost importance, such as in developing ways to complement traditional EDI investments- which has a rich heritage among predominantly larger organizations, while remaining focused on the needs of SMEs and developing nations, are being scrutinized.

In a recent report from Giga Information Group challenging the popular notion that traditional EDI transactions will be widely replaced by emerging Web alternatives, it seems that EDI is being used more than anybody thought, and appears that EDI usage will not slow down anytime soon. The report projects the value of EDI transactions to grow to $3.8 billion by the year 2002. However, the mode of transport for electronic data and the limited flexibility that traditional EDI allows will be strongly affected by Web technologies such as XML which promises a smarter, faster, cheaper way to transport business data. It is important for DoD to consider the ongoing work of the ebXML initiative, since this effort is focusing on developing a single standard framework for XML/EDI.

Recall that the ebXML initiative is an 18-month effort, which began November 1999. After the initial ebXML framework is formally released (circa June 2001), the potential effects might be experienced immediately by smaller companies wishing to conduct electronic business with large traditional EDI-based companies which were too costly due to deployment of EDI systems and VAN services. ebXML will enable SMEs to be positioned to play a strategic and important role in the global supply chain because of the lower barrier to entry in this market.

By placing a moratorium on XML development and directing all attention to ebXML, UN/CEFACT is expressing their seriousness in the need for harmonization among international standards. With the endorsement of ebXML by DISA and the X12 community, it is expected they will soon follow with their own moratorium on independent XML development.

While it is still premature to surmise that ebXML will become the "holy grail" of standardized electronic business exchanges, it remains to be seen if it will live up to the tentative promises being expressed. There apparently are many ongoing issues yet to be addressed by ebXML, one of which is a common solution to synchronize the functionality across X12 and UN/EDIFACT.

ebXML promises to deliver a framework by the end of their 18 month timeframe, and the e-commerce industry collectively will agree that standardization is not only long over due, but also required to achieve a "single global electronic market." Will a grand unified specification become reality or will competing developers go off in all directions building an XML Tower of Babel?


4.3  BizTalk
BizTalk is an industry initiative started by Microsoft and supported by a wide range of organizations, from technology vendors like SAP and CommerceOne to technology users like Boeing and BP/Amoco. BizTalk is not a standards body but a community of standards users, with the goal of driving the rapid, consistent adoption of XML to enable electronic commerce and application integration.

Announced in March 1999, BizTalk is comprised of the following components:  the BizTalk Framework provides a technical road map for describing business processes in industry-standard XML, BizTalk Server 2000 technology preview is Microsoft's second-generation software solution supporting the BizTalk Framework and supplants the earlier BizTalk JumpStart Kit with a significantly expanded set of capabilities and infrastructure, and BizTalk.org (http://www.biztalk.org), a community resource to accelerate the expression of business processes in XML, is an open XML business process schema repository which provides access to XML schema from industry standards bodies like ACORD, BASDA, the HR-XML Consortium and OAG as well as popular applications vendors like Autodesk Inc., Clarus Corp., CommerceOne Inc., Great Plains Software Inc., Intelisys Electronic Commerce LLC, Navision Software U.S. Inc., SAP AG and Scala Business Solutions, NV.


4.3.1  BIZTALK ORGANIZATION (www.biztalk.org)
Companies that want to use XML need a simple way to find the information about the schemas, documents and business processes that other businesses and applications support. Microsoft has chosen to create and manage www.biztalk.org. Over the course of the summer in 1999, this site became into a portal for locating, managing, learning about and publishing XML, XSL, and the information models used in applications. www.biztalk.org is an on-line repository providing member and partnership programs.


4.3.1.1  Membership
Membership, which is a free service, puts developers in touch with the businesses that use software that uses XML. The www.biztalk.org serves as a centralized and managed library that lets companies and software vendors share information about schemas, XSL and business processes that are supported by applications that support the BizTalk Framework.

Other membership services planned include on-line community discussion groups where developers of all experience levels can share information about their experiences. The discussion groups are also educational and support channels that are monitored by experts at Microsoft. Periodic on-line seminars will be held using chat-group technologies. These hosted discussions feature experts from Microsoft and from partner companies and provides developers with a way to interact with the companies that are developing the BizTalk Framework and products based on it.

Finally, members are entitled to access to the latest tools, samples and educational materials for download, as well as articles and news about real integration projects and software products that use or are based on the BizTalk framework.


4.3.1.2  Schema Publishers
Companies that are the registered owner of either a trademark or Internet domain name will be granted the ability to publish information about the schemas that their products or standards require. Software vendors and standards bodies are examples of the kinds of organizations that will become Schema Publishers.

Schema Publishers will be provided with storage space, access to schema design and editing tools and will be allowed to publish information about their schemas and business processes. Schema Publishers that complete a submission process, a collection of documents that describe and categorize an XML schema based on the BizTalk Framework, will be able to make their submissions visible to the membership, who can search by author, company, product industry, process and document type.

Schema Publishers will be given control of their schemas and will have the ability to measure how many other companies use the information they've published as well as notify their customers of impending or proposed changes. A reviewer feature will allow Schema Publishers to share proposed changes with select individuals of their choosing. These "in review" submissions will not be accessible via the general search capabilities.


4.3.1.3  Partners
Partner programs are being defined for software companies that have developed products or published schemas and information that other companies need in order to integrate with their software. Partners have access to the BizTalk Framework Publisher's Toolkit as well as logo programs. The Publisher's Toolkit will link companies that purchase products that use the toolkit directly into www.biztalk.org and provide the same portal services that let members locate the information that they need to do business together through the internet. Through this toolkit the software will be able to automatically create and publish information as desired by the end customer.


4.3.1.4  The Steering Committee
The www.biztalk.org was set up with a built-in watchdog group called the Steering Committee in order to prevent anyone from subverting the BizTalk Framework or XML in proprietary ways that benefit one vendor or group of customers more than another. The purpose of the BizTalk Steering committee is to provide the oversight and guidance that will make the BizTalk Server, the BizTalk Framework and www.biztalk.org an open and level playing field.

The steering committee is a hand-selected group of standards bodies, government agencies. This group was chosen for their experience, insight, interest and commitment to the BizTalk Framework. Steering committee representatives review proposed changes to specifications earlier than they are posted to the www.biztalk.org site. This preview step assures Microsoft that the changes that are planned make sense and don't violate the core principals of the initiative. The changes that are reviewed are based on feedback gathered at the web site and via E-Mail.


4.3.2  Additional Support and Endorsement
In May 1999, Microsoft and Ariba joined forces to accelerate the adoption of Business-to-Business E-Commerce and will cooperate in developing BizTalk schema for E-Commerce. According to the press release, "The companies will join to integrate Commerce XML (cXML), an emerging standard for business-to-business e-commerce, with the Microsoft BizTalkTM framework to define schema for communicating operating resource transactions, such as catalogs and orders. In addition to collaborating on BizTalk and cXML, Ariba and Microsoft plan to work together to implement these e-commerce frameworks into products offered by both companies. Ariba will support the BizTalk framework in Ariba e-commerce solutions, and Microsoft will integrate support for cXML into the upcoming releases of the Microsoft Commerce Server and BizTalk Server. Under the planned development, Ariba will use XML-Data Reduced (XDR), the preferred syntax for BizTalk, in the next version of cXML. XDR is an alternative to the DTDs that are outlined in the Extensible Markup Language standard and provides a richer way to define XML documents. Not only does XDR use XML itself to describe the format of a document, it supports two features critical to reusable e-commerce documents-data types and name spaces. Support for data types enables the more reliable processing of data."

While BizTalk will integrate concepts of cXML, Dan Rogers, a program manager on BizTalk.org, discussed on a www.biztalk.org discussion forum that "there are no current plans for Microsoft to directly support, adopt or contribute to the ebXML effort."


4.3.3  BIZTALK SCOPE
BizTalk is a cross-platform e-commerce framework that is intended to make it easy for businesses to integrate applications and conduct business over the Internet with trading partners and customers. The BizTalk framework is composed of XML schema and industry standards that enable integration across industries and between business systems, regardless of platform, operating system or underlying technology. The newly created XML specification will provide streamlined, accelerated and easy-to-use business processes and eliminate current system boundaries, help companies create more online business, and increase the opportunity to communicate and cooperate with other companies.


4.3.3.1  CORE COMPONENTS
The following section provides an overview of the core components within BizTalk. Topic areas covered in this section include the BizTalk framework, BizTalk server, and the BizTalk process methodology.


4.3.3.1.1  BizTalk Framework
The BizTalk Framework is designed to foster application integration and electronic commerce through data interchange standards based on XML. It assumes that application programs are distinct entities, and application integration takes place using a loosely coupled, message-passing approach. There is no need for a common object model, programming language, network protocol, database or operating system for two applications to exchange XML messages formatted using the BizTalk Framework. The two applications simply need to be able to format, transmit, receive and consume a standardized XML message.

Messages are the basis for the most significant contributions of the BizTalk Framework. A message flow between two or more applications is a means to integrate applications at the business-process level by defining a loosely coupled, request-based communication process.

Microsoft anticipates that the vast majority of interchanges, the exchange of XML documents and messages between trading partners or applications, implemented using the BizTalk Framework will use a simple HTTP post transport, but business may also be able to use other transports including FTP and message queuing technologies including IBM Corp. MQSeries and the Microsoft Message Queue Server.

Since few software applications today provide native support for XML, Microsoft anticipates businesses and software companies implementing layers of adapters to enable their existing applications to participate in the first generation of BizTalk Framework interchanges. For many applications, these adapters take an existing function call, translate it into an XML document, and route the document to a target destination, whether it is a trading partner or another application within a corporate intranet.

Until applications have native support for XML, these types of BizTalk Framework interchanges will require layered software that transforms native data types into XML and then performs the XML document routing. The BizTalk Framework will also provide support for schemas describing the more complex interchanges involving multiple documents exchanged in a sequence. End-user companies have built these types of XML document transformers and routers in-house. Microsoft is developing a BizTalk Server that automates many of the functions required in a BizTalk Framework interchange. Software products potentially capable of supporting BizTalk Framework interchanges are available today from companies like webMethods and DataChannel Inc. The important point is that BizTalk Framework interchanges do not require any specific software product from any individual software vendor.


4.3.3.1.2  BizTalk Server
According to Microsoft® literature, "Microsoft® BizTalkTM Server 2000 is a standards based platform for developing and managing application integration within and between organizations. Utilizing XML as the common document format, it allows companies to integrate and manage end-to-end business processes regardless of operating system or location. BizTalk Server's foundation is its reliable and rules-enabled business document delivery, transformation, and tracking infrastructure. It enables trading partner integration, electronic procurement, B2B portals and extranets, as well as automating value chain processes. It provides the infrastructure and tools to enable e-commerce business communities. The foundation of the BizTalk Server is its rules based business document routing, transformation, and tracking infrastructure. This infrastructure enables companies to integrate, manage, and automate business processes by exchanging business documents (e.g., purchase orders, invoices) among applications within or across organizational boundaries.

According to Microsoft literature, "BizTalk Server 2000 includes:

The BizTalk Server will provide a simple and scalable server product that will work with similar products and applications to facilitate the interchange of information that is encoded according to the BizTalk Framework. This server product is not available today. Specifications that allow other companies to write software that can interact with the BizTalk Server by properly manipulating the routing, security and Quality Of Service (QOS) tags are part of the BizTalk Framework Specification.


4.3.3.2  BizTalk Process Methodology
BizTalk Framework is a set of guidelines for how to publish schemas in XML and how to use XML messages to easily integrate software programs together in order to build new solutions. It is designed to use existing data models, solutions, and application infrastructure, and reformats it into XML for use in electronic commerce. The BizTalk Framework consists of a technical specification that defines a way to use XML in a consistent way, a code set that defines a small number of mandatory and optional XML tags, and the www.biztalk.org Web portal. These three elements each combine to form the basis for achieving friction-free integration. The special XML tags, or codes, defined by the BizTalk Framework address issues that are common to all integration solutions. The BizTalk Framework was designed to allow developers to eliminate three elements found in EC implementations. These elements are transport selection, calling convention, and data format. The goals for the BizTalk Framework at the outset included reducing or eliminating these factors.

BizTalk Framework schemas, business documents and messages expressed in XML are registered and stored on the BizTalk.Org Web site. Any individual or organization can download the framework and use it to implement and submit XML schemas to the Web site. As long as the schemas pass a verification test, they are valid BizTalk Framework schemas. The BizTalk.Org Web site will provide an automated submission and validation process. Individuals or organizations can freely use XML schemas from the BizTalk.Org Web site within their applications, as long as the schema is published for public use. Businesses will also have the option of publishing their schemas on the BizTalk.Org Web site in a secure area for private use between trading partners. A steering committee composed of software companies, end users and industry standards bodies will provide guidance on how the BizTalk.Org Web site is organized and managed.

According to the www.biztalk.org Website, "The BizTalk Framework provides the following benefits:

Microsoft will natively support the BizTalk Framework in its product line and will publish XML schemas to the BizTalk Framework Web site for public use. Other software vendors supporting the BizTalk Framework have also made this commitment."


4.3.4  BizTalk Development Activities
The following section provides an overview of key BizTalk development activities. In this section, both the implementation phase as well as current and planned future efforts of BizTalk are discussed.


4.3.4.1  Implementation Phase
BizTalk was announced in March 1999 and since this time Microsoft has developed a BizTalk Framework XML Tags Specification defining a common way to use XML to accomplish identification and routing and BizTalk Framework Guidelines which defines a set of design guidelines for the Microsoft BizTalk Framework documents. In addition, www.biztalk.org has been created as a place for BizTalk users and developers to read information on the initiative, discuss development ideas and concerns, and download BizTalk related tools. Lastly, BizTalk Jumpstart kit was release in the last quarter of 1999 with the follow-up release of Microsoft BizTalk Server 2000 Technical Preview available for download only in the first quarter of 2000


4.3.4.2  Current and Future Efforts
Current BizTalk efforts seem to be focused on the development of the Microsoft® BizTalkTM Server 2000 which, according to the Microsoft Website, is currently scheduled for release in the fall of 2000.


4.3.5  Challenges
BizTalk appears to be a Microsoft driven effort based around their implementation of the BizTalk Server 2000. The BizTalk Server 2000 Readme file denotes that "It is strongly recommended that you do not use the FTP transport and receive functions for this release (Technical Preview download). FTP may not be supported for BizTalk Server 2000."

According to the Microsoft Website BizTalk 2000 in its final release will use the "Windows DNA 2000 architecture. At the core of Windows DNA 2000 is Microsoft Windows 2000, the foundation layer upon which BizTalk Server 2000 resides." This implies that to fully utilize all the capabilities of the BizTalk Server 2000, the user will be required to use Windows 2000 and possibly other Microsoft applications, such as databases, which are based upon the Windows DNA 2000 architecture.

The BizTalk Server 2000 is not required to be installed on both ends of a transaction, as long as the server is running on one end and the client application is running on the other. Microsoft, however, strongly encourages the installation of BizTalk Server 2000 at both ends of the transaction to fully realize the total capabilities of their product. It is unknown at this time what functional limitations this type of setup produces. Depending on the final price tag of the application, BizTalk Server 2000 requirements may not allow small businesses to afford the ability to integrate BizTalk Server 2000 into their business procurement process. In addition, Microsoft highly recommends installation of portions of the application on multiple machines each running Windows 2000, again adding to the total cost of outfitting a small business with this capability.


4.3.6  Summary
BizTalk is described by Microsoft as "a cross-platform e-commerce framework that is intended to make it easy for businesses to integrate applications and conduct business over the Internet with trading partners and customers. The BizTalk framework is composed of XML schema and industry standards that enable integration across industries and between business systems, regardless of platform, operating system or underlying technology. The newly created XML specification will provide streamlined, accelerated and easy-to-use business processes and eliminate current system boundaries, help companies create more online business, and increase the opportunity to communicate and cooperate with other companies." Unfortunately, it appears that this attempt at accelerating the adoption of XML into today's business seems little more than a marketing step to draw customers into using Microsoft products. The entire initiative has been conceived, set-up, run, and monitored by Microsoft. While currently unable to evaluate the BizTalk Server 2000 due out in the fall of 2000, it is hoped that BizTalk merges it's selling points into RosettaNet or ebXML type XML initiatives and the community may find a single reference and knowledge point from which to develop their business.


4.4  Common Business Library (xCBL 2.0)
In this section, we will briefly explain CommerceOne's Common Business Library (xCBL) 2.0 (see http://www.commerceone.com/xml/cbl/index.html), the functionality and applicability to electronic commerce applications, and the role it assumes in regard to new and existing XML standards and initiatives. xCBL 2.0 is the first open XML specification for the cross-industry exchange of business documents such as product descriptions, purchase orders, invoices, and shipping schedules. CommerceOne is an active participant in numerous XML standards bodies and industry initiatives including the World Wide Web Consortium, the IETF, CommerceNet's eCo Working Group, RosettaNet, OASIS, XML/EDI, ebXML, and BizTalk. XCBL 2.0 will be a key part of the BizTalk schema based repository.

XCBL 2.0 is a set of XML building blocks created to provide the schema document framework that is needed for robust, reusable, XML document exchange in electronic commerce. These building blocks were defined based on extensive research and collaboration with CommerceOne and the leading XML industry initiatives.

xCBL 2.0 represents more than two years of research and development by CommerceOne and Veo Systems, which was acquired by CommerceOne in January 1999. Veo was chosen in September 1997 by the U.S. Government's Advanced Technology Program (ATP) of the National Institute of Standards and Technology (NIST) to conduct research and development on XML foundations for electronic commerce. Because platform and application heterogeneity are facts, integration at such a scale would have to be at a semantic level where components connect and communicate through a shared language, vocabulary, and business concepts. Dr. Marty Tenenbaum, the founder of Veo and CommerceOne's Chief Scientist, foresaw the need for a Common Business Library to enable companies to interconnect their business services over the Internet.

In a statement of support for xCBL Shirley Hurwitz, Program Manger of the ATP relates the following: "CommerceOne's XML-based Common Business Library is an innovative framework for enabling interoperability among online trading communities. The ATP has been partly funding the underlying xCBL research since 1997 because we believed in its potential to have a major impact on electronic commerce and the nation's economy."

The goal of xCBL 2.0 is to provide an initial set of XML building blocks that companies can assemble and extend to quickly develop XML applications. Some of these building blocks come from well-established international standards such as ISO 8601 (date and time), ISO 31 (measures), and ISO 4217 (currencies). Other building blocks come from SIMPL-EDI, a project to create minimal EDIFACT transaction sets. The "standard" business documents in xCBL 2.0 are based on the building blocks and an analysis of similar documents emerging from the Open Buying on the Internet (OBI), RosettaNet, and Open Trading Protocol (OTP) initiatives, with the goal to harmonize them as much as possible.

According to CommerceOne, xCBL 2.0 will reportedly fit into the "core components" category of the ebXML initiative (see Section 4.3 of this paper). Ultimately, xCBL will become "ebXML compliant," meaning that a transformation will be possible between xCBL and any ebXML-compliant set of business document data, whether in an XML format or in an EDI-based syntax.

xCBL 2.0 relates to other commerce specifications in that it is not a single standard, rather a collection of common business elements that underlie all EDI and Internet commerce protocols. Developed and modeled after EDI semantics such as X12 and UN/EDIFACT in order to preserve and extend the EDI investments of trading partners, xCBL 2.0 with its reusable components speed the implementation of standards and facilitate their interoperability by providing a common semantic framework. UN/CEFACT TMWG Chairman and ebXML Chair Klaus Dieter-Naujok stated that "xCBL shows that EDI and XML can co-exist and complement each other, unlike too many of the so-called `commerce XML standards' that make no attempt to preserve two decades of EDI standards and implementation experience."

Any company, large or small that is presently conducting electronic commerce or wanting to participate can utilize xCBL 2.0 to accelerate their XML based e-commerce efforts. xCBL 2.0 provides a transition path for companies wanting to move from EDI systems to open Internet-based commerce systems. Of special value to small companies wishing to transition from simple Web forms to more sophisticated XML e-commerce applications, xCBL 2.0 can help to accomplish this. In addition, companies who have previously chosen not to use EDI due to cost or other reasons can now participate in exchanging XML e-commerce documents and because xCBL 2.0 is not a proprietary effort, vendors can be assured that they are not choosing a closed solution. Thus, xCBL 2.0 provides the means for nearly every potential e-commerce trading partner to participate. xCBL 2.0 is the first XML specification for electronic commerce designed to take advantage of the expressive power of XML schemas as explained in the following section.


4.4.1  Schemas versus DTDs
One of the most important aspects of xCBL and one that sets it apart form other e-commerce XML applications, is the decision to use XML schema languages rather than XML DTDs. While schemas are still an emerging technology, it was obvious to CommerceOne with experience in the EDI realm as well as elsewhere that DTDs were not sufficient for e-commerce data, which tended to be very strongly typed. A schema provides a way to do many of the basic declarations possible in XML, but makes the declarations easier to both read and write.

Another problem is that DTDs lacked the extensibility needed to allow users to describe their own data, while still using a standard language and set of tools. Additionally, they provide no mechanism for maintenance and system upgrades because they do not model inheritance in the same way as the object-oriented systems that process the documents they describe.

As a demonstration of its commitment to interoperability, xCBL is available in XML DTD form and in two different schema languages: Microsoft's XML Data Reduced (XDR) and CommerceOne's Schema for Object-oriented XML (SOX). SOX was developed to overcome the limitations of XML DTDs, which typically model the content of information elements just as text strings, with some weak numeric typing in certain structures. Electronic commerce applications need to be able to specify stronger semantic constraints to handle some strings as prices, part numbers, and other data types, and to be able to specify the inheritance relationships between standard documents and customized versions. SOX is a data description language built with XML and provides mechanisms for extending both the elements as well as user-defined data types, of which xCBL 2.0 can take full advantage. Additionally, once a standard W3C XML Schema Language has been approved, xCBL 2.0 will be reissued in that language. SOX, now in Version 2.0 can be retrieved form the W3C as a Note, but XSDL, the proposed W3C standard schema language, will probably replace SOX, Microsoft's XDR, and other XML schema languages in the future. As defined in the following sub-section, xCBL 2.0 will address error handling, wrapping and protocols.


4.4.2  Error Handling, Wrappers and Protocols
xCBL 2.0 is designed so that documents can be used with any type of "messaging" wrapper, and transported using any transport protocol, but there are two emerging standards that are worth noting. The first of these is Microsoft's BizTalk; the second is the IETF's XML Messaging standard. The designers of xCBL are actively working on both initiatives to guarantee alignment with both of these standards.

xCBL documents such as the Invoice and Purchase Order define the structure of the data in business terms. However, when sending xCBL documents to another party errors can occur. These can be divided into four categories:

Each type of error needs to be handled in different ways. For example, transport errors are a function of the transport mechanism or protocol being used to carry a document. This could be for example, a MIME message in a Web page, a BizTalk wrapper, an Internet Open Trading Protocol message, an E-Mail or potentially anything that can transport the document from one place to another. Each method of "transport" has a different error handling approach, which is one of the main reasons why xCBL documents do not contain transport specific data.

Document errors can be reported simply by pointing to the offending part of the document and using a code to define the nature of the problem. Probably a software problem needs to be fixed by either one way or other of the parties involved.

Technical server errors can require that messages are resent or some sort of recovery at a server is made. One should note that these types of server errors typically lie behind the "front end" server such as an HTTP server, so the server response is not the most helpful. However, there needs to be some method of communicating back to the sender of a document as to what can be done to recover from the error.

Finally, process problems need to indicate what sort of alternative business process the sender of the document might take to recover from the unsuccessful processing of the original document and achieve a satisfactory business outcome. The following subsection will address the design principles of xCBL 2.0.


4.4.3  Design Principles
xCBL 2.0 was designed to model the information requirements of business-to-business electronic commerce. A first step in this direction was the identification of a small set of core documents that could be used to conduct the majority of business transactions. xCBL 2.0 provides schemas to represent the following business documents:

· Purchase Order

· Purchase Order Response

· Order Status Request

· Order Status Result

· Availability Check Request

· Availability Check Result

· Price Check Request

· Price Check Result

· Invoice

· Product Catalog

· Pricing Catalog

  

 

Each of these documents is constructed from a set of modules - XML building blocks that represent name and address, price, unit of measure, and so forth. xCBL's extensible architecture allows trading partners to modify the business documents, adding elements as needed. The documents can support the business needs of both ad hoc trading communities and long-term enterprise trading relationships.

xCBL builds on information models from other sources, including the United Nations Standard Messages (UNSMs) in the international EDIFACT standard and the transaction sets of the U.S. X12 standard. Of course, with xCBL, XML syntax is used instead of EDIFACT or X12. Both the X12 transaction sets and EDIFACT messages have evolved over time to handle the information requirements of every conceivable business relationship. Because the standard messages contain vastly more information than typically necessary, trading partners generally exchange only a small subset of the messages, and xCBL 2.0 addresses the most important of these standard messages. In designing xCBL 2.0, two proposals for standard EDIFACT subsets were carefully studied:  EANCOM and SIMPL-EDI. Next, we will look at architectural principles.


4.4.4  Architectural Principles
It is fundamentally better to design document models that are not limited to a single method of transporting information between business partners. Unfortunately, many XML "standards" for electronic commerce are tightly coupled to HTTP. xCBL 2.0 will use the joint IETF/W3C digital signature standard to protect and insure the integrity of xCBL documents and data. This standard defines syntax and procedures for the computation, verification, and encoding of digital signatures using XML. Using this standard and xCBL 2.0 together will provide:

As a result it will be possible to send xCBL documents over insecure networks such as the Internet or via E-Mail without risk of them being altered.

xCBL 2.0 separates the contents of documents from information that specifies their routing or their role in document exchange. In contrast, EDI messages generally specify whether acknowledgments are expected, which documents are receiving a response, etc. xCBL transmits this type of information in the message header or message envelope.

Traditional XML modular architecture is followed with xCBL 2.0 with each business document having the following structure:

xCBL's modular structure allows businesses to use standard documents or to customize them by:

The simplest method of customizing a standard xCBL 2.0 document is to exploit a placeholder for "mutually defined" code lists that appear in many parts of xCBL 2.0. This allows a new code list or set of identifiers to be used instead of standard ones. This customization makes no changes to the schema for the document type, so any application that uses the standard XML instances could parse the customized instance without a problem and then pass the new value to the receiving application.

Documents can also be customized by the addition of attachments such as reports, design documents, or multimedia files. Because attachments use a pre-defined optional attachment element, they do not require changes to the document schema. Applications that expect standard instances are able to parse instances that point to attachments. Standard documents can be customized using schema extension capabilities of the XML schema language in which xCBL 2.0 is expressed. For example, a standard purchase order:

Can be extended to meet specialized accounting needs of the Department of Defense, shown as:

This allows the application code for handling the standard elements and structures to be reused. Applications that do not require this additional information can safely ignore it.

Every element and attribute in xCBL 2.0 has a "semantically meaningful" name consisting of one to four English words strung together without spaces. Each word begins with a capital letter. Many of the longest names are needed for attributes, which often are used to make narrow distinctions in