Skeletons

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

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

DTD for WSDD

[Mark Volkmann <vo...@charter.net>]

Where can I find a DTD for WSDD?
Surely one exist somewhere.