On the whole, this stuff sounds good to me. Just two comments.
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.
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.
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.
Russell Butek
[EMAIL PROTECTED]
Glen Daniels <[EMAIL PROTECTED]> on 03/29/2002 05:42:49 PM
Please respond to [EMAIL PROTECTED]
To: "'Axis-Dev (E-mail)'" <[EMAIL PROTECTED]>
cc:
Subject: Skeletons
OK, here's my current thinking re: Skeletons and WSDL generation.
When I last talked with Russell, he said the fact that Skeletons were
classes was much more important than the particular API they used. Hence,
I'm proposing we move to the following:
interface Skeleton {
}
i.e. just a marker, because AFAIK no one ever intends to use the metadata
methods on an actual object, they're always going to be static on the
class. So the Skeleton marker indicates that your class should have the
following method:
public static OperationDesc [] getOperationDescsByName(String methodName)
...and an actual skeleton looks something like this:
public class TestSkel implements Skeleton {
static ParameterDesc [] testParams = new ParameterDesc [] {
new ParameterDesc(new QName("", "a"), ParameterDesc.IN, null),
new ParameterDesc(new QName("", "b"), ParameterDesc.INOUT, null)
};
static OperationDesc [] opers = new OperationDesc [] {
new OperationDesc("testMethod", testParams, new QName("",
"return"))
};
public static OperationDesc[] getOperationDescsByName(String
methodName) {
if ("testMethod".equals(methodName))
return opers;
else
return null;
}
public int testMethod(String a, IntHolder b) { ...call Impl... }
}
The idea is that you can fill in as much or as little of the information as
you want, and this becomes precisely equivalent to specifying the same
stuff in the WSDD. When it's time to actually get a "fully filled-in"
OperationDesc, we do the same introspecting-matching-caching that we do
normally to match up the OperationDesc with a Method, and to fill in any
missing stuff. So for instance, you'll note there are no types specified
for the parameters above, although the names are. So we'll figure out the
types via introspection. If there WERE types specified, we'd sanity-check
them as usual against the actual introspected types of the Method before
continuing.
This has two benefits - 1) we get to reuse the existing code/structures, 2)
the Skeleton code looks cleaner (IMHO). More on (1) below.
OK, so after this we are in a world where a ServiceDesc will exist and be
filled in correctly for classes with a) no metadata (use bytecode if
possible for names, and introspect for types), b) WSDD metadata, or c)
Skeleton metadata.
So the next big piece of this is to change the WSDL generation framework to
stop introspecting on its own, and just piggyback on the code that already
does this work in ServiceDesc. So WSDL generation essentially becomes a
matter of just walking the ServiceDesc and writing out the appropriate
WSDL. This will involve improving the ServiceDesc introspection framework
to walk up the inheritance tree like the WSDL code does now, which it needs
to do anyway. It will also mean adding an optional SOAPAction to the
OperationDesc.
I'm planning to do most of this work by Monday morning. Thoughts/comments
encouraged and appreciated.
--Glen
