Re: Apache TCK Issues

[ru...@us.ibm.com]

More on doc lit...

- Sam Ruby
---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 07/12/2002 09:
18 AM ---------------------------

Rahul Sharma <ra...@sun.com>@sun.com on 07/11/2002 04:40:18 PM

Sent by:    Rahul.Sharma@sun.com


To:    Lance.Andersen@sun.com, Sam Ruby/Raleigh/IBM@IBMUS
cc:    Rahul.Sharma@sun.com, Art Frechette <Ar...@sun.com>
Subject:    Re: Apache TCK Issues




rubys@us.ibm.com wrote:

> Lance/Rahul: Additional information on wrapped/doc lit, from Rich
> Scheurle....
>       JSR 101 v1.0 clearly indicates that the parameters of the
>       signature are obtained from the message parts.  This information is
used to
>       determine order, holders, etc.  There is no mention of unwrapping
an
>       part's element attribute to populate the parameter list.

  In the doc/literal mode, there is a *single* message part that is
  the wrapper element for parameters (in case of an input message).
  This wrapper element is the first child element of the SOAP Body
  element. This requirement is established by the section 6.2. Please
  see the example 6.4.3 for "DoExample" message.

  The parameterOrder and resulting WSDL->Java mapping implications
  apply to the message parts (and hence the wrapper element) not the
  elements contained within the wrapper element.

  In JAX-RPC spec, the chapters 4 and 5 have mapping specified based
  on the abstract portions of WSDL (portType, message, types) and
  independent of the concrete SOAP binding (and hence doc/literal
  and rpc/encoded modes). The chapter 6 augments the chapters 4/5
  mapping to add the SOAP binding specific mapping implications.

  The goal of JAX-RPC 1.0 has been to achieve similar consistent
  programming model (and mapped Java method signatures) that largely
  hide the doc/literal and rpc/encoded modes, and other SOAP binding
  specific mapping implications. Now that the  WSDL 1.1 spec is not
  so clear in the separation between abstract and concrete SOAP binding
  portions of the WSDL service description--some of SOAP binding
  specific aspects have a direct implication on the WSDL->Java mapping
  specified in the JAX-RPC spec.

  So consistent with the above goal of having one consistent
  programming model largely independent of doc/literal and rpc/
  encoded modes, JAX-RPC requires the standard type mapping to be
  used for mapping doc/literal parts. So the elements within the
  wrapper element (if these correspond to the standard type
  mapping support in the JAX-RPC) are mapped as method parameters
  using the data binding based on the standard type mapping specified
  in the JAX-RPC spec. For any extended non-standard types, a
  literal message part is mapped to a SOAPElement as a least common
  denominator portable mapping. Any vendor-implementation specific
  data binding for extended non-standard types is non-portable given
  the absence of standard JAXB for JAX-RPC 1.0. This will be addressed
  with the JAXB support.

  We had discussion on this in the EG. The consistent feeling was
  that a "JavaBean foo(JavaBean param") method signature is not
  natural to the Java programmer in terms of doc/literal mapping
  and should be avoided if so possible. The Java mapping for doc/
  literal with wrapper requirements using the standard type mapping
  meets this goal.

  The above has been the intent of the spec and is captured in
  the TCK. If you think that spec should be more verbose and
  clear in these terms, we can do so in the next release to remove
  any ambiguity in the requirements interpretation.

>       What if the complexType TradePriceRequest contained two elements
>       (tickerSymbol and companyName) ?  Would the TCK expect the
following
>       signature:

>       public float getLastTradePrice(String body, String body) throws
>       RemoteException;  // NOTE Two Parameters with the same name!

  This will be an error that should be detected during the WSDL->Java
  mapping.

  Regards,

  Rahul Sharma


