The sca jms binding spec also supports defining all that with the uri attribute doesn't it. The ws soap/jms uri format has been an evolving technique used for quite a while, and there is an attempt to standardized it, see : http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/[EMAIL PROTECTED]
...ant On 7/24/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 7/24/07, ant elder <[EMAIL PROTECTED]> wrote: > On 7/24/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > > > > Simon Laws wrote: > > > Has anyone in Tuscany made a binding that ships SOAP messages over > JMS > > > instead of HTTP? Looking at the current code base and at the old > code in > > > the > > > sandbox I don't see anything. > > > > > > Simon > > > > > > > Simon, > > > > Shouldn't this be a "simple" extension of the Web services binding? > > > > The interesting question is how to indicate that a JMS transport > should > > be used instead of HTTP. The spec only allows for this to be done via > > > WSDL at the moment - not so good if you didn't want to create the WSDL > > yourself. > > > > How about the idea of adding an intent for the Web services binding > > which can be used to indicate the transport?? > > > > eg: > > > > > > transport.http = use the HTTP transport (default) > > transport.jms = use the JMS transport > > transport.foo = use the foo transport.... > > > > The Web services binding can indicate which of these intents it > supports > > - since that depends on the support being available in the Web > > services stack that you are using. > > > Couldn't this just use the existing Axis2 facilities, the soap/jms uri > format and be done with the scdl binding uri attribute, eg: > > <binding.wsuri= > "jms:/dynamicTopics/something.TestTopic?transport.jms.ConnectionFactoryJNDIName=TopicConnectionFactory&java.naming.factory.initial= > > org.apache.activemq.jndi.ActiveMQInitialContextFactory&java.naming.provider.url=tcp://localhost:61616&java.naming.security.principal=system&java.naming.security.credentials=manager" > /> > > ...ant This provides a useable optional way of providing this information and a convenient way to start. It would seem a little odd, though, that the JMS binding lays all this out: * <binding.jms correlationScheme="string"? * initialContextFactory="xs:anyURI"? * jndiURL="xs:anyURI"? * requestConnection="QName"? * responseConnection="QName"? * operationProperties="QName"? * ...> * * <destination name="xs:anyURI" type="string"? create="string"?> * <property name="NMTOKEN" type="NMTOKEN">* * </destination>? * * <connectionFactory name="xs:anyURI" create="string"?> * <property name="NMTOKEN" type="NMTOKEN">* * </connectionFactory>? * * <activationSpec name="xs:anyURI" create="string"?> * <property name="NMTOKEN" type="NMTOKEN">* * </activationSpec>? * * <response> * <destination name="xs:anyURI" type="string"? create="string"?> * <property name="NMTOKEN" type="NMTOKEN">* * </destination>? * * <connectionFactory name="xs:anyURI" create="string"?> * <property name="NMTOKEN" type="NMTOKEN">* * </connectionFactory>? * * <activationSpec name="xs:anyURI" create="string"?> * <property name="NMTOKEN" type="NMTOKEN">* * </activationSpec>? * </response>? * * <resourceAdapter name="NMTOKEN">? * <property name="NMTOKEN" type="NMTOKEN">* * </resourceAdapter>? * * <headers JMSType="string"? * JMSCorrelationId="string"? * JMSDeliveryMode="string"? * JMSTimeToLive="int"? * JMSPriority="string"?> * <property name="NMTOKEN" type="NMTOKEN">* * </headers>? * * <operationProperties name="string" nativeOperation="string"?> * <property name="NMTOKEN" type="NMTOKEN">* * <headers JMSType="string"? * JMSCorrelationId="string"? * JMSDeliveryMode="string"? * JMSTimeToLive="int"? * JMSPriority="string"?> * <property name="NMTOKEN" type="NMTOKEN">* * </headers>? * </operationProperties>* * </binding.jms> if the only way to provide it for SOAP/JMS is through the URI. Simon
