RE: [ebxml-msg] CPPA 2.1 Transport changes for potential ebMS 3.0 pull s

Dale:

A few comments:

1. About the "mep hint" :

- we might use a lower-level concept closer to transport than ebMS MEPs that could do the same hint job. It might just look like a renaming issue, but I'd avoid lowering ebMS concepts such as MEPs down to the transport level: it seems that ebMS mep info would be more appropriately associated with higher level CPA layers like Delivery channel - or maybe doc exchange info ?

- At transport level, that could work like this: it is sufficient to know which of the TransportSender or TransportReceiver can initiate an exchange, in order to determine what ebMS MEPs can be run over this transport. An "initiator" attribute (true/false) of the TransportProtocol element of a TransportReceiver might just do that. If "true", it would tell that the transport can run ebMS One-way Pull, as well as more complex MEPs that include Pulling. But that depends indeed on how this transport is used (by which Delivery Channel), which does not have to be known or assumed, when defining TransportProtocol.

- (note: for sake of generalization, shouldn't the "method" be an unbounded child element instead of just an attribute? If the case, the "initiator" attribute could be associated to it, meaning that the party can actually generate the method, not just receive it.)

2. Endpoint in TransportReceiver: this one should probably have minOccurs="0" like for Sender, because the case where some Receiver has no endpoint address, now makes sense with Pulling.

Cheers,

Jacques

From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Monday, September 12, 2005 10:36 AM
To: ebxml-msg@lists.oasis-open.org
Cc: ebxml-cppa@lists.oasis-open.org
Subject: [ebxml-msg] CPPA 2.1 Transport changes for potential ebMS 3.0 pull support

The message receiver (who is the Pull initiator) would have a Transport element something like

<Transport transportId='ID2005' xmlns="http://docs.oasis-open.org/ebxmlcppa/cppa-2.1.xsd"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://docs.oasis-open.org/ebxmlcppa/cppa-2.1.xsd file:/C:/cppa-2.1-sep-15-2005.xsd">

<TransportProtocol version="1.0" mep="ebMS-Pull" method="POST">HTTPS</TransportProtocol>

<AccessAuthentication>basic</AccessAuthentication>

</TransportServerSecurity>

</TransportReceiver>

</Transport>

The @mep and @method attributes are newly added to the cppa namespace. It seems advisable to add more hints about how HTTP is being used to transfer the business data. Of course, the @mep value can be specified as a URI. [WSDL and SOAP already have URI identifiers for MEPs, for example] It seems like @mep seems to be useful to add in addition to @method (which will mainly apply to FTP or HTTP methods). Allowing an endpoint in the Sender is something new, and requires a schema change. In addition, the CanSend/CanReceive elements would presumably be structured to indicate that one message is sent. No current value of synchReply mode fits ebMS very well at present; possibly a new value is needed for this case. CPPA group should consider.

(It is a Request, not a Response, that is being sent on the HTTP reply.)

[The ID values are selected to trick the validater, btw.]

The message sender could have a Transport element like

<AccessAuthentication>basic</AccessAuthentication>

</TransportServerSecurity>

</TransportSender>

</Transport>

Here are some changes in the editor's draft of the 2.1 schema that would accommodate the above changes.

<!-- Added the choice about TransportSecurity to allow Sender to have Server security.

Also added an optional Endpoint for Sender which was not allowed previously for the business data Sender -->

<xsd:complexType name="TransportSenderType">

<xsd:complexContent>

<xsd:extension base="tns:TransportUserType">

<xsd:sequence>

<xsd:element name="TransportProtocol" type="tns:protocolType"/>

<xsd:element ref="tns:AccessAuthentication" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="tns:Endpoint" minOccurs="0" maxOccurs="unbounded"/>

<xsd:choice minOccurs="0">

<xsd:element ref="tns:TransportClientSecurity" minOccurs="0"/>

<xsd:element ref="tns:TransportServerSecurity" minOccurs="0"/>

</xsd:choice>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:element name="TransportReceiver" type="tns:TransportReceiverType"

substitutionGroup="tns:TransportUserHead"/>

<xsd:complexType name="TransportReceiverType">

<xsd:complexContent>

<xsd:extension base="tns:TransportUserType">

<xsd:sequence>

<xsd:element name="TransportProtocol" type="tns:protocolType"/>

<xsd:element ref="tns:AccessAuthentication" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="tns:Endpoint" maxOccurs="unbounded"/>

<xsd:choice minOccurs="0">

<xsd:element ref="tns:TransportClientSecurity" minOccurs="0"/>

<xsd:element ref="tns:TransportServerSecurity" minOccurs="0"/>

</xsd:choice>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="protocolType">

<xsd:simpleContent>

<xsd:extension base="tns:non-empty-string">

<xsd:attribute name="version" type="tns:non-empty-string" use="required"/>

<xsd:attribute name="method" type="tns:non-empty-string" use="optional"/>

<xsd:attribute name="mep" type="tns:non-empty-string" use="optional"/>

<xsd:anyAttribute namespace="##any" processContents="lax"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

ebxml-msg message