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:[EMAIL PROTECTED]] > Sent: Friday, March 22, 2002 2:33 PM > To: [EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > > > Glen Daniels <[EMAIL PROTECTED]> on 03/22/2002 12:20:00 PM > > Please respond to [EMAIL PROTECTED] > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED]] > > Sent: Friday, March 22, 2002 11:23 AM > > To: [EMAIL PROTECTED] > > 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 > > [EMAIL PROTECTED] > >
