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

Re: Non-schema approach to web service design: comments?

• To: Tech Rams <techmailing@y...>
• Subject: Re: Non-schema approach to web service design: comments?
• From: ian.graham@u...
• Date: Thu, 27 Oct 2005 23:15:20 -0400
• Cc: xml-dev@l...
• In-reply-to: <20051028003733.91522.qmail@w...>
• References: <20051028003733.91522.qmail@w...>
• User-agent: Internet Messaging Program (IMP) 3.1

Quoting Tech Rams <techmailing@y...>:

> 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@u... 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
> 

• Follow-Ups:
  • Re: Non-schema approach to web service design: comments?
    • From: Tech Rams <techmailing@y...>

• References:
  • Re: Non-schema approach to web service design: comments?
    • From: Tech Rams <techmailing@y...>

• Prev by Date: Re: Non-schema approach to web service design: comments?
• Next by Date: save XML into database
• Previous by thread: Re: Non-schema approach to web service design: comments?
• Next by thread: Re: Non-schema approach to web service design: comments?
• Index(es):
  • Date
  • Thread