[
Lists Home |
Date Index |
Thread Index
]
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? ;-)
VG
On Thu, 27 Oct 2005 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>
>
|
