EbXML - Revision history

Shawndouglas: /* History */ Fixed internal link

2014-08-28T23:19:11Z

History: Fixed internal link

← Older revision		Revision as of 23:19, 28 August 2014
Line 19:		Line 19:
	The OASIS technical committees and UN/CEFACT retained the responsibility for maintaining and advancing the above specifications. Note that while the ebXML standards adopted by ISO and OASIS seek to provide formal XML-enabled mechanisms that can be implemented directly, the ebXML architecture is based on concepts and methodologies that can be more broadly applied to allow practitioners to better implement e-business solutions.		The OASIS technical committees and UN/CEFACT retained the responsibility for maintaining and advancing the above specifications. Note that while the ebXML standards adopted by ISO and OASIS seek to provide formal XML-enabled mechanisms that can be implemented directly, the ebXML architecture is based on concepts and methodologies that can be more broadly applied to allow practitioners to better implement e-business solutions.

	In 2007, several public organizations were stated to have implemented ebXML standards, including the [[U.S. Centers for Disease Control and Prevention]] (CDC), the U.S. Department of Defense, The Port of Hong Kong, the government of Norway, and the government of Denmark.<ref name="KotokebXML"> {{cite web \|url=http://www.ebxmlforum.net/articles/Adoption%20of%20ebXML%20Hiding%20in%20Plain%20Sight.html \|title=Adoption of ebXML: Hiding in Plain Sight \|author=Kotok, Alan \|work=ebXML Forum \|date=February 2007 \|accessdate=28 August 2014}}</ref>		In 2007, several public organizations were stated to have implemented ebXML standards, including the [[Centers for Disease Control and Prevention\|U.S. Centers for Disease Control and Prevention]] (CDC), the U.S. Department of Defense, The Port of Hong Kong, the government of Norway, and the government of Denmark.<ref name="KotokebXML"> {{cite web \|url=http://www.ebxmlforum.net/articles/Adoption%20of%20ebXML%20Hiding%20in%20Plain%20Sight.html \|title=Adoption of ebXML: Hiding in Plain Sight \|author=Kotok, Alan \|work=ebXML Forum \|date=February 2007 \|accessdate=28 August 2014}}</ref>

	==Architecture==		==Architecture==

Shawndouglas: Updated content.

2014-08-28T23:18:32Z

Updated content.

← Older revision		Revision as of 23:18, 28 August 2014
Line 23:		Line 23:
	==Architecture==		==Architecture==

	== ~~Collaborative Partner Profile Agreement~~ ==		===Collaboration-protocol profile and agreement===
	~~Collaborative Partner Profile Agreements are~~ [[XML]] based documents ~~specifying~~ a trading agreement between trading partners.		The ebCPP is composed of two elements: the profile and the agreement. These [[XML]]-based documents specify a trading agreement between trading partners. Each trading partner will have their own profile that describes their abilities, including the messaging protocols or security capabilities they support. The agreement is the intersection of the two profile documents, and it describes the formal relationship between the two parties.<ref name="15000-1" />
	Each trading partner will have their own ~~Collaboration Protocol Profile (CPP) document~~ that describes their abilities ~~in an XML format. For instance~~, ~~this can include~~ the messaging protocols ~~they support,~~ or ~~the~~ security capabilities they support.
	~~A CPA (Collaboration Protocol Agreement) document~~ is the intersection of two ~~CPP~~ documents, and describes the formal relationship between two parties. ~~The following information will typically be contained in a CPA document:~~
	*Identification information: the unique identifiers for each party and their roles within the trading relationship
	*Security information: for instance, are digital signatures required, and what algorithms do they use & communication information: the protocols that will be used when exchanging documents
	*Endpoint locations: the URL, service and action messages should be sent to
	*Rules to follow when acknowledgments are not received for messages, including how long to wait before resending, and how many times to resend
	*Whether duplicate messages should be ignored
	*Whether acknowledgments are required for all messages

	==~~Messaging Service Specification~~==		===Message service specification===
	The ~~Message Service Specification (~~ebMS) describes a communication-neutral mechanism ~~Message Service Handlers~~ (~~MSH~~) must implement in order to exchange business documents. ~~ebMS3.0 is the current version of the specification.~~		The ebMS describes a communication-neutral mechanism that message service handlers (MSHs) must implement in order to exchange business documents. ebMS is built as an extension on top of the [[SOAP]] with Attachments specification. The SOAP message contains the meta-data required to exchange the business document in a secure and reliable manner, while the business payload is attached to the SOAP message. Multiple business payloads may be attached to a single message. ebMS is neutral in communication protocol, although the most common underlying protocols are HTTP and SMTP.<ref name="15000-2" />
	~~ebMS3.0~~ is built as an extension on top of the [[SOAP with Attachments]] specification. The [[SOAP]] message contains the meta-data required to exchange the business document in a secure and reliable manner, while the business payload is attached to the [[SOAP]] message. Multiple business payloads may be attached to a single message~~, and the format of the payloads is beyond the scope of the ebXML specifications~~.
	~~The information trading partners place in~~ ebMS ~~messages~~ is ~~largely dictated by~~ the ~~CPA agreement that defines the relationship between them~~. ~~The following information is typically contained within ebMS messages:~~
	*Unique message id
	*Who the message is for
	*Who sent the message
	*A conversation id for linking related messages
	*A digital signature based on the [[XML Signature]] specification
	*An indication for whether duplicate messages should be ignored
	*An indication for whether acknowledgments are required

	~~ebMS~~ is ~~communication protocol neutral~~, ~~although~~ the ~~most~~ common ~~underlying protocols are [[HTTP]]~~ and [~~[SMTP]~~].		===Registry information model specification===
			The ebRIM defines the ebXML registry's information model. The registry "describes objects that reside in a repository for storage and safekeeping ...[but] does not deal with the actual content of the repository."<ref name="15000-3" /> The objects are described as metadata, which is then organized into metadata classes. The registry is then implemented as either a SOAP binding using HTTP or as an ebXML messaging service binding.<ref name="15000-3" />

			===Registry services specification===
			The ebRS defines not only the interface between the registry and its associated clients but also the protocols used during interface, the message definitions, and the associated XML design. The ebRS also acts as the core repository of definitions for future registry requirements. The registry itself enables the transmission of information between involved parties and allows tighter business process integration as a result.<ref name="15000-4" />

			===Core components technical specification===
			The ebCCTS is an evolving specification that originally was viewed as a spec that

			<blockquote>presents a methodology for developing a common set of semantic building blocks that represent the general types of business data in use today and provides for the creation of new business vocabularies and restructuring of existing business vocabularies. It provides a way to identify, capture and maximize the re-use of business information to support and enhance information interoperability across multiple business situations.<ref name="CoverCCTS">{{cite web \|url=http://xml.coverpages.org/ni2004-10-29-b.html \|title=Digital Artefacts Europe Contributes Open Source Implementation for ebXML Core Components \|work=Cover Pages \|author=Cover, Robin \|date=29 October 2004 \|accessdate=28 August 2014}}</ref></blockquote>

			This specification set the standard for OASIS' Universal Business Language (UBL), a library of standard electronic XML business documents.<ref name="OASISConfoUBL">{{cite web \|url=http://docs.oasis-open.org/ubl/UBL-conformance-to-CCTS/v1.0/cn01/UBL-conformance-to-CCTS-v1.0-cn01.html \|title=UBL Conformance to ebXML CCTS ISO/TS 15000-5:2005 Version 1.0 \|publisher=OASIS \|author=OASIS Universal Business Language TC \|date=08 May 2014 \|accessdate=28 August 2014}}</ref>

			==Notes==
			This article reuses numerous content elements from [http://en.wikipedia.org/wiki/ebXML the Wikipedia article].

	==External links==		==External links==
Line 53:		Line 50:
	* [http://ebxml.xml.org/ ebXML online community]		* [http://ebxml.xml.org/ ebXML online community]
	* [http://xml.coverpages.org/ebXML.html ebXML at Cover Pages]		* [http://xml.coverpages.org/ebXML.html ebXML at Cover Pages]


	==References==		==References==
	<references />		<references />

			<!---Place all category tags here-->
			[[Category:Software and hardware terms]]

Shawndouglas: Fixed ref.

2014-08-28T21:37:27Z

Fixed ref.

← Older revision		Revision as of 21:37, 28 August 2014
Line 19:		Line 19:
	The OASIS technical committees and UN/CEFACT retained the responsibility for maintaining and advancing the above specifications. Note that while the ebXML standards adopted by ISO and OASIS seek to provide formal XML-enabled mechanisms that can be implemented directly, the ebXML architecture is based on concepts and methodologies that can be more broadly applied to allow practitioners to better implement e-business solutions.		The OASIS technical committees and UN/CEFACT retained the responsibility for maintaining and advancing the above specifications. Note that while the ebXML standards adopted by ISO and OASIS seek to provide formal XML-enabled mechanisms that can be implemented directly, the ebXML architecture is based on concepts and methodologies that can be more broadly applied to allow practitioners to better implement e-business solutions.

	In 2007, several public organizations were stated to have implemented ebXML standards, including the [[U.S. Centers for Disease Control and Prevention]] (CDC), the U.S. Department of Defense, The Port of Hong Kong, the government of Norway, and the government of Denmark.<ref name=""> {{cite web \|url=http://www.ebxmlforum.net/articles/Adoption%20of%20ebXML%20Hiding%20in%20Plain%20Sight.html		In 2007, several public organizations were stated to have implemented ebXML standards, including the [[U.S. Centers for Disease Control and Prevention]] (CDC), the U.S. Department of Defense, The Port of Hong Kong, the government of Norway, and the government of Denmark.<ref name="KotokebXML"> {{cite web \|url=http://www.ebxmlforum.net/articles/Adoption%20of%20ebXML%20Hiding%20in%20Plain%20Sight.html \|title=Adoption of ebXML: Hiding in Plain Sight \|author=Kotok, Alan \|work=ebXML Forum \|date=February 2007 \|accessdate=28 August 2014}}</ref>

	==Architecture==		==Architecture==

Shawndouglas: Created stub record. Saving and revising the rest a little later.

2014-08-28T21:34:48Z

Created stub record. Saving and revising the rest a little later.

New page

{{lowercase title}}
'''Electronic Business using eXtensible Markup Language''' (commonly known as '''ebXML''') is a family of [[XML]] based standards sponsored by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS). ebXML was created to provide an open, XML-based infrastructure that enables the global use of electronic business information in an interoperable, secure, and consistent manner by all trading partners. Standards bodies like the National Institute of Standards and Technology (NIST) and the World Wide Web Consortium (W3C) were also involved in the initial development.<ref name="ebXMLAbout">{{cite web |url=http://www.ebxml.org/geninfo.htm |title=About ebXML |publisher=OASIS Open |date=2006 |accessdate=28 August 2014}}</ref><ref name="IBMebXML">{{cite web |url=http://www.ibm.com/developerworks/library/x-ebxml/ |title=Understanding ebXML |author=Mertz, David |work=developerWorks |publisher=IBM |date=01 June 2001 |accessdate=28 August 2014}}</ref>

==History==
ebXML was started in November 1999 as a joint initiative between the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS). At that time, the groups viewed several roadblocks to allowing "anyone, anywhere to do business with anyone else"<ref name="ebXMLHist">{{cite web |url=http://www.ebxml.eu.org/about_ebxml.htm |title=About ebXML |publisher=European Committee for Standardization |date=03 February 2009 |accessdate=28 August 2014}}</ref>:

<blockquote>The ebXML initiative was conceived due to the widely held need to enable enterprises of any size and in any geographical location to conduct business electronically in a simple, cheap reliable way. There are technologies that currently exist to perform electronic trading, such as Electronic Data Interchange (EDI), (and it should be noted they perform this task very well) but they are often costly to implement, the information itself is not human readable and the these technologies often require the use of private, fee paying networks.</blockquote>

The group created a set of technical and business principles that guided their development during the core design phase of the project, including avoiding proprietary solutions and including multilingual support. The core project also envisioned five layers of data specification, including XML standards for business processes, core data components, collaboration protocol agreements, messaging tools, and registries and repositories.<ref name="ebXMLAbout" /> The core part of the project was completed in May 2001, laying out the architecture and base standards. After the core work was completed, the two organizations agreed to split further development responsibilities for the various specifications but continued oversight through the group's Joint Coordination Committee (JCC).<ref name="ebXMLHist" /><ref name="ebXMLProj">{{cite web |url=http://www.ebxml.eu.org/the_ebxml_initiative.htm |title=The ebXML Project |publisher=European Committee for Standardization |date=03 February 2009 |accessdate=28 August 2014}}</ref>

After completion of the specifications by the two organizations, five portions of the work were submitted to the [[International Organization for Standardization]] (ISO) Technical Committee 154 for approval. The ISO approved the following five ebXML specifications as the ISO 15000 standard, under the general title Electronic Business Extensible Markup Language (ebXML). The first four were approved in 2004<ref name="15000App04">{{cite web |url=http://searchsoa.techtarget.com/news/958429/OASIS-ISO-approval-may-spark-ebXML-critical-mass |title=OASIS: ISO approval may spark ebXML critical mass |author=Mimoso, Michael S |work=SearchSOA |publisher=TechCrunch |date=06 April 2004 |accessdate=28 August 2014}}</ref>, with the fifth, the CCTS, realizing approval in 2005:

* ISO/TS 15000-1:2004: Collaboration-protocol profile and agreement specification (ebCPP)<ref name="15000-1">{{cite web |url=http://www.isotc154.org/standards/isots-15000-12004 |title=ISO/TS 15000-1:2004 |publisher=International Organization for Standardization |accessdate=28 August 2014}}</ref>
* ISO/TS 15000-2:2004: Message service specification (ebMS)<ref name="15000-2">{{cite web |url=http://www.isotc154.org/standards/isots-15000-22004 |title=ISO/TS 15000-2:2004 |publisher=International Organization for Standardization |accessdate=28 August 2014}}</ref>
* ISO/TS 15000-3:2004: Registry information model specification (ebRIM)<ref name="15000-3">{{cite web |url=http://www.isotc154.org/standards/isots-15000-32004 |title=ISO/TS 15000-3:2004 |publisher=International Organization for Standardization |accessdate=28 August 2014}}</ref>
* ISO/TS 15000-4:2004: Registry services specification (ebRS)<ref name="15000-4">{{cite web |url=http://www.isotc154.org/standards/isots-15000-42004 |title=ISO/TS 15000-4:2004 |publisher=International Organization for Standardization |accessdate=28 August 2014}}</ref>
* ISO/TS 15000-5:2005: ebXML Core Components Technical Specification, Version 2.01 (ebCCTS)<ref name="15000-5">{{cite web |url=http://www.isotc154.org/standards/isots-15000-52005 |title=ISO/TS 15000-5:2005 |publisher=International Organization for Standardization |accessdate=28 August 2014}}</ref>

The OASIS technical committees and UN/CEFACT retained the responsibility for maintaining and advancing the above specifications. Note that while the ebXML standards adopted by ISO and OASIS seek to provide formal XML-enabled mechanisms that can be implemented directly, the ebXML architecture is based on concepts and methodologies that can be more broadly applied to allow practitioners to better implement e-business solutions.

In 2007, several public organizations were stated to have implemented ebXML standards, including the [[U.S. Centers for Disease Control and Prevention]] (CDC), the U.S. Department of Defense, The Port of Hong Kong, the government of Norway, and the government of Denmark.<ref name=""> {{cite web |url=http://www.ebxmlforum.net/articles/Adoption%20of%20ebXML%20Hiding%20in%20Plain%20Sight.html

==Architecture==

== Collaborative Partner Profile Agreement ==
Collaborative Partner Profile Agreements are [[XML]] based documents specifying a trading agreement between trading partners.
Each trading partner will have their own Collaboration Protocol Profile (CPP) document that describes their abilities in an XML format. For instance, this can include the messaging protocols they support, or the security capabilities they support.
A CPA (Collaboration Protocol Agreement) document is the intersection of two CPP documents, and describes the formal relationship between two parties. The following information will typically be contained in a CPA document:
*Identification information: the unique identifiers for each party and their roles within the trading relationship
*Security information: for instance, are digital signatures required, and what algorithms do they use & communication information: the protocols that will be used when exchanging documents
*Endpoint locations: the URL, service and action messages should be sent to
*Rules to follow when acknowledgments are not received for messages, including how long to wait before resending, and how many times to resend
*Whether duplicate messages should be ignored
*Whether acknowledgments are required for all messages

==Messaging Service Specification==
The Message Service Specification (ebMS) describes a communication-neutral mechanism Message Service Handlers (MSH) must implement in order to exchange business documents. ebMS3.0 is the current version of the specification.
ebMS3.0 is built as an extension on top of the [[SOAP with Attachments]] specification. The [[SOAP]] message contains the meta-data required to exchange the business document in a secure and reliable manner, while the business payload is attached to the [[SOAP]] message. Multiple business payloads may be attached to a single message, and the format of the payloads is beyond the scope of the ebXML specifications.
The information trading partners place in ebMS messages is largely dictated by the CPA agreement that defines the relationship between them. The following information is typically contained within ebMS messages:
*Unique message id
*Who the message is for
*Who sent the message
*A conversation id for linking related messages
*A digital signature based on the [[XML Signature]] specification
*An indication for whether duplicate messages should be ignored
*An indication for whether acknowledgments are required

ebMS is communication protocol neutral, although the most common underlying protocols are [[HTTP]] and [[SMTP]].

==External links==
* [http://www.ebxml.org/ ebXML]
* [http://www.ebxml.eu.org/default.htm ebXML Europe]
* [http://ebxml.xml.org/ ebXML online community]
* [http://xml.coverpages.org/ebXML.html ebXML at Cover Pages]

==References==
<references />