Serializing interface contracts

[Simon Laws <si...@googlemail.com>]

As an alternative to writing out WSDL I'm wondering whether it will be
more effective/efficient to just write out our internal interface
model. I put code in to write out the WSDL and (most of it) is live in
the build again however It concerns we as we always end up generating
WSDL and, given the way it is at the moment, there is a danger that we
end up transferring arbitrarily large associated XSD across the domain
just for interface matching purposes.

So firstly is there some code somewhere that is already able to
serialize our internal interface contract model?

If no what do I need, Well I just need the interface operations and
their input, output and fault types so that I can reconstruct the
contract just for matching purposes. As usual the tricky bit is the
data types. I think the only thing that's required is the logical
types. Is this practical or am I missing something?

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: Serializing interface contracts

[Simon Laws <si...@googlemail.com>]

On Wed, Sep 7, 2011 at 5:09 PM, Simon Laws <si...@googlemail.com> wrote:
> As an alternative to writing out WSDL I'm wondering whether it will be
> more effective/efficient to just write out our internal interface
> model. I put code in to write out the WSDL and (most of it) is live in
> the build again however It concerns we as we always end up generating
> WSDL and, given the way it is at the moment, there is a danger that we
> end up transferring arbitrarily large associated XSD across the domain
> just for interface matching purposes.
>
> So firstly is there some code somewhere that is already able to
> serialize our internal interface contract model?
>
> If no what do I need, Well I just need the interface operations and
> their input, output and fault types so that I can reconstruct the
> contract just for matching purposes. As usual the tricky bit is the
> data types. I think the only thing that's required is the logical
> types. Is this practical or am I missing something?
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>

So I knocked up a quick internal XML representation for interface
contracts that looks something like,,,,

<zdef-1667636070:interfaceContract
    xmlns:zdef-1667636070="http://tuscany.apache.org/xmlns/sca/1.1">
    <zdef-1667636070:interface isRemotable="true">
        <zdef-1667636070:operation name="callback"
            isDynamic="false" isNonBlocking="false" isWrapperStyle="false">
            <zdef-1667636070:input>
                <zdef-1667636070:dataType
                    dataBinding="java:simpleType">
                    <zdef-1667636070:generic>class java.lang.String
                    </zdef-1667636070:generic>
                    <zdef-1667636070:logicalXMLType>

<zdef-1667636070:xmlType>{http://www.w3.org/2001/XMLSchema}string
                        </zdef-1667636070:xmlType>
                    </zdef-1667636070:logicalXMLType>
                    <zdef-1667636070:physical>java.lang.String
                    </zdef-1667636070:physical>
                </zdef-1667636070:dataType>
            </zdef-1667636070:input>
            <zdef-1667636070:output></zdef-1667636070:output>
            <zdef-1667636070:fault></zdef-1667636070:fault>
        </zdef-1667636070:operation>

etc.

This removes the need to writing/reading WSDL and associated schema
and holds the basic information required for matching. Java complex
types are still an issue of course but I'm more confident with this
than trying to serialize/deserialize the WSDL. Ultimately I'd like to
provide domain level access to artifacts (includes WSDL/XSD namespace
qualified artifacts) that makes reverting using plain WSDL more
natural but that's a bigger job for another day. We could probably do
a pretty decent job of creating locators that look for remote namspace
based artifacts in the domain before going to look for them online and
hence remove the need to actually stream all the dependencies of a
particular WSDL.

It's interesting doing this as it allows me to look at what the
internal interface model looks like in various situations. I still
don't understand all the various combinations and I'm pretty sure
there will be things I've missed but it's an education. I've left all
the WSDL writing/reading code in there in case we want to turn it back
on at some point.

Simon


-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com