> Axis-dev'ers: below is outlook on schedule, process, etc.
>
> Everyone: what is the right process for Apache to approach the Expert
> Group? - Sam Ruby
>
> ---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 07/09/2002
> 01:40 PM ---------------------------
>
> To: Sam Ruby/Raleigh/IBM@IBMUS
> cc:
> Subject: Re: apache jaxrpc issues
>
>
>
> Hi Sam,
>
> Yes it was excellent thank you.  Could have used a bit more time but
> that is always the case after a holiday.  How was your 4th?  Hopefully
> you took some time off as well.
>
> Yes I am getting traffic on the list.
>
>
> For the content-id header, if either you or dims could fill out the
> template, that would be ideal.  I really need to know which tests and
> the section(s) of the spec which are in question. This just in, dims
> just sent me the challenge (and called me).... so I will take a look now.
>
>
> We are going to do a patch for jaxrpc based on the issues that you had
> raised previously and I have responded to.    If you have other issues,
> please forward when you have a chance so that we can review.  My goal is
> to address any issues that we feel need patched.   Issues that do not
> get patched and we concur with, will be excluded.  I don't have an exact
> ETA for the patch as I want to see what other issues you have that we
> can address at the same time.
>
>
> I also followed up with Rahul again on the following issue.  He believes
> the tests are correct in their design.  His comments follow the issue
> description and your team's comments.  I think if there is still a
> concern, that it should be revisited in the Expert Group regarding the
> spec requirements.  Please let me know your thoughts.
>
> >>>>
> >>>> wrapped doc/lit
> >>>> The TCK is expecting wrapped doc/lit signatures (like what .NET
> >>>> does).  We do not believe it should.
> >>>>
> >>>> Here's a WSDL snippet from the TCK's stock quote test:
> >>>>
> >>>> <element name="TradePriceRequest">
> >>>>  <complexType>
> >>>>    <sequence>
> >>>>      <element name="tickerSymbol" type="string"/>
> >>>>    </sequence>
> >>>>  </complexType>
> >>>> </element>
> >>>> <element name="TradePrice">
> >>>>  <complexType>
> >>>>    <sequence>
> >>>>      <element name="price" type="float"/>
> >>>>    </sequence>
> >>>>  </complexType>
> >>>> </element>
> >>>>
> >>>> <message name="GetLastTradePriceInput">
> >>>>  <part name="body" element="xsd1:TradePriceRequest"/>
> >>>> </message>
> >>>>
> >>>> <message name="GetLastTradePriceOutput">
> >>>>  <part name="body" element="xsd1:TradePrice"/>
> >>>> </message>
> >>>>
> >>>> <portType name="StockQuotePortType">
> >>>>  <operation name="GetLastTradePrice">
> >>>>    <input message="tns:GetLastTradePriceInput"/>
> >>>>    <output message="tns:GetLastTradePriceOutput"/>
> >>>>  </operation>
> >>>> </portType>
> >>>>
> >>>> (the binding for this WSDL is doc/lit).  This is ALMOST like .NET's
> >>>> doc/lit style.  But it's not quite.  AXIS generates:
> >>>>
> >>>> public TradePrice getLastTradePrice(TradePriceRequest body) throws
> >>>> RemoteException;
> >>>>
> >>>> Unfortunately the TCK expects the following signature:
> >>>>
> >>>> public float getLastTradePrice(String body) throws RemoteException;
> >>>>
> >>>> We don't read anything in JAX-RPC that allows or requires this
> >>>> signature, so we do not believe the TCK should expect this
signature.
> >>>
> >>>
> >>>
> >>>
> >>>   Doc/literal with wrapper is required as per 6.2. There is also an
> >>>   example in section 6.4.
> >>>
> >>>   So this is not an issue.
> >>
> >>
> >>
> >>
> >>
> >> This is not an issue. I am expecting what the spec says regarding
> >> doc/literal.
> >>
> >>
> <rjs>
>
> You are looking at the first mapping in section 6.4.3. Read futher in
> the same section. "Another possible mapping of the doExample method is
> as follows. In this example, the part named body in the DoExample
> message is mapped as xsd:complexType:
>
> DoExampleResponse doExample(DoExample body) throws
> java.rmi.RemoteException;"
>
> This is the kind of mapping that Axis uses. Also note that the last
> paragraph of 6.4.1 indicates that the mapping is specific to a JAX-RPC
> implementation and is not portable. So this is not a valid test.
>
> </rjs>
>
> As per specification, the section 6.2 requires support for wrapper
> element for doc/literal style of operations. This is used as part
> of the mapping. Please see details in this section 6.2.
>
> --- rahul's comments ----
>
>       The section 6.4.1 specifies mapping of literal message parts. In
>       case
>       of standard required set of XML/Java types, use of doc/literal
>       wrapper
>       style mapping is required as per the section 6.2. The spec can
>       clarify
>       this further (in maintenance release) if this is not entirely
clear.
>
>       For extended (beyond the standard) set of XSD types, the mapping
>       to SOAPElement is the required mapping (per section 6.4.1). Spec
>       also
>       allows implementation specific data binding (in absence of JAXB)
but
>       the latter is optional.
>
>       The section 6.4.2 provides examples about requirements in the
>       section
>       6.2 and 6.4.1. The intent of examples is to be illustrative. The
>       requirements are still derived from sections 6.2 and 6.4.1.
>
>       So JAX-RPC requires doc-literal with wrapper style of mapping for
>       operations based on the standard required set of XML schema types.
>       This is how TCK tests this case. So TCK tests are okay.
>
>       Beyond the standard set, mapping to SOAPElement is required with
any
>       any implementation-specific data binding being optional. This with
>       additional requirement that a portable application should not
>       rely on
>       any implementation specific data binding in the XML/WSDL->Java
>       mapping.
>
>
> Regards,
> Lance
> rubys@us.ibm.com wrote:
>
> > I trust you had a nice holiday?
> >
> > Are you receiving axis-tck mailing list traffic yet?
> >
> > I'd like to start discussions with an issue concerning when the
> > "Content-Id" headers (CID) for attachment parts are created. As near
> > as we can tell the SAAJ TCK is dependent on the precise timing of when
> > these ids are created by the TCK.
> >
> > How do we proceed?
> >
> > - Sam Ruby
>
>
> --
> Lance Andersen                       email: Lance.Andersen@sun.com
> Sun Microsystems Inc.                phone: (781) 442-2037
> 1 Network Drive, UBUR02-301          fax  : (781) 442-1610
> Burlington, MA 01803
>
>
>

--
Lance Andersen                       email: Lance.Andersen@sun.com
Sun Microsystems Inc.                phone: (781) 442-2037
1 Network Drive, UBUR02-301          fax  : (781) 442-1610
Burlington, MA 01803