You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Nash <na...@apache.org> on 2008/04/02 16:31:50 UTC
JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
I'd like to restart the discussion on supporting JAX-WS annotations
for the Java-to-WSDL mapping. This is needed to fix TUSCANY-2033,
and has been the subject of various user requests from time to time.
The scenario that I want to fix is a service with a Java interface
that was generated from WSDL by running the JAX-WS mapping (e.g.,
the wsimport tool from the JAX-WS RI). The generated service interface
and associated classes (e.g., exceptions, data objects) will have
JAX-WS and JAXB annotations that are equivalent to the information
contained in the WSDL.
The runtime processing for a Tuscany client talking to a Tuscany
service is as follows:
a. (client and service) Generate an equivalent WSDL interface from
the Java service interface and associated classes.
b. (client and service) Generate equivalent XSD types from the
Java service interface and associated classes.
c. (client and service) Use the Web Service stack to create a
service definition from the output of a and b. This is done
by the Web Service binding.
d. (client) Transform the Java datatypes passed on the service
invocation into an XML infoset (as defined by b) for marshalling
by the reference binding's Web Service stack. This is done by
the databinding framework. In Tuscany today, the XML infoset
would be AXIOM for use by the Axis2 binding.
e. (client) Pass the XML infoset created by d to the service
definition created by c. This is done by the Web Service binding.
f. (service) Receive the invocation data in XML infoset form from
the service definition created by c. This is done by the
Web Service binding.
g. (service) Transform the XML infoset (as defined by b) passed
on the service invocation into Java classes that can be passed
to the service business logic. This is done by the databinding
framework.
h. (service) Invoke the service business logic.
i. Any result or exception is returned to the client using the
inverse of steps d to g.
My understanding is that the current state of the Tuscany code
for these steps is as follows.
a. Broken, does not understand JAX-WS annotations.
b. Most or all of the code needed is currently present in the
JAXP transformer and the exception mapper, but some information
that it needs (derived from JAX-WS annotations) is not being
passed to it.
c. Would probably work if the right outputs from a and b were
passed in, but this is not certain as it depends on whether the
Axis2 stack that we are using has any limitations here.
d. Probably working if the correct output from b is available.
e. Probably working.
f. Probably working.
g. Probably working if the correct output from b is available.
h. Working.
i. Probably working once the above steps have been made to work.
Tuscany also has standalone tools to do Java-to-WSDL and
WSDL-to-Java mapping. These currently use code that's completely
separate from the above code in the runtime. Ideally as much
code as possible should be shared between tools and runtime.
Specifically, the code for steps a and b should also be invoked
by the tools, to guarantee consistent processing. This means
that we need a module structure that makes it easy for the
tools to pull in this code without too many other dependencies.
For databindings other than JAXB (let's use SDO as an example),
steps b, d and g need to be pluggable. Currently only steps
d and g are pluggable, so b needs to include a framework that
allows other databinding transformations to be plugged in.
For WSDL to Java processing, something similar is needed, but
I won't make this post twice as long by spelling out all the
steps here.
In terms of making progress on TUSCANY-2033 and similar use cases,
I think the the starting point is to work on steps a and b and
at least get them into an 80% state so that we can start to run
end-to-end scenarios through all the steps. We could then go back
later and get them to a state of 100% perfection.
I have been thinking of having the Tuscany runtime call code in
CXF to do the 80% exercise for step a, perhaps only as a temporary
prototype and learning exercise until we have all the necessary
code in Tuscany. I think I understand how to do this, but I don't
yet feel able to do a "from scratch" implementation of step a.
I'd welcome other thoughts on this and any offers to help with
steps a or b.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
Posted by Simon Nash <na...@apache.org>.
Simon Nash wrote:
> Raymond Feng wrote:
>> 1) I added the sample at
>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/zipcode-jaxws.
>> (Not in the build yet even it works).
> >
> Thanks, Raymond. This sample runs OK for me. However, it does not
> represent the use case that I had in mind. (Sorry that I did not
> make this clear enough in my original post.) The use case is a
> service invocation that does not use a WSDL interface at all, but
> only uses a Java interface that was generated from WSDL using the
> JAX-WS WSDL to Java mapping.
>
> I modified the sample to do this and it gave a NullPointerException.
> I am investigating and I will post further updates as I have them.
>
I am making good progress with this. I have made quite a few
changes (in private at present) to the code that Raymond checked in.
I have been holding off committing these changes because ideally
I would like to have a simple end-to-end scenario working before I
check in my code. I don't have this working yet, though I think
I am close. If I can't get to this point within the next day or so,
I'll go ahead and commit the changes anyway.
Simon
> Simon
>
>> 2) The JAXB schema generation code is at:
>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-jaxb/src/main/java/org/apache/tuscany/sca/databinding/jaxb/JAXBContextHelper.java
>> (see the generateSchema() method).
>>
>> Thanks,
>> Raymond
>> --------------------------------------------------
>> From: "Simon Nash" <na...@apache.org>
>> Sent: Wednesday, April 02, 2008 12:09 PM
>> To: <tu...@ws.apache.org>
>> Subject: Re: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
>>
>>> Raymond Feng wrote:
>>>> Please see my comments inline.
>>>>
>>> I have added some responses inline under your comments.
>>>
>>> Simon
>>>
>>>> Thanks,
>>>> Raymond
>>>>
>>>> --------------------------------------------------
>>>> From: "Simon Nash" <na...@apache.org>
>>>> Sent: Wednesday, April 02, 2008 7:31 AM
>>>> To: "tuscany-dev" <tu...@ws.apache.org>
>>>> Subject: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
>>>>
>>>>> I'd like to restart the discussion on supporting JAX-WS annotations
>>>>> for the Java-to-WSDL mapping. This is needed to fix TUSCANY-2033,
>>>>> and has been the subject of various user requests from time to time.
>>>>>
>>>>> The scenario that I want to fix is a service with a Java interface
>>>>> that was generated from WSDL by running the JAX-WS mapping (e.g.,
>>>>> the wsimport tool from the JAX-WS RI). The generated service
>>>>> interface
>>>>> and associated classes (e.g., exceptions, data objects) will have
>>>>> JAX-WS and JAXB annotations that are equivalent to the information
>>>>> contained in the WSDL.
>>>>
>>>> I have prototyped a demo application for the weather forecast web
>>>> service as you described. It runs successfully
>>>> with the trunk code. I can check it in as an sample.
>>>>
>>> Please do check this in. I would be very interested to see it.
>>>
>>>>>
>>>>> The runtime processing for a Tuscany client talking to a Tuscany
>>>>> service is as follows:
>>>>>
>>>>> a. (client and service) Generate an equivalent WSDL interface from
>>>>> the Java service interface and associated classes.
>>>>> b. (client and service) Generate equivalent XSD types from the
>>>>> Java service interface and associated classes.
>>>>> c. (client and service) Use the Web Service stack to create a
>>>>> service definition from the output of a and b. This is done
>>>>> by the Web Service binding.
>>>>> d. (client) Transform the Java datatypes passed on the service
>>>>> invocation into an XML infoset (as defined by b) for marshalling
>>>>> by the reference binding's Web Service stack. This is done by
>>>>> the databinding framework. In Tuscany today, the XML infoset
>>>>> would be AXIOM for use by the Axis2 binding.
>>>>> e. (client) Pass the XML infoset created by d to the service
>>>>> definition created by c. This is done by the Web Service binding.
>>>>> f. (service) Receive the invocation data in XML infoset form from
>>>>> the service definition created by c. This is done by the
>>>>> Web Service binding.
>>>>> g. (service) Transform the XML infoset (as defined by b) passed
>>>>> on the service invocation into Java classes that can be passed
>>>>> to the service business logic. This is done by the databinding
>>>>> framework.
>>>>> h. (service) Invoke the service business logic.
>>>>> i. Any result or exception is returned to the client using the
>>>>> inverse of steps d to g.
>>>>>
>>>>
>>>> Good summary.
>>>>
>>> Thanks!
>>>
>>>>> My understanding is that the current state of the Tuscany code
>>>>> for these steps is as follows.
>>>>>
>>>>> a. Broken, does not understand JAX-WS annotations.
>>>>
>>>> Not really. We support most of the JAX-WS annotations for java SEI
>>>> (Service Endpoint Interface) in interface-java-jaxws module.
>>>>
>>> I need to split a into a1 and a2 to clarify my comment. a1 is
>>> generating the WSDL interface that is passed to the Web Service
>>> stack in step c. This part is broken AFAIK. a2 is creating a
>>> Tuscany interface definition that is (???) used by step d. As
>>> you point out, this is mostly working.
>>>
>>> [Is step d is driven by an interface.wsdl derived from the WSDL
>>> generated in step a1, or by an interface.java that is generated
>>> in step a2? Please clarify.]
>>>
>>>>> b. Most or all of the code needed is currently present in the
>>>>> JAXP transformer and the exception mapper, but some information
>>>>> that it needs (derived from JAX-WS annotations) is not being
>>>>> passed to it.
>>>>
>>>> I assume you meant JAXB. What information is missing?
>>>>
>>> Yes, I meant JAXB. Maybe nothing is missing, given that the result
>>> of step a2 is used as input to drive this step.
>>>
>>>>> c. Would probably work if the right outputs from a and b were
>>>>> passed in, but this is not certain as it depends on whether the
>>>>> Axis2 stack that we are using has any limitations here.
>>>>> d. Probably working if the correct output from b is available.
>>>>> e. Probably working.
>>>>> f. Probably working.
>>>>> g. Probably working if the correct output from b is available.
>>>>> h. Working.
>>>>> i. Probably working once the above steps have been made to work.
>>>>>
>>>>> Tuscany also has standalone tools to do Java-to-WSDL and
>>>>> WSDL-to-Java mapping. These currently use code that's completely
>>>>> separate from the above code in the runtime. Ideally as much
>>>>> code as possible should be shared between tools and runtime.
>>>>> Specifically, the code for steps a and b should also be invoked
>>>>> by the tools, to guarantee consistent processing. This means
>>>>> that we need a module structure that makes it easy for the
>>>>> tools to pull in this code without too many other dependencies.
>>>>
>>>> +1.
>>>>
>>>>>
>>>>> For databindings other than JAXB (let's use SDO as an example),
>>>>> steps b, d and g need to be pluggable. Currently only steps
>>>>> d and g are pluggable, so b needs to include a framework that
>>>>> allows other databinding transformations to be plugged in.
>>>>>
>>>>
>>>> Right.
>>>>
>>>>> For WSDL to Java processing, something similar is needed, but
>>>>> I won't make this post twice as long by spelling out all the
>>>>> steps here.
>>>>>
>>>>> In terms of making progress on TUSCANY-2033 and similar use cases,
>>>>> I think the the starting point is to work on steps a and b and
>>>>> at least get them into an 80% state so that we can start to run
>>>>> end-to-end scenarios through all the steps. We could then go back
>>>>> later and get them to a state of 100% perfection.
>>>>>
>>>>> I have been thinking of having the Tuscany runtime call code in
>>>>> CXF to do the 80% exercise for step a, perhaps only as a temporary
>>>>> prototype and learning exercise until we have all the necessary
>>>>> code in Tuscany. I think I understand how to do this, but I don't
>>>>> yet feel able to do a "from scratch" implementation of step a.
>>>>>
>>>>
>>>> I have checked in some code to demonstrate how we can generate WSDL
>>>> portType out of our Interface/Operation model.
>>>> @
>>>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-java2wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/interface2wsdl.
>>>> Please note I name it as Interface2WSDL.
>>>>
>>> Thanks, I will take a look at this.
>>>
>>>> It seems that step a is not so complicated even though my initial
>>>> code needs more enhancements. For step b, I have added the capability
>>>> into databinding-jaxb module to generate XSD from JAXBContext. We
>>>> can do the similar thing for SDO and there are APIs for it.
>>>>
>>> Please can you give a more exact pointer to where in the
>>> databinding-jaxb
>>> module I can find this code.
>>>
>>> Thanks for this very quick and very helpful response!
>>>
>>> Simon
>>>
>>>>> I'd welcome other thoughts on this and any offers to help with
>>>>> steps a or b.
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
Posted by Simon Nash <na...@apache.org>.
Raymond Feng wrote:
> 1) I added the sample at
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/zipcode-jaxws.
> (Not in the build yet even it works).
>
Thanks, Raymond. This sample runs OK for me. However, it does not
represent the use case that I had in mind. (Sorry that I did not
make this clear enough in my original post.) The use case is a
service invocation that does not use a WSDL interface at all, but
only uses a Java interface that was generated from WSDL using the
JAX-WS WSDL to Java mapping.
I modified the sample to do this and it gave a NullPointerException.
I am investigating and I will post further updates as I have them.
Simon
> 2) The JAXB schema generation code is at:
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-jaxb/src/main/java/org/apache/tuscany/sca/databinding/jaxb/JAXBContextHelper.java
> (see the generateSchema() method).
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Simon Nash" <na...@apache.org>
> Sent: Wednesday, April 02, 2008 12:09 PM
> To: <tu...@ws.apache.org>
> Subject: Re: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
>
>> Raymond Feng wrote:
>>> Please see my comments inline.
>>>
>> I have added some responses inline under your comments.
>>
>> Simon
>>
>>> Thanks,
>>> Raymond
>>>
>>> --------------------------------------------------
>>> From: "Simon Nash" <na...@apache.org>
>>> Sent: Wednesday, April 02, 2008 7:31 AM
>>> To: "tuscany-dev" <tu...@ws.apache.org>
>>> Subject: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
>>>
>>>> I'd like to restart the discussion on supporting JAX-WS annotations
>>>> for the Java-to-WSDL mapping. This is needed to fix TUSCANY-2033,
>>>> and has been the subject of various user requests from time to time.
>>>>
>>>> The scenario that I want to fix is a service with a Java interface
>>>> that was generated from WSDL by running the JAX-WS mapping (e.g.,
>>>> the wsimport tool from the JAX-WS RI). The generated service interface
>>>> and associated classes (e.g., exceptions, data objects) will have
>>>> JAX-WS and JAXB annotations that are equivalent to the information
>>>> contained in the WSDL.
>>>
>>> I have prototyped a demo application for the weather forecast web
>>> service as you described. It runs successfully
>>> with the trunk code. I can check it in as an sample.
>>>
>> Please do check this in. I would be very interested to see it.
>>
>>>>
>>>> The runtime processing for a Tuscany client talking to a Tuscany
>>>> service is as follows:
>>>>
>>>> a. (client and service) Generate an equivalent WSDL interface from
>>>> the Java service interface and associated classes.
>>>> b. (client and service) Generate equivalent XSD types from the
>>>> Java service interface and associated classes.
>>>> c. (client and service) Use the Web Service stack to create a
>>>> service definition from the output of a and b. This is done
>>>> by the Web Service binding.
>>>> d. (client) Transform the Java datatypes passed on the service
>>>> invocation into an XML infoset (as defined by b) for marshalling
>>>> by the reference binding's Web Service stack. This is done by
>>>> the databinding framework. In Tuscany today, the XML infoset
>>>> would be AXIOM for use by the Axis2 binding.
>>>> e. (client) Pass the XML infoset created by d to the service
>>>> definition created by c. This is done by the Web Service binding.
>>>> f. (service) Receive the invocation data in XML infoset form from
>>>> the service definition created by c. This is done by the
>>>> Web Service binding.
>>>> g. (service) Transform the XML infoset (as defined by b) passed
>>>> on the service invocation into Java classes that can be passed
>>>> to the service business logic. This is done by the databinding
>>>> framework.
>>>> h. (service) Invoke the service business logic.
>>>> i. Any result or exception is returned to the client using the
>>>> inverse of steps d to g.
>>>>
>>>
>>> Good summary.
>>>
>> Thanks!
>>
>>>> My understanding is that the current state of the Tuscany code
>>>> for these steps is as follows.
>>>>
>>>> a. Broken, does not understand JAX-WS annotations.
>>>
>>> Not really. We support most of the JAX-WS annotations for java SEI
>>> (Service Endpoint Interface) in interface-java-jaxws module.
>>>
>> I need to split a into a1 and a2 to clarify my comment. a1 is
>> generating the WSDL interface that is passed to the Web Service
>> stack in step c. This part is broken AFAIK. a2 is creating a
>> Tuscany interface definition that is (???) used by step d. As
>> you point out, this is mostly working.
>>
>> [Is step d is driven by an interface.wsdl derived from the WSDL
>> generated in step a1, or by an interface.java that is generated
>> in step a2? Please clarify.]
>>
>>>> b. Most or all of the code needed is currently present in the
>>>> JAXP transformer and the exception mapper, but some information
>>>> that it needs (derived from JAX-WS annotations) is not being
>>>> passed to it.
>>>
>>> I assume you meant JAXB. What information is missing?
>>>
>> Yes, I meant JAXB. Maybe nothing is missing, given that the result
>> of step a2 is used as input to drive this step.
>>
>>>> c. Would probably work if the right outputs from a and b were
>>>> passed in, but this is not certain as it depends on whether the
>>>> Axis2 stack that we are using has any limitations here.
>>>> d. Probably working if the correct output from b is available.
>>>> e. Probably working.
>>>> f. Probably working.
>>>> g. Probably working if the correct output from b is available.
>>>> h. Working.
>>>> i. Probably working once the above steps have been made to work.
>>>>
>>>> Tuscany also has standalone tools to do Java-to-WSDL and
>>>> WSDL-to-Java mapping. These currently use code that's completely
>>>> separate from the above code in the runtime. Ideally as much
>>>> code as possible should be shared between tools and runtime.
>>>> Specifically, the code for steps a and b should also be invoked
>>>> by the tools, to guarantee consistent processing. This means
>>>> that we need a module structure that makes it easy for the
>>>> tools to pull in this code without too many other dependencies.
>>>
>>> +1.
>>>
>>>>
>>>> For databindings other than JAXB (let's use SDO as an example),
>>>> steps b, d and g need to be pluggable. Currently only steps
>>>> d and g are pluggable, so b needs to include a framework that
>>>> allows other databinding transformations to be plugged in.
>>>>
>>>
>>> Right.
>>>
>>>> For WSDL to Java processing, something similar is needed, but
>>>> I won't make this post twice as long by spelling out all the
>>>> steps here.
>>>>
>>>> In terms of making progress on TUSCANY-2033 and similar use cases,
>>>> I think the the starting point is to work on steps a and b and
>>>> at least get them into an 80% state so that we can start to run
>>>> end-to-end scenarios through all the steps. We could then go back
>>>> later and get them to a state of 100% perfection.
>>>>
>>>> I have been thinking of having the Tuscany runtime call code in
>>>> CXF to do the 80% exercise for step a, perhaps only as a temporary
>>>> prototype and learning exercise until we have all the necessary
>>>> code in Tuscany. I think I understand how to do this, but I don't
>>>> yet feel able to do a "from scratch" implementation of step a.
>>>>
>>>
>>> I have checked in some code to demonstrate how we can generate WSDL
>>> portType out of our Interface/Operation model.
>>> @
>>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-java2wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/interface2wsdl.
>>> Please note I name it as Interface2WSDL.
>>>
>> Thanks, I will take a look at this.
>>
>>> It seems that step a is not so complicated even though my initial
>>> code needs more enhancements. For step b, I have added the capability
>>> into databinding-jaxb module to generate XSD from JAXBContext. We can
>>> do the similar thing for SDO and there are APIs for it.
>>>
>> Please can you give a more exact pointer to where in the databinding-jaxb
>> module I can find this code.
>>
>> Thanks for this very quick and very helpful response!
>>
>> Simon
>>
>>>> I'd welcome other thoughts on this and any offers to help with
>>>> steps a or b.
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
Posted by Raymond Feng <en...@gmail.com>.
1) I added the sample at
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/zipcode-jaxws.
(Not in the build yet even it works).
2) The JAXB schema generation code is at:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/databinding-jaxb/src/main/java/org/apache/tuscany/sca/databinding/jaxb/JAXBContextHelper.java
(see the generateSchema() method).
Thanks,
Raymond
--------------------------------------------------
From: "Simon Nash" <na...@apache.org>
Sent: Wednesday, April 02, 2008 12:09 PM
To: <tu...@ws.apache.org>
Subject: Re: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
> Raymond Feng wrote:
>> Please see my comments inline.
>>
> I have added some responses inline under your comments.
>
> Simon
>
>> Thanks,
>> Raymond
>>
>> --------------------------------------------------
>> From: "Simon Nash" <na...@apache.org>
>> Sent: Wednesday, April 02, 2008 7:31 AM
>> To: "tuscany-dev" <tu...@ws.apache.org>
>> Subject: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
>>
>>> I'd like to restart the discussion on supporting JAX-WS annotations
>>> for the Java-to-WSDL mapping. This is needed to fix TUSCANY-2033,
>>> and has been the subject of various user requests from time to time.
>>>
>>> The scenario that I want to fix is a service with a Java interface
>>> that was generated from WSDL by running the JAX-WS mapping (e.g.,
>>> the wsimport tool from the JAX-WS RI). The generated service interface
>>> and associated classes (e.g., exceptions, data objects) will have
>>> JAX-WS and JAXB annotations that are equivalent to the information
>>> contained in the WSDL.
>>
>> I have prototyped a demo application for the weather forecast web service
>> as you described. It runs successfully
>> with the trunk code. I can check it in as an sample.
>>
> Please do check this in. I would be very interested to see it.
>
>>>
>>> The runtime processing for a Tuscany client talking to a Tuscany
>>> service is as follows:
>>>
>>> a. (client and service) Generate an equivalent WSDL interface from
>>> the Java service interface and associated classes.
>>> b. (client and service) Generate equivalent XSD types from the
>>> Java service interface and associated classes.
>>> c. (client and service) Use the Web Service stack to create a
>>> service definition from the output of a and b. This is done
>>> by the Web Service binding.
>>> d. (client) Transform the Java datatypes passed on the service
>>> invocation into an XML infoset (as defined by b) for marshalling
>>> by the reference binding's Web Service stack. This is done by
>>> the databinding framework. In Tuscany today, the XML infoset
>>> would be AXIOM for use by the Axis2 binding.
>>> e. (client) Pass the XML infoset created by d to the service
>>> definition created by c. This is done by the Web Service binding.
>>> f. (service) Receive the invocation data in XML infoset form from
>>> the service definition created by c. This is done by the
>>> Web Service binding.
>>> g. (service) Transform the XML infoset (as defined by b) passed
>>> on the service invocation into Java classes that can be passed
>>> to the service business logic. This is done by the databinding
>>> framework.
>>> h. (service) Invoke the service business logic.
>>> i. Any result or exception is returned to the client using the
>>> inverse of steps d to g.
>>>
>>
>> Good summary.
>>
> Thanks!
>
>>> My understanding is that the current state of the Tuscany code
>>> for these steps is as follows.
>>>
>>> a. Broken, does not understand JAX-WS annotations.
>>
>> Not really. We support most of the JAX-WS annotations for java SEI
>> (Service Endpoint Interface) in interface-java-jaxws module.
>>
> I need to split a into a1 and a2 to clarify my comment. a1 is
> generating the WSDL interface that is passed to the Web Service
> stack in step c. This part is broken AFAIK. a2 is creating a
> Tuscany interface definition that is (???) used by step d. As
> you point out, this is mostly working.
>
> [Is step d is driven by an interface.wsdl derived from the WSDL
> generated in step a1, or by an interface.java that is generated
> in step a2? Please clarify.]
>
>>> b. Most or all of the code needed is currently present in the
>>> JAXP transformer and the exception mapper, but some information
>>> that it needs (derived from JAX-WS annotations) is not being
>>> passed to it.
>>
>> I assume you meant JAXB. What information is missing?
>>
> Yes, I meant JAXB. Maybe nothing is missing, given that the result
> of step a2 is used as input to drive this step.
>
>>> c. Would probably work if the right outputs from a and b were
>>> passed in, but this is not certain as it depends on whether the
>>> Axis2 stack that we are using has any limitations here.
>>> d. Probably working if the correct output from b is available.
>>> e. Probably working.
>>> f. Probably working.
>>> g. Probably working if the correct output from b is available.
>>> h. Working.
>>> i. Probably working once the above steps have been made to work.
>>>
>>> Tuscany also has standalone tools to do Java-to-WSDL and
>>> WSDL-to-Java mapping. These currently use code that's completely
>>> separate from the above code in the runtime. Ideally as much
>>> code as possible should be shared between tools and runtime.
>>> Specifically, the code for steps a and b should also be invoked
>>> by the tools, to guarantee consistent processing. This means
>>> that we need a module structure that makes it easy for the
>>> tools to pull in this code without too many other dependencies.
>>
>> +1.
>>
>>>
>>> For databindings other than JAXB (let's use SDO as an example),
>>> steps b, d and g need to be pluggable. Currently only steps
>>> d and g are pluggable, so b needs to include a framework that
>>> allows other databinding transformations to be plugged in.
>>>
>>
>> Right.
>>
>>> For WSDL to Java processing, something similar is needed, but
>>> I won't make this post twice as long by spelling out all the
>>> steps here.
>>>
>>> In terms of making progress on TUSCANY-2033 and similar use cases,
>>> I think the the starting point is to work on steps a and b and
>>> at least get them into an 80% state so that we can start to run
>>> end-to-end scenarios through all the steps. We could then go back
>>> later and get them to a state of 100% perfection.
>>>
>>> I have been thinking of having the Tuscany runtime call code in
>>> CXF to do the 80% exercise for step a, perhaps only as a temporary
>>> prototype and learning exercise until we have all the necessary
>>> code in Tuscany. I think I understand how to do this, but I don't
>>> yet feel able to do a "from scratch" implementation of step a.
>>>
>>
>> I have checked in some code to demonstrate how we can generate WSDL
>> portType out of our Interface/Operation model.
>> @
>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-java2wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/interface2wsdl.
>> Please note I name it as Interface2WSDL.
>>
> Thanks, I will take a look at this.
>
>> It seems that step a is not so complicated even though my initial code
>> needs more enhancements. For step b, I have added the capability
>> into databinding-jaxb module to generate XSD from JAXBContext. We can do
>> the similar thing for SDO and there are APIs for it.
>>
> Please can you give a more exact pointer to where in the databinding-jaxb
> module I can find this code.
>
> Thanks for this very quick and very helpful response!
>
> Simon
>
>>> I'd welcome other thoughts on this and any offers to help with
>>> steps a or b.
>>>
>>> Simon
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
Posted by Simon Nash <na...@apache.org>.
Raymond Feng wrote:
> Please see my comments inline.
>
I have added some responses inline under your comments.
Simon
> Thanks,
> Raymond
>
> --------------------------------------------------
> From: "Simon Nash" <na...@apache.org>
> Sent: Wednesday, April 02, 2008 7:31 AM
> To: "tuscany-dev" <tu...@ws.apache.org>
> Subject: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
>
>> I'd like to restart the discussion on supporting JAX-WS annotations
>> for the Java-to-WSDL mapping. This is needed to fix TUSCANY-2033,
>> and has been the subject of various user requests from time to time.
>>
>> The scenario that I want to fix is a service with a Java interface
>> that was generated from WSDL by running the JAX-WS mapping (e.g.,
>> the wsimport tool from the JAX-WS RI). The generated service interface
>> and associated classes (e.g., exceptions, data objects) will have
>> JAX-WS and JAXB annotations that are equivalent to the information
>> contained in the WSDL.
>
> I have prototyped a demo application for the weather forecast web
> service as you described. It runs successfully
> with the trunk code. I can check it in as an sample.
>
Please do check this in. I would be very interested to see it.
>>
>> The runtime processing for a Tuscany client talking to a Tuscany
>> service is as follows:
>>
>> a. (client and service) Generate an equivalent WSDL interface from
>> the Java service interface and associated classes.
>> b. (client and service) Generate equivalent XSD types from the
>> Java service interface and associated classes.
>> c. (client and service) Use the Web Service stack to create a
>> service definition from the output of a and b. This is done
>> by the Web Service binding.
>> d. (client) Transform the Java datatypes passed on the service
>> invocation into an XML infoset (as defined by b) for marshalling
>> by the reference binding's Web Service stack. This is done by
>> the databinding framework. In Tuscany today, the XML infoset
>> would be AXIOM for use by the Axis2 binding.
>> e. (client) Pass the XML infoset created by d to the service
>> definition created by c. This is done by the Web Service binding.
>> f. (service) Receive the invocation data in XML infoset form from
>> the service definition created by c. This is done by the
>> Web Service binding.
>> g. (service) Transform the XML infoset (as defined by b) passed
>> on the service invocation into Java classes that can be passed
>> to the service business logic. This is done by the databinding
>> framework.
>> h. (service) Invoke the service business logic.
>> i. Any result or exception is returned to the client using the
>> inverse of steps d to g.
>>
>
> Good summary.
>
Thanks!
>> My understanding is that the current state of the Tuscany code
>> for these steps is as follows.
>>
>> a. Broken, does not understand JAX-WS annotations.
>
> Not really. We support most of the JAX-WS annotations for java SEI
> (Service Endpoint Interface) in interface-java-jaxws module.
>
I need to split a into a1 and a2 to clarify my comment. a1 is
generating the WSDL interface that is passed to the Web Service
stack in step c. This part is broken AFAIK. a2 is creating a
Tuscany interface definition that is (???) used by step d. As
you point out, this is mostly working.
[Is step d is driven by an interface.wsdl derived from the WSDL
generated in step a1, or by an interface.java that is generated
in step a2? Please clarify.]
>> b. Most or all of the code needed is currently present in the
>> JAXP transformer and the exception mapper, but some information
>> that it needs (derived from JAX-WS annotations) is not being
>> passed to it.
>
> I assume you meant JAXB. What information is missing?
>
Yes, I meant JAXB. Maybe nothing is missing, given that the result
of step a2 is used as input to drive this step.
>> c. Would probably work if the right outputs from a and b were
>> passed in, but this is not certain as it depends on whether the
>> Axis2 stack that we are using has any limitations here.
>> d. Probably working if the correct output from b is available.
>> e. Probably working.
>> f. Probably working.
>> g. Probably working if the correct output from b is available.
>> h. Working.
>> i. Probably working once the above steps have been made to work.
>>
>> Tuscany also has standalone tools to do Java-to-WSDL and
>> WSDL-to-Java mapping. These currently use code that's completely
>> separate from the above code in the runtime. Ideally as much
>> code as possible should be shared between tools and runtime.
>> Specifically, the code for steps a and b should also be invoked
>> by the tools, to guarantee consistent processing. This means
>> that we need a module structure that makes it easy for the
>> tools to pull in this code without too many other dependencies.
>
> +1.
>
>>
>> For databindings other than JAXB (let's use SDO as an example),
>> steps b, d and g need to be pluggable. Currently only steps
>> d and g are pluggable, so b needs to include a framework that
>> allows other databinding transformations to be plugged in.
>>
>
> Right.
>
>> For WSDL to Java processing, something similar is needed, but
>> I won't make this post twice as long by spelling out all the
>> steps here.
>>
>> In terms of making progress on TUSCANY-2033 and similar use cases,
>> I think the the starting point is to work on steps a and b and
>> at least get them into an 80% state so that we can start to run
>> end-to-end scenarios through all the steps. We could then go back
>> later and get them to a state of 100% perfection.
>>
>> I have been thinking of having the Tuscany runtime call code in
>> CXF to do the 80% exercise for step a, perhaps only as a temporary
>> prototype and learning exercise until we have all the necessary
>> code in Tuscany. I think I understand how to do this, but I don't
>> yet feel able to do a "from scratch" implementation of step a.
>>
>
> I have checked in some code to demonstrate how we can generate WSDL
> portType out of our Interface/Operation model.
> @
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-java2wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/interface2wsdl.
> Please note I name it as Interface2WSDL.
>
Thanks, I will take a look at this.
> It seems that step a is not so complicated even though my initial code
> needs more enhancements. For step b, I have added the capability
> into databinding-jaxb module to generate XSD from JAXBContext. We can do
> the similar thing for SDO and there are APIs for it.
>
Please can you give a more exact pointer to where in the databinding-jaxb
module I can find this code.
Thanks for this very quick and very helpful response!
Simon
>> I'd welcome other thoughts on this and any offers to help with
>> steps a or b.
>>
>> Simon
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Nash" <na...@apache.org>
Sent: Wednesday, April 02, 2008 7:31 AM
To: "tuscany-dev" <tu...@ws.apache.org>
Subject: JAX-WS support in the Java to WSDL mapping (TUSCANY-2033)
> I'd like to restart the discussion on supporting JAX-WS annotations
> for the Java-to-WSDL mapping. This is needed to fix TUSCANY-2033,
> and has been the subject of various user requests from time to time.
>
> The scenario that I want to fix is a service with a Java interface
> that was generated from WSDL by running the JAX-WS mapping (e.g.,
> the wsimport tool from the JAX-WS RI). The generated service interface
> and associated classes (e.g., exceptions, data objects) will have
> JAX-WS and JAXB annotations that are equivalent to the information
> contained in the WSDL.
I have prototyped a demo application for the weather forecast web service as
you described. It runs successfully
with the trunk code. I can check it in as an sample.
>
> The runtime processing for a Tuscany client talking to a Tuscany
> service is as follows:
>
> a. (client and service) Generate an equivalent WSDL interface from
> the Java service interface and associated classes.
> b. (client and service) Generate equivalent XSD types from the
> Java service interface and associated classes.
> c. (client and service) Use the Web Service stack to create a
> service definition from the output of a and b. This is done
> by the Web Service binding.
> d. (client) Transform the Java datatypes passed on the service
> invocation into an XML infoset (as defined by b) for marshalling
> by the reference binding's Web Service stack. This is done by
> the databinding framework. In Tuscany today, the XML infoset
> would be AXIOM for use by the Axis2 binding.
> e. (client) Pass the XML infoset created by d to the service
> definition created by c. This is done by the Web Service binding.
> f. (service) Receive the invocation data in XML infoset form from
> the service definition created by c. This is done by the
> Web Service binding.
> g. (service) Transform the XML infoset (as defined by b) passed
> on the service invocation into Java classes that can be passed
> to the service business logic. This is done by the databinding
> framework.
> h. (service) Invoke the service business logic.
> i. Any result or exception is returned to the client using the
> inverse of steps d to g.
>
Good summary.
> My understanding is that the current state of the Tuscany code
> for these steps is as follows.
>
> a. Broken, does not understand JAX-WS annotations.
Not really. We support most of the JAX-WS annotations for java SEI (Service
Endpoint Interface) in interface-java-jaxws module.
> b. Most or all of the code needed is currently present in the
> JAXP transformer and the exception mapper, but some information
> that it needs (derived from JAX-WS annotations) is not being
> passed to it.
I assume you meant JAXB. What information is missing?
> c. Would probably work if the right outputs from a and b were
> passed in, but this is not certain as it depends on whether the
> Axis2 stack that we are using has any limitations here.
> d. Probably working if the correct output from b is available.
> e. Probably working.
> f. Probably working.
> g. Probably working if the correct output from b is available.
> h. Working.
> i. Probably working once the above steps have been made to work.
>
> Tuscany also has standalone tools to do Java-to-WSDL and
> WSDL-to-Java mapping. These currently use code that's completely
> separate from the above code in the runtime. Ideally as much
> code as possible should be shared between tools and runtime.
> Specifically, the code for steps a and b should also be invoked
> by the tools, to guarantee consistent processing. This means
> that we need a module structure that makes it easy for the
> tools to pull in this code without too many other dependencies.
+1.
>
> For databindings other than JAXB (let's use SDO as an example),
> steps b, d and g need to be pluggable. Currently only steps
> d and g are pluggable, so b needs to include a framework that
> allows other databinding transformations to be plugged in.
>
Right.
> For WSDL to Java processing, something similar is needed, but
> I won't make this post twice as long by spelling out all the
> steps here.
>
> In terms of making progress on TUSCANY-2033 and similar use cases,
> I think the the starting point is to work on steps a and b and
> at least get them into an 80% state so that we can start to run
> end-to-end scenarios through all the steps. We could then go back
> later and get them to a state of 100% perfection.
>
> I have been thinking of having the Tuscany runtime call code in
> CXF to do the 80% exercise for step a, perhaps only as a temporary
> prototype and learning exercise until we have all the necessary
> code in Tuscany. I think I understand how to do this, but I don't
> yet feel able to do a "from scratch" implementation of step a.
>
I have checked in some code to demonstrate how we can generate WSDL portType
out of our Interface/Operation model.
@
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-java2wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/interface2wsdl.
Please note I name it as Interface2WSDL.
It seems that step a is not so complicated even though my initial code needs
more enhancements. For step b, I have added the capability
into databinding-jaxb module to generate XSD from JAXBContext. We can do the
similar thing for SDO and there are APIs for it.
> I'd welcome other thoughts on this and any offers to help with
> steps a or b.
>
> Simon
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org