RE: Meta-data discussion (was: RE: cvs commit: xml-axis/java/test /encoding TestArrayListConversi ons.java)

[Glen Daniels <gd...@macromedia.com>]

Hi Russell!

In particular, take a look at these msgs:

http://marc.theaimsgroup.com/?l=axis-dev&m=101421211014715&w=2
http://marc.theaimsgroup.com/?l=axis-dev&m=100629069510555&w=2

During that chat, we did explicitly discuss putting this stuff into the WSDD.  Personally, I think the WSDD is a fine place for operation-specific info, in fact even before this change operation info about return types/qnames and element mappings for doc/lit was already in the WSDD.  We needed to do this to pass the interop3 doc/lit tests.

Re: performance, I think you'll find that the way we work now probably performs BETTER than we did before, if nothing else because we're not doing an introspection for every single invocation - and that will improve still further when the method search code in RPCProvider gets cleaned up (working on it).

Re: pluggability, I'm very open to discussing in what ways this stuff should be pluggable, and how we can do it.  However, I do see a need for the Axis core to have a well-defined mechanism for representing and dealing with services/invocations/XML dispatching.  This is not least because I want to continue to support non-codegen'ed classes.

--Glen

> -----Original Message-----
> From: Russell Butek [mailto:butek@us.ibm.com]
> Sent: Friday, March 22, 2002 2:33 PM
> To: axis-dev@xml.apache.org
> Subject: Meta-data discussion (was: RE: cvs commit:
> xml-axis/java/test/encoding TestArrayListConversi ons.java)
> 
> 
> I understand what you're trying to do.  You want to get rid of the
> skeleton.  That's goodness.  But we need the meta-data that 
> lives on the
> skeleton to solve some immediate problems.  So you moved this 
> meta-data to
> deploy.wsdd.
> 
> I've got 2 concerns.
> 
> 1.  This model puts operation-level info into the deploy file.
> operation-level info doesn't belong in the deploy file (I thought we'd
> discussed this).  Perhaps it should be in a different file.  
> What should we
> call that file?  Hmmmm...  skeleton.xml?
> 
> 2.  I don't want to completely eliminate the option of having 
> a skeleton.
> Right now it has degenerated into holding meta-data and 
> you've eliminated
> the need for it by moving the meta-data elsewhere.  That's 
> fine (except for
> my point 1 caveat).  But what is the meta-data used for?  To 
> dispatch an
> incoming request to the proper method.  In the CORBA world, 
> we didn't need
> meta-data for this.  The skeletons knew intrinsically how to dispatch
> requests.  Querying meta-data is a form of introspection and 
> introspection
> can be expensive.  If we give the generated skeletons all the 
> knowledge
> they need, dispatches can be less expensive.  Yes, 
> dispatching becomes more
> complex in the XML world, but we could still do it in a 
> skeleton.  Perhaps
> I'm just approaching this all wrong.  Perhaps the 
> 'skeleton'(dispatcher?)
> should really replace RPCProvider in this scenario and 
> deploy.wsdd should
> list both the implementation and the dispatcher.  In any 
> case, I'm afraid
> of tying the runtime tightly into the meta-data model such 
> that no other
> model can be plugged in.
> 
> I've similar concerns on the client-side, but we've already 
> tied ourselves
> into the Call object.  If we tried to make the stubs more 
> knowledgeable
> like my suggested skeleton/dispatcher, then we'd have to 
> invent another way
> into the runtime outside of the DII Call object.  So I can't 
> whine as much
> on the client side.
> 
> My short answer (if you've gotten all the way through this 
> little tirade of
> mine) is that all this meta-data solves some immediate 
> problems that we
> have, but the design as it's progressing seems to hinder 
> future directions
> toward pluggability and performance improvements.
> 
> Russell Butek
> butek@us.ibm.com
> 
> 
> Glen Daniels <gd...@macromedia.com> on 03/22/2002 12:20:00 PM
> 
> Please respond to axis-dev@xml.apache.org
> 
> To:    "'axis-dev@xml.apache.org'" <ax...@xml.apache.org>
> cc:
> Subject:    RE: cvs commit: xml-axis/java/test/encoding
>        TestArrayListConversi  ons.java
> 
> 
> 
> 
> *hands Russell some pepto-bismol*
> 
> First off, understand that this metadata stuff
> (ServiceDesc/OperationDesc/ParameterDesc) is different from 
> the TypeDesc
> stuff, although both being metadata about Java<->XML 
> relationships, there
> are a few similarities.  They are independent.
> 
> The main point of the Service/Operation/Parameter descriptors 
> is to act as
> a consistent common model across the engine of what a service 
> is, what it
> can do, and the various mappings of XML names to things like 
> Java methods
> and parameters.  I'm in the midst of roughing in the core 
> parts of these
> classes now, and I expect we'll improve them as we go - please don't
> consider this stuff a polished work yet, but it moves in a 
> direction we've
> needed to go in for a long time now.  We've been discussing 
> these concepts
> for months/years.  I agree a design/arch doc is needed, and 
> I'll commit to
> doing one but I want to get this phase of development effort 
> done first.
> 
> Here's a summary.  A service has a name, a pointer to a Java 
> class, and a
> set of operations.  An operation has a QName, a java method name,
> information about the return qname/type, and a set of ordered 
> parameters.
> A parameter has a qname, an ordinal position, a mode 
> (IN/OUT/INOUT), and a
> type.  This should all feel pretty familiar - the idea is 
> that this is an
> abstract model of what Axis cares about for a service which 
> is not tied
> tightly to WSDL (though it can be used to generate WSDL or be 
> built from
> WSDL).
> 
> This data comes from one of two places.  Either 
> WSDD/deployment info or
>   introspection.  So if you want to specify that the third 
> parameter for
>   your calculateInterest() method has an XML QName of 
> ["myNS", "term"], you
>   can do that like this in WSDD:
>   <service name="loanCalc">
>     <operation name="calculateInterest">
>       <parameter name="rate" type="xsd:float"/>
>       <parameter name="principal" type="xsd:float"/>
>       <parameter qname="foo:term" xmlns:foo="myNS" type="xsd:int"/>
>     </operation>
>   </service>
> 
> If there is no info which defines this stuff in the WSDD, we 
> will build it
> by introspecting.  We only need to do this once now, because 
> once we have
> built the OperationDescs from the introspection, everything 
> else in the
> engine uses those directly.
> 
> There is actually a third way this information gets into the 
> system - on
> the client side via the Call APIs.  A Call is really a mechanism which
> makes an operation happen, and it contains metadata about 
> that operation.
> So we're moving towards a world where the Call stores all of 
> this stuff
> (parameter info, etc) in the OperationDesc inside it, instead 
> of in custom
> ways.  Also, pointing a Call at a WSDL document should enable 
> generation of
> OperationDescs from there.
> 
> Each request gets an OperationDesc associated with it - for 
> the client,
> this gets handed down from the Call.  For the server, we 
> figure it out by
> looking at the XML which came in (and then potentially resolving
> overloads).
> 
> Now, here's an example of where the rubber meets the road.  We're
> deserializing some XML like this on the server:
> 
> <calculateInterest>
>   <rate>6.625</rate>
>   <principal>10000</principal>
>   <ns1:term xmlns:ns1="myNS">48</term>
> </calculateInterest>
> 
> We've already dispatched to a SOAPService (via 
> URL/SOAPAction/NS), and we
> look in there for a ServiceDescription.  Then we ask the 
> ServiceDescription
> for an OperationDesc which matches <calculateInterest> - note 
> that this can
> be an arbitrary QName match to allow document-style services 
> to dispatch on
> any XML they want.  Once we've got the OperationDesc, the 
> RPCHandler can do
> the same trick when encountering each of the parameters <rate>,
> <principal>, and <ns1:term>.  It asks the OperationDesc for a 
> ParameterDesc
> which matches the XML, and that ParameterDesc contains the 
> type to apply.
> We used to introspect the Java class on every request to 
> figure this stuff
> out, now we just do a lookup.
> 
> Because we get parameters by QName, we are now moving towards 
> being able to
> support the "missing element == null value" pattern.  If we can
> unambiguously determine the OperationDesc which we're calling 
> (i.e. don't
> have overloaded methods), we now have the ability to set up 
> the method call
> with the passed parameters in the right places and nulls for 
> the missing
> ones.
> 
> Note also that once this info is in the WSDD, we no longer 
> need to generate
> the Skeleton classes for services built with WSDL2Java -s.
> 
> This is just an initial summary, but I hope it conveys some 
> of what's up
> with these classes and eases your "queasy feeling".  You're 
> right, this
> model is weaving its way into several parts of the runtime, which is
> exactly what it was designed to do.  Discussion / questions / 
> etc. most
> appreciated.
> 
> --Glen
> 
> > -----Original Message-----
> > From: Russell Butek [mailto:butek@us.ibm.com]
> > Sent: Friday, March 22, 2002 11:23 AM
> > To: axis-dev@xml.apache.org
> > Subject: Re: cvs commit: xml-axis/java/test/encoding
> > TestArrayListConversions.java
> >
> >
> > Hey, Glen!  Where's your design doc for this stuff!?!  I
> > would really like
> > to understand what you're doing here!  There seem to be a lot of
> > dependencies on this meta-data model within the runtime.
> > That's giving me
> > a rather queasy feeling.
> >
> > Russell Butek
> > butek@us.ibm.com
> 
>