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">

    <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>