One Side Initiate Only Channel Requirements
AIAG Message Routing Work Group
Draft V0.4, February 14, 2002

Revision History
Version	Date	Who	What	
V0.3	1/16/02	Chuck Fenton	Initial Draft	
V0.4	2/18/02	Chuck Fenton	Changed sideOnly to transientChannel and filled in some detail BPSS and solve need.	

Abstract
AIAG has published the E5 2000 Guideline for Electronic Commerce Message Routing On TCP/IP Networks.  The E5 2000 guideline and the preceding version are in use in the automotive supply chain.  E5 describes a protocol for HTTP messaging including support for one side initiate only channel operations.   The current ebXML messaging framework for HTTP is peer-to-peer channels, which limits adoption in the automotive supply chain.
This paper describes one side initiate only delivery channel requirements and suggestions as to how this may be achieved in the ebXML message framework.
Terminology
The terms used in this document are defined as follows:
Term	Definition and Characteristics	
Initiate only	Can only initiate a call to a responder.  Can collaborate once the responder accepts a call.  May or may not have a permanent Internet connection or IP address (URI). 	
Response only	Can only response to an external initiated call.  Cannot initiate a call.  Can collaborate once a call is accepted from the initiator.  Will normally have a permanent Internet connection and IP address (URI).	
Peer-to-peer	Both parties in a call or conversation have the same capability.  Both support initiation and response.  One or both have permanent Internet connections and IP addresses (URI).	
Background
E5 was developed as a routing and packaging protocol by the AIAG Message Routing Work Group.  E5 version 1 borrowed heavily from Gas Industry Standards Board EDM. E5 version 2 (2000) builds on version 1, implementing XML meta-data and segregating operation between machine and human operation.  E5 supports both one side initiate only, and peer-to-peer implementation and operation.  
E5 supports the messaging requirements across the spectrum of the automotive supply chain, from the very smallest to the very largest organization.  ebXML began as an initiative to meet the needs of small and medium organizations.  A small organization does not have the sophistication or requirements of a large organization; consequently a small organization should not have to implement the same peer level message infrastructure that a large organization does.  E5 2000 achieves this by allowing any organization to operate in initiate only mode with another organization that operates in response only mode.  The fact they agree to operate in this fashion is a defacto Collaboration Protocol Agreement.  
E5 2000 defines a limited set of verbs.
Verb	Action	
Deliver	Deliver a document	
Obtain	Obtain a document.  This includes facilities to specify the characteristics of the document(s) to obtain.	
Acknowledge	Acknowledge the receipt of a document	
API Definition	Request a document describing the facilities that implement the other verbs.	
Loopback	Do a delivery loop back on a document.	
This set of verbs is sufficient for one side initiate only mode operations.  More detail may be found in the E5 2000 specification.
General Use Case
Actors
Buyer – Large upper tier conglomerate
Seller – Small lower tier supplier
Pre-conditions
Buyer desires to automate messaging with Seller.  Seller has little sophistication and no ability or interest in absorbing cost of additional infrastructure.  Seller is not permanently connected to IP services (no URI).  Seller has dial up capability to a private VPN where the Buyer has a permanent host server.
Events
1.	Seller dials up VPN and connects to Buyer’s server
2.	Seller delivers messages to Buyer.
3.	Seller obtains messages from Buyer.
4.	Seller disconnects.
Discussion
The above use case is overly general and simplistic, but that is the point of it.  The real issue is the Seller is transient, and must take initiative with the Buyer.  The Buyer has no facility to initiate a call to the Seller, because the Seller doesn’t support it.  It is not a peer-to-peer relationship at the infrastructure level.  The business process agreed to by both parties allows this type of operation.  
There is nothing said about the degree of sophistication of the B2B message/process collaboration.  It is only as sophisticated as it needs to be.  The typical limited information content to and from the Seller doesn’t warrant sophisticated B2B integration on the Sellers end.  
ebXML has sufficient latitude to support a one side initiate only implementation in the messaging/process framework.   The following section offers some suggestions as to how this may be achieved.
Suggestions - ebXML Framework
ebXML is an evolving framework for B2B collaboration.  The appropriate components of the framework should be augmented to properly implement one side initiate only channel operations.  At first blush this may seem to be Messaging Services (MS), but MS does not stand-alone, it operates based on Collaboration Protocol Agreement (CPA).   
The following offers details on the Delivery Channel and a proposed addition.
Delivery Channel
Delivery Channel is defined in the Collaboration-Protocol Profile and Agreement Specification (Draft Version 1.07 section 8.5.20).  In operation, the agreement between two organizations (the CPA) includes a service binding to specific delivery channels.  The delivery channel has specific business transaction characteristics as seen in the excerpts from the CPP-CPA schema:
<element name="BusinessTransactionCharacteristics">
		<complexType>
			<attribute name="isNonRepudiationRequired" type="boolean"/>
			<attribute name="isNonRepudiationReceiptRequired" type="boolean"/>
			<attribute name="isSecureTransportRequired" type="boolean"/>
			<attribute name="isConfidential" type="tns:persistenceLevel.type"/>
			<attribute name="isAuthenticated" type="tns:persistenceLevel.type"/>
			<attribute name="isTamperProof" type="tns:persistenceLevel.type"/>
			<attribute name="isAuthorizationRequired" type="boolean"/>
			<attribute name="isIntelligibleCheckRequired" type="boolean"/>
			<attribute name="timeToAcknowledgeReceipt" type="duration"/>
			<attribute name="timeToAcknowledgeAcceptance" type="duration"/>
			<attribute name="timeToPerform" type="duration"/>
		</complexType>
	</element>

Proposed Attribute: transientChannel
A new attribute could be added to the above BusinessTransactionCharacteristics with the following description:
<attribute name="transientChannel" default=”none”/>
<simpleType >
		<restriction base="NMTOKEN">
			<enumeration value="initiateOnly"/>
			<enumeration value="respondOnly"/>
			<enumeration value="none"/>
		</restriction>
</simpleType>
</attribute>

This would augment the characteristics to permit a distinction between initiate only and respond only side channels.  The default=’none’ would be operationally consistent with previous peer-to-peer versions.
Normal negotiation of the CPA would line up the service bindings necessary on each side.  In all likelihood the Buyer in the above use case would publish a template CPA that would contain the all the appropriate details save for a few Seller specific elements.
Other Impact
There are other elements in the CPP-CPA schema that would need modification as regards URIs that make no sense on a transport because they don’t or can’t exist: initiate only side.
Why Not on the Transport?
Because, as in the above use case the Seller could only initiate, the transport type was immaterial.  There could be any number of transports that could be used by the Seller, but for each and every one, the Seller initiates the business process.
Business Process
The ebBPSS schema is may be used to define some the above listed elements in the BusinessTransactionCharacteristics element.  It may be valuable to include the same addition in the ebBPSS schema with appropriate description because it influences the business process.  A possible location would be in the RequestBusinessActivity and RespondingBusinessActivity elements.
The business process that could make use of a transientChannel would have to be defined by the user community.  Details about the process, services, actions, etc. would be left to their choice and definition, as stipulated by the ebXML specifications.

Solve Need
1.	This addition to the schema addresses the requirements of the small and medium organizations that are not at a true peer-to-peer operating level with other trading partners.  
2.	It would allow developers to create solutions that scale across a broader range of industry with out making serious changes to the scope of the messaging framework.
3.	It retains and augments the intent of the BPSS and CPP/CPA for channel and transport declaration, negotiation and agreement.