cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bharath Ganesh" <bharathgan...@gmail.com>
Subject Re: Proposal -- removing irrelevent services from WSDL
Date Fri, 07 Nov 2008 10:09:32 GMT
+1.

I personally have seen this many times. Many operations in WSDL which don't
work. This will be a good feature I guess. May be we can have an option to
retain the old behavior.

On Fri, Nov 7, 2008 at 3:09 PM, Sergey Beryozkin <
sergey.beryozkin@progress.com> wrote:

> Hi
>
>
>> Okay, thanks.
>>
>> No particular opinion about the WSDL pruning proposal then?
>>
>
> IMHO it makes sense. If the endpoint exposes only one of many services
> described in a wsdl there seems to be no need in keeping the rest of them in
> a published wsdl. That said it might be a bit expensive to ensure the
> 'unused' services are stripped.
>
> Is there any other reason in yourself being proposing it, other thna in a
> published wsdl be verbose ? Say, a client code has issues figuring out which
> service definition to use or something like that ?
>
> One possible complication here is that one service might return references
> to transient services also defined in this wsdl. Say, Bank return WSA refs
> to Account services. There might be no direct link between these 2 services
> at a wsdl level so if a Bank endpoint is published and its published wsdl
> instance won't contain a definition for Account then it might cause some
> issues at a point when Account reference is used at a client side ? I'm not
> sure if it actually will, but it's something which may need to be looked
> at...
>
> Cheers, Sergey
>
>
>
>> Andrew.
>>
>>
>>
>> Andi Abes wrote:
>>
>>>
>>> The soapAction is the logical name of the operation - so CXF is very
>>> correct in not touching it.
>>> A good practice is not to use hostnames for it, but rather URI's that
>>> represent the logical purpose of the operation.
>>>
>>> The soap:address is obviously used to connect to the service, hence it
>>> must be updated.
>>>
>>>
>>>
>>>  -----Original Message-----
>>>> From: Andrew Clegg [mailto:andrew.clegg@gmail.com]
>>>> Sent: Thursday, November 06, 2008 6:56 AM
>>>> To: dev@cxf.apache.org
>>>> Subject: Proposal -- removing irrelevent services from WSDL
>>>>
>>>>
>>>> Hey folks,
>>>>
>>>> I have a WSDL-first project which contains several service
>>>>
>>> definitions,
>>>
>>>> each
>>>> with a separate binding to a separate port type.
>>>>
>>>> When I go to the 'services' page for the WAR in Tomcat, I get a bunch
>>>>
>>> of
>>>
>>>> links like:
>>>>
>>>> http://myserver:8080/MyWar/services/ServiceOne?wsdl
>>>>
>>>> http://myserver:8080/MyWar/services/ServiceTwo?wsdl
>>>>
>>>> etc.
>>>>
>>>> Exactly the same WSDL, but published to different URLs.
>>>>
>>>> What would be really neat is if CXF could trim out the unused
>>>>
>>> services,
>>>
>>>> bindings and port type definitions when it publishes the WSDL.
>>>>
>>>> I know it already does some editing as the soap:address location
>>>> attributes
>>>> are correct. Would the maintainers be interested in a patch to do this
>>>>
>>> if
>>>
>>>> I
>>>> volunteered? I *think* Axis2 does this, if I remember correctly, so
>>>>
>>> there
>>>
>>>> might be some usable code in there.
>>>>
>>>> Interestingly, I just noticed the soap:operation soapAction attributes
>>>>
>>> are
>>>
>>>> not updated the same way as soap:address is. They still have the
>>>>
>>> localhost
>>>
>>>> test URLs which I hardcoded into my WSDL. Is this intentional, or a
>>>>
>>> bug,
>>>
>>>> or
>>>> a sign I've misconfigured something? (Does anything even use this?)
>>>>
>>>> Andrew.
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>> http://www.nabble.com/Proposal----removing-
>>>
>>>> irrelevent-services-from-WSDL-tp20359717p20359717.html
>>>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>>
>> --
>> View this message in context:
>> http://www.nabble.com/Proposal----removing-irrelevent-services-from-WSDL-tp20359717p20376006.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>>
>

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