[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: xml-dev@l...
• Subject: Re: Non-schema approach to web service design: comments?
• From: ian.graham@u...
• Date: Thu, 27 Oct 2005 23:13:35 -0400
• In-reply-to: <Pine.LNX.4.61.0510272033340.26756@m...>
• References: <1130439256.4361225849490@w...> <Pine.LNX.4.61.0510272033340.26756@m...>
• User-agent: Internet Messaging Program (IMP) 3.1

Quoting Vladimir Gapeyev <vgapeyev@s...>:

> 
> One doesn't need to know much about web services to ask: If your 
> application ain't broken (== serves its purpose well), what do you worry 
> about? ;-)

Several reasons to ask:

If we and others are doing this because WSDL isn't expressive enough for
service contracts, then perhaps there is a fundamental problem with WSDL
and XSD for this class of use cases: which would certainly be of
interest to this list (and to me/us).

We are just starting this exercise, so want to know if anyone thinks we
are doing things that may lead to long term problems. For example, if
this Java-centric approach tends to bias the service architecture in
inappropriate ways, we'd like to know how to avoid doing so.

If there is an equivalently good (as in fast/flexible) way of doing this
starting with WSDL/XSD, then we'd rather do that then do something
non-standard. Using standards makes it easier to find commercial and/or
open source tools. Home grown can be good up front, but can cause you
problems long-term (code and tool maintenance, for example). 
> 
> On Thu, 27 Oct 2005 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>
> >
> 
> -----------------------------------------------------------------
> 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>
> 
> 

• References:
  • Non-schema approach to web service design: comments?
    • From: ian.graham@u...
  • Re: Non-schema approach to web service design: comments?
    • From: Vladimir Gapeyev <vgapeyev@s...>

• Prev by Date: Re: Non-schema approach to web service design: comments?
• Next by Date: Re: Non-schema approach to web service design: comments?
• 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