[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?
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@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> >
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|