axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: Skeletons
Date Sun, 31 Mar 2002 13:44:09 GMT

Hi Russell!

> 1.  I would prefer that the Skeleton interface contain the method
> getOperationDescsByName.  It doesn't cost much.  The 
> skeletons can still
> implement the static method, and the instance methods could 
> do nothing more
> than call the static method, but the instance method DOES buy 
> us something.
> It allows us to call the method directly rather than 
> introspect on it if we
> have the skeleton class itself.

I assume you mean "the skeleton object itself", and I'm not sure there's really going to be
a case where we will, since the introspecting is all happening on a Class level.  I guess
I'll leave it for now, but I'll call it getOperationDescsByNameInstance(), because I think
it's nicer to leave the "core" name on the static method as that'll be the one most used.

> 2.  I had hoped at one time that we could keep the emitters 
> separate from
> the runtime.  But I've virtually lost this battle over time.  They've
> gotten more and more interdependent.  Replacing the WSDL generation
> framework's introspection with the ServiceDesc introspection 
> is just one
> more nail in this coffin.  Since it seems a hopeless case to pull the
> emitters and runtime apart, maybe I should just stop whining. 
>  Just felt
> like whining one more time.

Hmm... I'm not sure that your concern here is really warranted.  If you think about it, what's
going on is that we're putting a design around the concept of "a structure that represents
services/classes, operations/methods, and their XML-related metatadata".  This stuff doesn't
tie in to the whole Handler architecture, or to the Serializer/Deserializer system, or even
to the MessageContext or Message structure - it's really quite well modularized, I think.
 If you take a look at the code in ClassRep/MethodRep/etc, you'll note some really striking
similarities to what we're now doing in ServiceDesc - so I just want to coalesce all this
into using a single model.  I don't think that ties the Emitter code particuarly tighter to
the rest of the engine, only to this model.

> One question:  you still believe it should be a fault if the meta data
> exists in BOTH WSDD and skeleton, right?  So WSDL2Java will emit the
> metadata in either the deploy.wsdd OR in the skeleton, but never both.

Yup.

--Glen

Mime
View raw message