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">
<TransportReceiver>
<TransportProtocol version="1.0" mep="ebMS-Pull"
method="POST">HTTPS</TransportProtocol>
<AccessAuthentication>basic</AccessAuthentication>
<Endpoint
uri="https://www.example.com/path-to-identify-only"/>
<TransportServerSecurity>
<TransportSecurityProtocol
version="1.0">TLS</TransportSecurityProtocol>
<ServerCertificateRef certId="ID2005"/>
<ClientSecurityDetailsRef securityId="ID2005"/>
<EncryptionAlgorithm minimumStrength='168'
w3c="http://www.w3.org/2001/04/xmlenc#tripledes-cbc">des_EDE3_CBC</EncryptionAlgorithm>
</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
<Transport transportId='ID2005'>
<TransportSender>
<TransportProtocol version="1.0" method="HTTP-Response"
mep="ebMS-Pull">HTTP</TransportProtocol>
<AccessAuthentication>basic</AccessAuthentication>
<Endpoint
uri="http://www.example.com/message/queue101"/>
<TransportServerSecurity>
<TransportSecurityProtocol
version="1.0">TLS</TransportSecurityProtocol>
<ServerCertificateRef certId="ID2005"/>
<ClientSecurityDetailsRef securityId="ID2005"/>
<EncryptionAlgorithm minimumStrength='168'
w3c="http://www.w3.org/2001/04/xmlenc#tripledes-cbc">des_EDE3_CBC</EncryptionAlgorithm>
</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>
<!-- added the choice about
TransportSecurity to allow Receiver to have client security -->
<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>
<!-- added @mep and @mep attributes
explicitly did not get an ambiguous grammar complaint so far. -->
<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>