You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2006/03/08 18:06:30 UTC
Mapping WSDL operation names to Java method names (JIRA issue TUSCANY-8)
JIRA issue TUSCANY-8 raises the issue of mapping WSDL operation names to
Java method names.
Let's imagine a scenario with an SCA entry point. The entry point uses a
WSDL service definition and a Web Service binding to publish a POJO
component. The POJO component implements a Java interface. This is a
top-down scenario where you start with the WSDL file describing the Web
Service (let's say it's a standard WSDL, or you have agreed on that WSDL
with one of your business partners), and you try to write or generate
the corresponding Java interface for your POJO component. The problem is
that your WSDL operation names won't always translate nicely to nice
Java method names. You'll run into WSDL name to Java name mapping issues
in a number of cases, for example:
- WSDL operation "GetQuote" -> do u map that to a getQuote method? or to
a GetQuote method (which doesn't follow the Java naming best practices)
- WSDL operation "get-quote" -> you need to map this to a valid Java
method name without the '-' like getQuote
- WSDL operation "continue" or "import" -> these are Java keywords so
again you can't just use the operation name as your method name.
We could come up with a name mangling algorithm but I don't really like
that. If we generate the interface we'll end up with ugly names for
these cases, if I'm an app developer and I want to write the interface
by hand I'll have to understand the name mangling algorithm and compute
the mangled name in my head. Such an algorithm may also cause
ambiguities / undeterministic behavior (if for example we look for both
getQuote and GetQuote Java methods for a GetQuote WSDL operation).
Instead of doing that I'd like to propose the following:
- a one-to-one mapping to cover all the cases that do not cause this
issue (i.e. a getQuote WSDL operation simply maps to a getQuote method)
- the use of annotations to define the WSDL to Java mapping, we would
allow you to annotate a WSDL operation with an XML element to drive the
generation of a Java method with the name you want (this is similar to
what SDO does with its commonj.sdo/java annotations)
- the use of Java 5 annotations to indicate which WSDL operation a given
Java method maps to.
The same principles would also apply to the WSDL portType name to Java
interface name mapping (which presents very similar issues).
Any thoughts?
--
Jean-Sebastien
Re: Mapping WSDL operation names to Java method names (JIRA issue
TUSCANY-8)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> ant elder wrote:
>> For most cases using annotations to define this mapping seems like a
>> great
>> idea to me...except for this operation names starting with an uppercase
>> character problem.
>>
>> WSDL with operation names starting with a capital letter is really
>> common
>> (.Net default?), but a Java method starting with an uppercase
>> character is
>> wrong. I think Tuscany should treat this as a special case and map
>> to the
>> method name seamlessly. The SEI class being used may have been hand
>> coded or
>> gen'd by some other tooling so it may not have an annotation. It would
>> create a much better impression, especially for new Tuscany users, if
>> this
>> very common case just works. The only times this could break
>> something is if
>> there are two different operations with the same name except for the
>> case of
>> the 1st character, which must be pretty rare and then annotations
>> could be
>> used to fix it.
>>
>> Be good if some of you other WS PMCers lurking on this list could
>> comment on
>> this.
>>
>> ...ant
>>
>> On 3/8/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>>> JIRA issue TUSCANY-8 raises the issue of mapping WSDL operation
>>> names to
>>> Java method names.
>>>
>>> Let's imagine a scenario with an SCA entry point. The entry point
>>> uses a
>>> WSDL service definition and a Web Service binding to publish a POJO
>>> component. The POJO component implements a Java interface. This is a
>>> top-down scenario where you start with the WSDL file describing the Web
>>> Service (let's say it's a standard WSDL, or you have agreed on that
>>> WSDL
>>> with one of your business partners), and you try to write or generate
>>> the corresponding Java interface for your POJO component. The
>>> problem is
>>> that your WSDL operation names won't always translate nicely to nice
>>> Java method names. You'll run into WSDL name to Java name mapping
>>> issues
>>> in a number of cases, for example:
>>> - WSDL operation "GetQuote" -> do u map that to a getQuote method?
>>> or to
>>> a GetQuote method (which doesn't follow the Java naming best practices)
>>> - WSDL operation "get-quote" -> you need to map this to a valid Java
>>> method name without the '-' like getQuote
>>> - WSDL operation "continue" or "import" -> these are Java keywords so
>>> again you can't just use the operation name as your method name.
>>>
>>> We could come up with a name mangling algorithm but I don't really like
>>> that. If we generate the interface we'll end up with ugly names for
>>> these cases, if I'm an app developer and I want to write the interface
>>> by hand I'll have to understand the name mangling algorithm and compute
>>> the mangled name in my head. Such an algorithm may also cause
>>> ambiguities / undeterministic behavior (if for example we look for both
>>> getQuote and GetQuote Java methods for a GetQuote WSDL operation).
>>>
>>> Instead of doing that I'd like to propose the following:
>>> - a one-to-one mapping to cover all the cases that do not cause this
>>> issue (i.e. a getQuote WSDL operation simply maps to a getQuote method)
>>> - the use of annotations to define the WSDL to Java mapping, we would
>>> allow you to annotate a WSDL operation with an XML element to drive the
>>> generation of a Java method with the name you want (this is similar to
>>> what SDO does with its commonj.sdo/java annotations)
>>> - the use of Java 5 annotations to indicate which WSDL operation a
>>> given
>>> Java method maps to.
>>>
>>> The same principles would also apply to the WSDL portType name to Java
>>> interface name mapping (which presents very similar issues).
>>>
>>> Any thoughts?
>>>
>>> --
>>> Jean-Sebastien
>>>
>>>
>>>
>>
>>
> Ant,
>
> Good idea I'd like to see the opinions of people from the Axis2 team.
> How is this handled in Axis2?
>
I tried a number of operation names with WSDL2Java from Axis2 0.94. Here
is what it generates:
- operation getquote -> method getquote
- operation GetQuote -> method GetQuote
- operation GETQUOTE -> method GETQUOTE
- operation get-Quote -> method get-Quote -> compile error :)
- operation continue -> method continue -> compile error :)
So the Axis 2 WSDL2Java does not seem to do any name mangling at the moment.
--
Jean-Sebastien
Re: Mapping WSDL operation names to Java method names (JIRA issue
TUSCANY-8)
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> For most cases using annotations to define this mapping seems like a great
> idea to me...except for this operation names starting with an uppercase
> character problem.
>
> WSDL with operation names starting with a capital letter is really common
> (.Net default?), but a Java method starting with an uppercase character is
> wrong. I think Tuscany should treat this as a special case and map to the
> method name seamlessly. The SEI class being used may have been hand coded or
> gen'd by some other tooling so it may not have an annotation. It would
> create a much better impression, especially for new Tuscany users, if this
> very common case just works. The only times this could break something is if
> there are two different operations with the same name except for the case of
> the 1st character, which must be pretty rare and then annotations could be
> used to fix it.
>
> Be good if some of you other WS PMCers lurking on this list could comment on
> this.
>
> ...ant
>
> On 3/8/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
>> JIRA issue TUSCANY-8 raises the issue of mapping WSDL operation names to
>> Java method names.
>>
>> Let's imagine a scenario with an SCA entry point. The entry point uses a
>> WSDL service definition and a Web Service binding to publish a POJO
>> component. The POJO component implements a Java interface. This is a
>> top-down scenario where you start with the WSDL file describing the Web
>> Service (let's say it's a standard WSDL, or you have agreed on that WSDL
>> with one of your business partners), and you try to write or generate
>> the corresponding Java interface for your POJO component. The problem is
>> that your WSDL operation names won't always translate nicely to nice
>> Java method names. You'll run into WSDL name to Java name mapping issues
>> in a number of cases, for example:
>> - WSDL operation "GetQuote" -> do u map that to a getQuote method? or to
>> a GetQuote method (which doesn't follow the Java naming best practices)
>> - WSDL operation "get-quote" -> you need to map this to a valid Java
>> method name without the '-' like getQuote
>> - WSDL operation "continue" or "import" -> these are Java keywords so
>> again you can't just use the operation name as your method name.
>>
>> We could come up with a name mangling algorithm but I don't really like
>> that. If we generate the interface we'll end up with ugly names for
>> these cases, if I'm an app developer and I want to write the interface
>> by hand I'll have to understand the name mangling algorithm and compute
>> the mangled name in my head. Such an algorithm may also cause
>> ambiguities / undeterministic behavior (if for example we look for both
>> getQuote and GetQuote Java methods for a GetQuote WSDL operation).
>>
>> Instead of doing that I'd like to propose the following:
>> - a one-to-one mapping to cover all the cases that do not cause this
>> issue (i.e. a getQuote WSDL operation simply maps to a getQuote method)
>> - the use of annotations to define the WSDL to Java mapping, we would
>> allow you to annotate a WSDL operation with an XML element to drive the
>> generation of a Java method with the name you want (this is similar to
>> what SDO does with its commonj.sdo/java annotations)
>> - the use of Java 5 annotations to indicate which WSDL operation a given
>> Java method maps to.
>>
>> The same principles would also apply to the WSDL portType name to Java
>> interface name mapping (which presents very similar issues).
>>
>> Any thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
>>
>
>
Ant,
Good idea I'd like to see the opinions of people from the Axis2 team.
How is this handled in Axis2?
--
Jean-Sebastien
Re: Mapping WSDL operation names to Java method names (JIRA issue TUSCANY-8)
Posted by ant elder <an...@gmail.com>.
For most cases using annotations to define this mapping seems like a great
idea to me...except for this operation names starting with an uppercase
character problem.
WSDL with operation names starting with a capital letter is really common
(.Net default?), but a Java method starting with an uppercase character is
wrong. I think Tuscany should treat this as a special case and map to the
method name seamlessly. The SEI class being used may have been hand coded or
gen'd by some other tooling so it may not have an annotation. It would
create a much better impression, especially for new Tuscany users, if this
very common case just works. The only times this could break something is if
there are two different operations with the same name except for the case of
the 1st character, which must be pretty rare and then annotations could be
used to fix it.
Be good if some of you other WS PMCers lurking on this list could comment on
this.
...ant
On 3/8/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> JIRA issue TUSCANY-8 raises the issue of mapping WSDL operation names to
> Java method names.
>
> Let's imagine a scenario with an SCA entry point. The entry point uses a
> WSDL service definition and a Web Service binding to publish a POJO
> component. The POJO component implements a Java interface. This is a
> top-down scenario where you start with the WSDL file describing the Web
> Service (let's say it's a standard WSDL, or you have agreed on that WSDL
> with one of your business partners), and you try to write or generate
> the corresponding Java interface for your POJO component. The problem is
> that your WSDL operation names won't always translate nicely to nice
> Java method names. You'll run into WSDL name to Java name mapping issues
> in a number of cases, for example:
> - WSDL operation "GetQuote" -> do u map that to a getQuote method? or to
> a GetQuote method (which doesn't follow the Java naming best practices)
> - WSDL operation "get-quote" -> you need to map this to a valid Java
> method name without the '-' like getQuote
> - WSDL operation "continue" or "import" -> these are Java keywords so
> again you can't just use the operation name as your method name.
>
> We could come up with a name mangling algorithm but I don't really like
> that. If we generate the interface we'll end up with ugly names for
> these cases, if I'm an app developer and I want to write the interface
> by hand I'll have to understand the name mangling algorithm and compute
> the mangled name in my head. Such an algorithm may also cause
> ambiguities / undeterministic behavior (if for example we look for both
> getQuote and GetQuote Java methods for a GetQuote WSDL operation).
>
> Instead of doing that I'd like to propose the following:
> - a one-to-one mapping to cover all the cases that do not cause this
> issue (i.e. a getQuote WSDL operation simply maps to a getQuote method)
> - the use of annotations to define the WSDL to Java mapping, we would
> allow you to annotate a WSDL operation with an XML element to drive the
> generation of a Java method with the name you want (this is similar to
> what SDO does with its commonj.sdo/java annotations)
> - the use of Java 5 annotations to indicate which WSDL operation a given
> Java method maps to.
>
> The same principles would also apply to the WSDL portType name to Java
> interface name mapping (which presents very similar issues).
>
> Any thoughts?
>
> --
> Jean-Sebastien
>
>