Adrian,
The first step is to really get the JMS transport into a state where it's
easily configurable and more easy to maintain and extend. As part of this,
it's also being converted from using pure JMS calls to using the Spring JMS
stuff. Currently, Christian Schneider has been submitting some patches to
move us in that direction. That really needs to be done first. (he's
doing an excellent job though)
Once that is done, the SOAP-over-JMS specification should become a bit easier
to implement. But step one above needs to get done first.
Dan
On Thursday 18 September 2008 12:12:47 pm Adrian Trenaman wrote:
> I'd lie to see us supporting the SOAP-over-JMS specification: MTOSI (from
> TMF) has WSDLs with SOAP-over-JMS semantics, but as the spec isn't
> finalized yet they're using "made-up" transport url
> ("http://schemas.xmlsoap.org/soap/jms";) instead of the standardized
> "http://www.w3.org/2008/07/soap/bindings/JMS/";.
>
> Right now, I'm working with a customer who adds the custom CXF
> <jms:address> element to the port type to MTOSI WSDL. Clearly, that's not
> desirable, as it means they have to maintain their own modified copy of the
> MTOSI WSDL; further, this WSDL is incompatible with non-CXF client
> technologies.
>
> @Dan: do you know if anyone has started work on implementing this spec?
>
> dkulp wrote:
> > Regarding JMS, the other thing that probably needs to be done is
> > investigating the SOAP over JMS spec submitted at:
> > http://www.w3.org/Submission/SOAPJMS/
> > and seeing how well that can fit in.
> >
> > Dan
> >
> > On Jun 18, 2008, at 7:34 PM, Christian Schneider wrote:
> >> I would really like to see good osgi integration as we plan to rely
> >> quite heavily on osgi in the future. But as I myself are only
> >> starting on this I don´t know much about the details. Basically I
> >> would like to be able to connect the osgi internal services with
> >> cxf to communicate with the outside world. So a client should be
> >> able to simply use an osgi service. The provider of the service
> >> could then be simply a local bundle or a cxf based kind of binding
> >> component that does the remoting. I hope somthing like this will
> >> come from servicemix.
> >>
> >> For the short term the jms enhancements are my favourite.
> >> Configuring the jms destination and jms conduit is really non
> >> intuitive and it does not follow spring standard procedures.
> >> The most important thing for me is externalising the
> >> ConnectionFactory. This should be defined in a separate bean and
> >> only be referenced from conduit and destination. I think there are
> >> two main
> >> use cases here.
> >>
> >> 1. You want to define the ConnectionFactory yourself. In a spearate
> >> bean this will be easy
> >>
> >> 2. You want to fetch the factory from jndi. In this case I would
> >> like to use the spring jee extensions or again a simple bean
> >>
> >> <jee:jndi-lookup id="myConnectionFactory" jndi-
> >> name="my.connection.Factory"
> >> <jee:environment>
> >>
> >> java
> >> .naming.factory.initial=weblogic.jndi.WLInitialContextFactory
> >> java.naming.provider.url=tcp://localhost:10001
> >> </jee:environment> </jee:jndi-lookup>
> >>
> >> The last thing about jms is that I would like to be able to select
> >> the connection and configure the queue and other settings in the
> >> address of the service. I really like the way camel handles
> >> jms. Perhaps this can be done like in camel. So perhaps it is
> >> possible to not need the jms destination and jms conduit configs at
> >> all.
> >>
> >> Best regards
> >>
> >> Christian
> >>
> >> Daniel Kulp schrieb:
> >>> Now that 2.1.1 is being voted on, I'd like to step back a bit and
> >>> talk a little about ideas for the next versions.
> >>>
> >>> First, most likely, we'll need to do a 2.1.2 release in about 6-8
> >>> weeks (and maybe 2.0.8 as well). We've done a very good job of
> >>> getting fixes out to our users in a timely manner and I'd like to
> >>> keep that up, but I also would like to think about 2.2 a bit as
> >>> well. I haven't created the 2.1.x fixes branch yet, but I
> >>> probably will shortly if we start doing some new stuff toward 2.2.
> >>>
> >>> That said, here is my list of stuff that is "missing" and could be
> >>> considered for 2.2:
> >>>
> >>>
> >>> 5) OSGi stuff - I know there are some OSGi enhancements in the
> >>> works that could be pulled in:
> >>> a) osgi http transport - this currently lives in ServiceMix, but
> >>> could be pulled into CXF to work with other OSGi runtimes
> >>> b) Distributed OSGi (RFC 119) - there is work being done to
> >>> implement RFC 119 with CXF. There are some rules about releasing
> >>> the IP for this though that is being investigated.
> >>>
> >>> 6) JMS transport enhancements - I keep wanting to update this a bit
> >>> to leverage spring jms stuff a bit better to make it much easier to
> >>> configure.
> >>>
> >>>
> >>> Anyway, thoughts? Other ideas? Comments?
> >
> > ---
> > Daniel Kulp
> > [EMAIL PROTECTED]
> > http://www.dankulp.com/blog
--
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
