Let me chime in.
A) Skeletons are emitted code that users don't see. So my belief is that
any reasonable implementation is acceptable. (This differs from my
viewpoint about emitted Java Beans, which is I am a strong proponent of a
Helper class...)
B) The runtime's dependency on the Skeleton is a bit of a concern. Glen
proposes that the "Operation Desc" model be used by the runtime in both
cases. I agree that this allows for sharing (a very good thing), but I do
have some concerns about changes in the model. For example if the model
changes, code emitted several months ago will no longer work... Perhaps the
model will stabalize soon (?) An alternate approach is to support a
"dispatch" method on the skeleton, the skeleton could then be written to
contain its own way of determining which method to dispatch from the
parameter names and arguments. So I would like flexibility to add such an
approach in the future.
C) The WSDL generation code is another concern. It seems like ?wsdl should
return the original wsdl instead of intropspecting the class. Or the
skeleton could contain the actual text of the original wsdl. (Actually I
have done some work on this in my implementation of the Bean Helper class).
So +1 to Glen's changes, but I don't want anyone to be surprised in the
future if IBM wants to put in some reasonable hooks to provide an alternate
implementation.
----------------------------
Russell and I are very interested in putting hook points in the
architecture. Sometimes the hook points are necessary for release
stablization, sometimes they are necessary to productization, sometimes
they are necessary for integration with IBM products, and sometimes they
are necessary for IBM value add work.
So when we do have disagreements about something (for example meta data
models), we are not dis'ing the technology. We are just concerned about
having our own plug points to provide an alternate solution. (I think the
meta data model being evolved by Glen is a great way to fix a lot of
problems. The addition of the model improves Axis. But the meta data
model is still evolving and we want the ability to provide alternate
choices for our customers.
Now if Russell and I were not contributing any code (and only whining about
plug points) then it would be reasonable to dismiss our concerns. But I
think we have contributed to evolving the Axis code base over the last nine
months.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Glen Daniels
<gdaniels@macrome To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
dia.com> cc:
Subject: RE: Skeletons
03/31/2002 07:44
AM
Please respond to
axis-dev
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
