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
>
>
>
>
>
>
--
View this message in context:
http://www.nabble.com/Ideas-for-2.2-tp17985028p19556509.html
Sent from the cxf-dev mailing list archive at Nabble.com.
