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

[Tech Rams <techmailing@yahoo.com>]

OK...so as I see it, you have 2 issues with WSDL/XSD

1. It is slow to generate / use
2. It is not expressive enough - you are not able to
express all your contract details

While the first one can be specific to the
implementation, the second would be interesting to
this audience. What is in the contract that you are
not able to express in WSDL/XSD? If you can share
samples of that, we can then see if there are
real-life limitations to these standards, or if there
are other standards that can be used in tandem.

-rams

--- ian.graham@utoronto.ca wrote:

> Quoting 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.
> 
> We would hand over the WSDL and ask external parties
> to
> use that (plus hand over any other documentation we
> might
> provide: basically the contract information
> converted to 
> printed documentation )
> 
> > 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.
> 
> Ideally, yes: but doing so (at least for now, given
> today's technology) seems to mean that we get a
> productivity
> factor drop of 3-4. And as part of this drop we have
> to
> hand-code many of the contract rules in code, as
> opposed
> to expressing them in the contract. 
>  
> > -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
> > 
> 
> 
> 



		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com