RE: Approaches to WS implementation - does this make sense?

Ian,

In my book the essence of a good Web service is that it doesn't
impose how to implement or write code on other parties. 

Concentratingon the documents being exchanged rather than the code
which process them is a much better investment in the long term 
- a "customer" will long outlive some system you may currently have 
to process them in Java or whatever. 

Publishing a description of a service is difficult, and
although one might wonder why the industry standardised upon W3C
XML Schema to describe Web service messages exchanged, the fact it 
has offers tremendous interoperability across vendors.

However your concerns around the reality of poor interoperability 
between tools which consume Schema descriptions in WSDL, were 
discussed in some detail at the recent W3C Workshop on 
XML Schema 1.0 User Experiences:
http://www.w3.org/2005/03/xml-schema-user-cfp

The result has been for the W3C to form a new Working Group to
publish patterns of XML Schema intended to work well with vendor
supplied Web service toolkits:
http://www.w3.org/2002/ws/xsdb/

I'd suggest you consider participating in this working group, or
at least tracking its work and applying pressure to suppliers when
you encounter difficulties using their recommended patterns.


Paul




-----Original Message-----
From: www-ws-request@w3.org on behalf of Ian Graham
Sent: Sat 10/22/2005 9:30 PM
To: www-ws@w3.org
Subject: 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 Thursday, 3 November 2005 08:51:25 UTC