cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Retzlaff" <dretzl...@gmail.com>
Subject Re: Invalid WSDL for SOAP over JMS
Date Thu, 10 Jul 2008 01:01:16 GMT
If I knew how to vote, I'd +1 the proposal. For now I'll continue to ignore
my WSDL editor's complaints. Thanks.

On Wed, Jul 9, 2008 at 1:28 PM, Daniel Kulp <dkulp@apache.org> wrote:

>  "go away and be happy with what you have"
>>
>
> :-)
>
> Seriously,  that's an interesting catch.   This syntax basically comes from
> IONA's commercial products which have been doing it this way for YEARS (like
> 2001 or so).  You're the first to catch that it's invalid.   Nice job.
>
> As part of the discussion for 2.2 features, updating the JMS transport was
> brought up.   One of the things we'd like to do is get it to implement the
> proposed spec:
> http://www.w3.org/Submission/SOAPJMS/
>
>
> Dan
>
>
>
>
> On Jul 9, 2008, at 3:45 PM, Dan Retzlaff wrote:
>
>  Right, this is still a SOAP binding since the first element of
>> <wsdl:binding/> is <soap:binding/>, and what goes over the wire is wrapped
>> in a SOAP envelope. It's the binding's transport that is JMS.
>>
>> By analogy, the WSDL spec includes this example for SOAP over SMTP:
>>
>>   <wsdl:binding name="StockQuoteSoap" type="tns:StockQuotePortType">
>>
>>>       <soap:binding style="document" transport="http://example.com/smtp
>>> "/>
>>>
>>>
>> I can see why CXF was done it this way. The WSDL spec does not allow the
>> SOAP binding to have any extensibility elements:
>>
>> <schema xmlns="http://www.w3.org/2000/10/XMLSchema"
>>
>>>       xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>>>       targetNamespace="http://schemas.xmlsoap.org/wsdl/soap/">
>>>  ...
>>>  <element name="address" type="soap:addressType"/>
>>>  <complexType name="addressType">
>>>     <attribute name="location" type="uriReference" use="required"/>
>>>  </complexType>
>>>
>>>
>> And apparently CXF requires additional stuff like "destinationStyle" and
>> "jndiConnectionFactoryName". So I guess the question is whether this
>> non-compliance is intentional. Any insight or guidance, including "go away
>> and be happy with what you have" is appreciated. :)
>>
>> Dan
>>
>> On Wed, Jul 9, 2008 at 12:11 PM, Glen Mazza <glen.mazza@gmail.com> wrote:
>>
>>
>>> Oops--this is SOAP over JMS.  Never mind (I think).
>>>
>>>
>>> Glen Mazza wrote:
>>>
>>>>
>>>> I may be wrong here but that's just for the SOAP binding within WSDL
>>>> (which has other bindings, namely the HTTP one) A JMS binding with WSDL
>>>> would not be relevant for the SOAP-binding rule below then.
>>>>
>>>> Glen
>>>>
>>>>
>>>> Dan Retzlaff wrote:
>>>>
>>>>>
>>>>> The jms_queue and jms_pubsub samples configure their <wsdl:port/>s
with
>>>>>
>>>> a
>>>
>>>> <jms:address/> element instead of a <soap:address/> element.
This looks
>>>>> like
>>>>> the only way to get CXF's JMS transport to actually work, but I believe
>>>>> it's
>>>>> technically invalid. According to the WSDL spec at
>>>>> http://www.w3.org/TR/wsdl#_soap:address:
>>>>>
>>>>>  3.8 soap:address
>>>>>>
>>>>>> The SOAP address binding is used to give a port an address (a URI).
A
>>>>>> port
>>>>>> using the SOAP binding MUST specify exactly one address.  The URI
>>>>>>
>>>>> scheme
>>>
>>>> specified for the address must correspond to the transport specified by
>>>>>> the
>>>>>> soap:binding.
>>>>>>
>>>>>>  Is this discrepency worthy of a JIRA report? I'm guessing this
>>>>> URI-based
>>>>> transport specification isn't as easy to do with the current
>>>>> implementation,
>>>>> but looking through the forum history, I'm not the first to be confused
>>>>> by
>>>>> this. In my case XMLSpy complains every time I try to validate my
>>>>> CXF-compatible WSDLs.
>>>>>
>>>>> Regards,
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> View this message in context:
>>>
>>> http://www.nabble.com/Invalid-WSDL-for-SOAP-over-JMS-tp18367273p18368644.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>>
>>>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message