[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Non-schema approach to web service design: comments?

• To: xml-dev@l...
• Subject: Non-schema approach to web service design: comments?
• From: ian.graham@u...
• Date: Thu, 27 Oct 2005 14:54:16 -0400
• User-agent: Internet Messaging Program (IMP) 3.1

[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 

• Follow-Ups:
  • Re: Non-schema approach to web service design: comments?
    • From: Anne Thomas Manes <atmanes@g...>
  • Re: Non-schema approach to web service design: comments?
    • From: Vladimir Gapeyev <vgapeyev@s...>
  • Re: Non-schema approach to web service design: comments?
    • From: Tech Rams <techmailing@y...>

• Prev by Date: Re: XML Schemas
• Next by Date: Recursive section validation
• Previous by thread: Re: XML Schemas
• Next by thread: Re: Non-schema approach to web service design: comments?
• Index(es):
  • Date
  • Thread