[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-cppa] CPPA 2.1 Transport changes for potential ebMS 3.0pull support
Dale, on the trnasport changes and your comment on canSend/canReceive, how do these changes map back to the process? If the naming is changed, presumably shouldn't we have to explain that an HTTP reply is a Request which maps back up to a business request in the process. As long as we can reasonably explain the glue between the process, configuration and messaging, I think this is an acceptable solution (as the process won't know about the underlying messaging infrastructure but the mapping is important). Thanks. Dale Moberg wrote: >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</Encry >ptionAlgorithm> > > </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</Encry >ptionAlgorithm> > > </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> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]