New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
How Relevant Is Contract First Development Using Angle Brackets?
Posted by Dilip Krishnan on Jul 09, 2009
Christian Weyer of Thinktecture, announced the release of WSCF.blue a Visual Studio Add-in that enables contract first development of web services using WCF.
It has been a long time where I originally built the Web Services Contract First tool...
This tool - briefly called WSCF - (available both as a command line utility and a simple Visual Studio add-in) was targeted at the ASMX platform.
The idea of contract first development has been around for a long time. The need for contract first arises from the need for a canonical representation of the shape of the messages that flow to and from a service in the form of web service requests. Most popular languages support WSDL and XSD based tools and Schema and WSDL based representations of these message “contracts” as a starting point is arguably a sound approach to having an interoperable solutions.
The contract first development style addresses the impedance mismatch between objects and XML. Since Xml Schema language is a richer representation format its easy to model the contracts taking into consideration the differences to pare down the serialization and interoperability problems, some of which include
- Inability to map certain constructs of the schema language for e.g. XSD type extensions and restrictions.
- Inability to mapping or at least efficiently map certain object types to schema types for e.g. Generic lists, HashMaps etc.
- Inability to represent object graphs effectively in XML especially in Parent/Child relationships where the Parent holds the reference to the children and the Child holds a reference back to the parent object.
Some advantages of using this approach are
- Defining language agnostic contracts promotes interoperability, provided service designers adhere to WS-I interoperability standards
- Promotes reuse of contract definition artifacts across the enterprise i.e. XSD and WSDL
- Allows for controlled versioning of services and lends itself to better governance eventually.
WCSF.blue is Visual Studio 2008 add-in is an open source project hosted at CodePlex. The capabilities of the tool as listed include.
- A WSDL Wizard that allows the developer to step through the creation of a WSDL from one or more XSDs
- A DataContract generator (similar to XSD.exe, XSDObjectGen.exe and Svcutil.exe) that generates the . NET equivalent of the XSD types
- A service/endpoint stub (SVC) generator and
- A client proxy generator.
The tool still has a list of known issues, which will hopefully be ironed out by the time the product comes out of beta. The tool also has a walkthrough from the 0.7 version of the WSCF.classic add-in that is still relevant for the most part. Given that Microsoft WCF supports contracts in code, no angle brackets, XSD or WSDL required, how important is it to have tools that focus on modeling message and service contracts using WSDL and XSD?
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
WSDL First
by
Jean-Jacques Dubray
Posted
It's important
by
Ronny Birkeli
Posted
-
It is actually quite sad that in 2009 the .Net world does not really have a WSDL-first capability nor even understand the difference between Contract First (which WCF suppports) and WSDL-first which it does not. I have used WSCF v0.7 a couple month ago and the code that was generated was broken and needed to be fixed by hand. I am sure it would be easy to fix, but ... wsdl2dotnet would be a great step forward for .Net SOAs.
-
We're currently working out the data contracts and interfaces of a set of web services. The job is a joint effort between our company and an international partner. We're on .Net, they're on Java. We used XMLSpy to work out and agree on the XSD's and the naming of methods. It's a simple, fast and "technology neutral" way to agree on the contracts without going to deep in code. Even the business people where able to follow ;-) What I feel is important is to have a good and simple methods and tools to take those XSD's and producing my service interface and data contracts. I don't feel I have that within Visual Studio today.
Another thing is that by "hiding" the XSD's and WSDL's the .Net world is distancing them self from the underlying technology of services which isn't good for anything in the long run.
2 comments
Watch Thread Reply