W3C home > Mailing lists > Public > www-ws@w3.org > November 2005

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

From: Ian Graham <ian.graham@utoronto.ca>
Date: Sat, 05 Nov 2005 10:17:05 -0500
Message-ID: <436CCCF1.5040608@utoronto.ca>
To: paul.downey@bt.com, www-ws@w3.org

Paul --

Thanks you very much for your reply, and comments.

FYI, I've had some follow-up discussion of this topic (sort-of an 
x-post) on XML-dev - see
http://lists.xml.org/archives/xml-dev/200510/msg00281.html
and follow-ups.

The discussion there makes me think there are two issues at the core of 
  our difficulties. These issues are potentially (but not guaranteedly) 
generic to other implementors/users.

The first is that specifying rich service contracts requires generic 
co-constraints and custom 'types' (like validation checksums). These are 
not generally possible using XSD. For the cases where they are (like 
some co-constraints) the available XSD mechanisms force you to take a 
simple business constraint and contort it into a complex, non-intuitive 
schema rule.

To put it another way, our developers want to express the contract as 
completely and easily as possible, and have a single 'book of record' 
for this contract.  The inability to specify custom types and 
co-constraints makes this difficult/impossible, and is seen as problem.

The second issue (likely mostly due to tooling limitations)is that the 
WSDL/XSD approach does not work well within an iterative development 
activity that incorporates service designs. Within this approach are 
constantly 'revving' services within the development lifecycle, as new 
requirements are implemented.

Currently WSDL/XSD tooling makes it hard/expensive to modify a defined 
service.

I will see what I / we can do about getting more engaged in the W3C work 
in this area. At worst I will keep an eye on the lists / projects you 
mention.

With thanks -

Ian

paul.downey@bt.com wrote:
> 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 Saturday, 5 November 2005 15:17:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:50 GMT