On Wed, May 21, 2008 at 7:19 PM, Scott Kurz (JIRA) < tuscany-dev@ws.apache.org> wrote:
> > [ > https://issues.apache.org/jira/browse/TUSCANY-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Scott Kurz updated TUSCANY-2332: > -------------------------------- > > Attachment: guessAndGreet.wsdl > > > reconsider non-support for Holders > > ---------------------------------- > > > > Key: TUSCANY-2332 > > URL: https://issues.apache.org/jira/browse/TUSCANY-2332 > > Project: Tuscany > > Issue Type: Improvement > > Components: Java SCA Data Binding Runtime > > Reporter: Scott Kurz > > Attachments: guessAndGreet.wsdl > > > > > > Though the Java annotations/API spec specifically says wrt WSDL-> Java > mapping: > > The JAX-WS mappings are applied with the following restrictions: > > • No support for holders > > I'd like to suggest that we look into enabling such support anyway, as > this seems overly restrictive and prevents us from supporting existing WSDLs > with inout data. > > At least I don't see how we'd map these WSDLs to Java and would think > we'd be way better off relying on the mapping defined by JAX-WS which does > use Holders. > > (Not sure what this statement in the spec was trying to accomplish.) > > I attached an example WSDL with two operations which we'd want to use > Holders in the corresponding Java methods. One has a common child element > of both input/output wrapper elem and the other has a common part of > input/output message. > > (Maybe it would be better to bring this up before opening a JIRA, but I > wanted to attach the WSDL.) > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > Hi Scott I have a couple of questions/comments related to this. I don't know why the spec specifically stated that we won't support this either but I can make a guess. On a philosophical note if you are in the business of writing coarse grained service interfaces with the intention of being protocol independent then relying on in/out or out parameters in you interface is unlikely to make your interfaces clear and easy to use. Like everything, as a purely technical challenge, I'm sure it could be made to work but IMHO it doesn't add clarity or achieve anything that can't be achieved with clearly delineated input parameters and a response value. As we only deal with doc/lit/wrapped WSDL currently Tuscany only expects one part per message and would always expect there to be a set of input parameters and a response. If this WSDL has come from some other existing system with the intention of representing in/out or out parameters then the SOAP engine on the service end will be marshalling from request parameters and to a responses so Tuscany would just take the WSDL at face value. As a slight aside, looking at the WSDL attached, I had to go and check in the WSDL spec what the hints are for in/out and out params. In WSDL 1.1 I found some words in section 2.4.6 which don't seem to chime with the approach you have taken. What rules are you following to indicate in/out and out parameters. Regards Simon
