CPPA 2.1 Transport changes for potential ebMS 3.0 pull support

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

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>