Isn't easy always good, especially when developing complex systems? I would say no, it is not always a good thing.
We currently have this kind of problem with Microsoft's implementation of web services. The situation is almost the same as we had with Visual Basic earlier. This was before it became a serious programming language for larger, multilayered, systems. It was extremely simple to build an application. All you had to do was to draw some controls and hit the F5 button. I remember that Gartner Group advised the market some years ago not to develop systems with Microsoft products because of this.
Unfortunately, the same now applies to web services. They too are very simple to create. If you in addition use DataSets as transfer objects then you are in serious trouble and probably heading in the wrong direction.
There are no easy ways to implement professional web services today.
In the future we will have better tools but this is not the case right now. You have to roll up our shirt-sleeves and do the messy work ourselves.
This conclusion and much more has Aaron Skonnard described in a new article in the MSDN Magazine. The following are some comments on his article.
Today we have two common techniques to define service contracts. "Implementation-First" is the method that Microsoft, and probably other vendors, uses by default. You first write your components and from these the underlying platform produces the contracts for you. This is the easy, but erroneous, way to go.
"Contract-First" is the other technique to use. It is this method that both Aaron and I prefer. He does a short introduction to this method. In the rest of this article I'll do make some comments on that method. Some are drawn from experience I have gained the last year when I have been working for a company that right now implements a service oriented architecture in a heterogeneous environment.
The two languages that you have to learn when designing web services according to contract-first is Wsdl and Xsd. Aaron suggests that we should start, after we have designed the system, to write the Wsdl files. From my experience is it very important that we don’t write the Wsdl first. We should start by defining types. A type is, for example, a civil number, implemented as a simple type, or an address, implemented as a complex type. Both simple types and complex types are parts of the Xsd specification. When you have these fundamental types you start combining them to even more complex types. It will ends with one complex type that describe the request of a method in the web service and one that describes the response. When you have done this, then you start writing the Wsdl file. This way is sometimes called "schema-first".
Why schema (Xsd) before the web service description (Wsdl)? If we design the schemas first, and if we are serious about this, we should only have one schema repository for the whole company or organization, the interoperability and reuse will be easier to maintain. If we start with the Wsdl it could be tempting to include the schemas in that file. It is this technique that Microsoft use when they atomically generate the Wsdl. This is called Russian Doll because every type and sub type is contained in the same file.
"... "Implementation-First" ... You first write your components and from these the underlying platform produces the contracts for you. This is the easy, but erroneous, way to go."
I don't agree here, Contract-First absolutely, but the contract have nothing to do with the "implementation-first" it has to do with the model (analyze, Design)-first. You never start building a solution if you don't have the design ready, and the contract will be an important specification for the design. The contract is also designed against the consumer at the first. Then when this contract is defined and the consumer thinks its ok you start building the service.
And this approach is general for all development processes. Or have I missed something?
I never start coding the domain if I don't have any specification, and for SOA you can’t have any specification if you don’t have the contract right?
As Pat Hallend put it when I talked with him "the messaging interface (contract) becomes the specification for the individual application (service)."
Please correct me if I'm wrong or have missed understood all this.
Best,
Johan
Posted by: Johan N2 | 2005-01-17 at 12.11
I agree with you that in the analyze and design phase it is allways contract-first. But what I talk about is the next phase, the implementation phase. It that phase you could either choose to start writing the code that implement the contract in VB or C# that you have designed before (implementation-first) or you could start designing the interface in WSDL and XSD first.
The question is more how you go from the design phase where your components are designed and described in a design document to the implementation phase.
Posted by: Dag | 2005-01-17 at 13.41