Approaches to WS implementation - does this make sense?

I want to describe our approach to service development, and get some 
feedback: Has anyone else tried this?  Does this make sense?  And if not 
sensible, what are the problems with it)?  I should point out we are 
building agile-y, and so want easy refactoring of all code -- including 
service interface specs. We are also building on a websphere service 
provider, with (for now) .NET and websphere service consumers. This is 
an internal project, so we 'own' all interfaces (at least for now).

The approach we have taken seems to be driven by two factors:

- the incompleteness / difficulty of using XSD for expressing
   service contracs
- the poor quality of tools that take in WSDL/XSD to generate
   service implementations (in Java).

We define the service contracts in Java, using xdoclet to annotate 
classes/methods with the contract rules. We use standard xdoclet tags, 
plus some tag extensions to support custom types and constraints.

The build process for the service provider creates code for the 
constraints and the services interface. The build also generates  WSDL 
and XSD files characterizing the interface. The XSD files, are, however, 
pretty thin: much of the contract richness is embedded as annotations 
inside the XSD. These annotations are written using our own simplified 
constraint notation.

We have a simple .NET tool (partly home-built) that takes the WSDL/XSDs, 
plus the embedded annotations, and creates appropriate service consumer 
code (and constraints), on the .NET client. We can do similar things for 
a java consumer.

The team sees three big advantages to this over starting with WSDL/XSDs:

1) the xdoclet annotations express business-relevant constraints
    more easily (to developers) and completely than XSD. In
    particular, they can express checksums and co-constraints,
    fundamental business constraints not expressible in XSD.
2) the development cycle is much faster than when starting with
    WSDL/XSD. Changing a service provider is as simple as changing
    the xdoclet tags and re-building. Rebuilding the .NET (or
    another java) consumer is also easy. Starting with XSD/WSDL,
    on the other hand, requires much labor to re-bind the
    constraint code to the generated provider interface
    classes (with current  tooling, most of the constraints
    need to be hand-coded).
3) We get us a single (in java) 'book of record', in machine
    and human-readable form, of the entire service contract.
    This is not possible using as-is WSDL/XSD since there are
    contract rules (checksums, etc.) not expressible in XSD.

Some concerns raised have been:

a) Java-centred service design is a bad idea, as the overall
    service architecture will be biased to the Java model
    (so should start with WSDL/XSD)
b) Approach could leave you high and dry in the future if
    xdoclet withers away.
c) Custom non-standard way of expressing interface
    constraints is bad - forces us to maintain in-house
    expertise to maintain this .

Thoughts?

Ian
-- 
Ian Graham
H: 416.769.2422 / W: 416.513.5656 / E: <ian . graham AT utoronto . ca>

Received on Sunday, 23 October 2005 05:01:29 UTC