Re: [xml-dev] Non-schema approach to web service design: comments?

[Anne Thomas Manes <atmanes@gmail.com>]

A good web services/SOA mailing list: 
service-orientated-architecture@yahoogroups.com

On 10/27/05, ian.graham@utoronto.ca <ian.graham@utoronto.ca> wrote:

[Also: Anyone know of a good web service mailing list?? I certainly
can't find one .... ]

I want to describe our approach to Web service development, and
get some feedback:has anyone else tried this?  Does this make
sense?  If not, why. etc. ?

Background: we are using continuous integration, so need
easy refactoring of all code, including service interfaces.
We use websphere as our service provider, and have (for now)
.NET and websphere service consumers. This is an internal
project, so we 'own' all interfaces (at least for now).

We do not use WSDL/XSD to 'define' services. Instead the
dev team uses xdoclet/JCF to decorate java classes with
annotations defining the contract.  We have created xdoclet
extensions to support custom constraints (e.g. checksums).

The build generates the service provider code, along with WSDL
and XSD files: the XSD's including <annotation>s in a custom,
machine-readable format detailing the contract rules not
expressed in the Schema. Indeed, today very little of the
contract  is in the XSD: the goal is to place as much as
possible in  XML Schema, the rest in the custom format.

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).  We can
do similar things for Java consumers.

What was the rationale?

- Speed.  This approach is 2-4 times faster than one starting
  with WSDL/XSD (done on a previous project). This is particularly
  true when modifying/refactoring a service.
- Simplicity. the annotations express business-relevant
  constraints more easily (to developers) and completely than
  XSD. In particular, they can specify constraints like
  checksums and co-constraints, that are fundamental to the
  contracts but that are not expressible in XSD.
- Simplicity 2. We get a single (in java) book of record
  for the contract -- whereas when we use WSDL/XSD we end
  up with part of the contract in XML, and part in text
  documentation (checksums, etc.).

Some concerns raised have been:

- Java-centred service design is a bad idea, as the overall
  service architecture will be biased to the Java data and
  component model (so should start with WSDL/XSD)
- Approach could leave you high and dry if  xdoclet/JCF goes away.
- Just Plain Bad to use a Custom non-standard approach.

Thoughts?

Ian
--
ian DOT graham AT utoronto DOT ca


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: < http://www.oasis-open.org/mlmanage/index.php>