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

[Tech Rams <techmailing@yahoo.com>]

Right now you are inhouse, so you have the liberty to
do anything.
But the moment you have to expose, would you ask
others what their system is and accordingly generate
the consumer code, or just hand the WSDL to them? Many
systems generate their own custom code given a WSDL.

I like the annotation part, but instead of having your
build generate WSDL/XSD with embedded custom data, I
would rather generate the actual WSDL/XSD.

-rams

--- 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>
> 
> 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com