[
Lists Home |
Date Index |
Thread Index
]
[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
|
