Web Services | Main
06.02.08
REST & SOAP/WS-* - two different views
For a very long time I’ve been promoting the SOAP/WS-* way of developing web services. After many discussions, articles and posts on the REST/SOAP war and some experimenting on my own I finally tend to prefer the REST way. The main reason for doing so are the advantages of loosely coupling services when going the REST way.
The most important difference when designing RESTful and SOAP/WS-* web services is their view on models and processes. In my opinion REST demands a complete new way of designing services. Stefan provides a nice example of RESTful design on InfoQ.
Ganesh Prasad delves in the differences (or similarities) by setting up a Namespace-Time continuum, which should unify both approaches. Mark Baker responds and Ganesh updates his view.
Mark argues that “WS-* fails to separate interface from implementation, while REST does”. He provides an example task of changing the implementation of an interface and asks the question: “if I change the implementation of a component from a stock quote service to a weather report, does the interface have to change? If yes, then prima facie you haven’t decoupled interface from implementation, have you?”.
Ganesh responds:
Now, as an architect, I am rather sensitive to issues of tight coupling, and have often railed against examples of this, such as the SOAP-RPC style itself and the generation of WSDL files from Java implementation classes. But Mark goes much further. He would like to change the implementation of a service from a Stock Quote service to a Weather Report, and he would like to see his interface unchanged! To my mind, this goes beyond the reasonable.
I especially like and agree with his statement that Mark’s change is like “changing from pasta to soup, and expecting to continue using a fork”. It appears to me that both are talking about the same thing from a different perspective. Mark refers to the “technical” generic interface provided by REST only, whereas Ganesh concerns himself with the service design.
The RESTful approach demands a mapping of service design logic to a combination of HTTP/REST verb and URI. Every combination has to be interpreted in order to get its meaning. In most cases the meaning is obvious, in some it isn’t. Thus the RESTful service design has to put a strong emphasis on a very slick choice of meaningful URIs, especially when setting aside a service definition, such as WADL.
Posted by Hartmut Wilms at 12:17
02.11.07
WCF v2 Features in .NET Framework 3.5
Christian Weyer has published some entries about the new WCF features of .NET 3.5.
In his first post he give a rough overview of the popular and not so popular new features. One of these features is the new Web Programming Model. Although support for RESTful Services is an important feature for the next version of the .NET Framework, I’m wondering, whether a slick light-weight solution (such as Mindtouch Dream), which remains true to the principles and simplicity of REST, isn’t much better suited than an all-in-one silver-bucket attempt.
Dominick Baier joins in and writes about Usernames over Transport Authentication in WCF.
In his most recent blog post Christian publishes a list of all updated/new WS-* specs in WCF v2.
Posted by Hartmut Wilms at 12:13
24.09.07
Astoria Updated for Visual Studio Beta 2
Project Astoria has been updated to run with Visual Studio Beta 2. Nicholas Allen has the details.
Posted by Hartmut Wilms at 14:00
29.08.07
Contract-first vs. Code-first Web Services Development
Dare Obasanjo is commenting on an InfoQ article entitled “Code First” Web Services Reconsidered. He states that the question shouldn’t be about whether you should prefer contract-first or code-first:
The only real consideration when deciding between “code first” and “contract first” approaches is whether your service is concerned primarily with objects or whether it is concerned primarily with XML documents [preferrably with a predefined schema]. If you are just moving around data objects (i.e. your data model isn’t much more complex than JSON) then you are better off using a “code first” approach especially since most SOAP toolkits can handle the basic constructs that would result from generating WSDLs from such types. On the other hand, if you are transmitting documents that have a predefined schema (e.g. XBRL or OOXML documents) then you are better off authoring the WSDL by hand than trying to jump through hoops to get the XML<->object mapping technology in your off-the-shelf SOAP toolkit to do a great job with these schemas.
According to Dare the main problem lies in the impedance mismatch between W3C XML Schema (XSD) and objects from your typical OO system. Every SOAP Web Service publishes a service contract, which described the document types based on XML Schema. The problem with XML Schema is that it offers a much more complex type system than any known OO language. Thus interoperability issues cannot be avoided when putting XML (De)Serialization to use, because simple types might be mapped correctly, but complex types often pose problems for the serialization engine.
Dare suggests to revert to RESTful Web Services, which omit the problem by simply doing without XML Schema based contracts:
One of the interesting consequences of the adoption of RESTful Web services is that these interoperability issues have been avoided because most people who provide these services do not provide schemas in the W3C XML Schema. […] That way XML geeks like me get to party on the raw XML which is in a simple and straightforward format while the folks who are scared of XML can party on objects using their favorite programming language and platform. The best of both worlds.
Although I have once rightly been put on the SOAP side of the Tilkov Scale, I’m starting to switch sides - for better or for worse …
Posted by Hartmut Wilms at 11:13 | Comments (2)
22.02.06
OOP 2006 - Contract-First vs. Code-First
Marcel und ich haben auf der OOP 2006 im Januar einen Vortrag �ber das Thema “Contract-First vs. Code-First” gehalten. Obwohl ich der Meinung bin, dass eine Kopie der Folien ohne den Vortrag selber nicht viel bringt, will ich die Folien keinem mehr vorenthalten.
Der Vortrag wurde im Stil eines Streitgespr�chs gehalten, in dem die Argumente f�r beide Seiten aufeinander prasselten. Aus diesem Grund finden im zweiten Teil der Folien schnelle Wechsel statt.
Posted by Hartmut Wilms at 10:23 | TrackBack
14.09.05
A hope for native XML support in C#: The LINQ Project
Yesterday I mused about an intuitive way of accessing XML messages and today I read about The LINQ Project:
The LINQ Project is a codename for a set of extensions to the .NET Framework that encompass language-integrated query, set, and transform operations. It extends C# and Visual Basic with native language syntax for queries and provides class libraries to take advantage of these capabilities.
It seems that Comega features have made their way into C# 3.0 sooner as I could have hoped. The C# LINQ features are demonstrated in an MSDN video. A technology preview can be downloaded here.
I’ve got to give the preview a try. Maybe all my hopes will be fulfilled in the “near” future. If Microsoft will some day succeed in shipping new releases, that is …
Posted by Hartmut Wilms at 13:45 | TrackBack
12.09.05
Is Microsoft doing the "hide-the-paradigm-from-those-dumb-developer-idiots" thing, again?
There is a “nice” discussion going on between Rich Turner and John CJ. Stefan already summarized and commented the highlights. If nothing else this post is intended to show that there is at least one reader of his blog, who is “.NET aware” ;-).
The thing which strikes Stefan and me most is, that John CJ stated in his last response: “At the heart of the internal model of Indigo is a very powerful concept of a message. Unfortunately, this conceptual model is never exposed to developers and architects directly.”. At first I was shocked and thought: No, this can’t be true. They couldn’t have done it, again. After calming down I read the comments by Stefan and John on John’s last blog entry, which fortunately made me relax, again.
The Process Message API, described by Don Box in this old post, still seems to be existing in WCF (Indigo).
I cannot understand John’s point. My best guess is, that he wants WCF to provide a message-oriented API as far as processes are concerned and an object-oriented API as far as data are concerned. This seems to be a little bit weird. Among many other benefits, which John and I agree upon, a major pro of message-oriented programming is, that message data are much more “loosely coupled” than objects. By serializing messages into objects, the message payload is bound to the classes generated from a single service description version. If the message payload changes, even by a minor, additional, optional element, every participant has to update its generated Classes, which represent the message payload. Is this “loosely coupled”? I doubt it.
What is missing, is a higher level XML API, which provides an easy and intuitive access to every message element and attribute.
Posted by Hartmut Wilms at 12:28 | TrackBack
18.02.05
Clemens Vasters on my "Wrong" post ;-)
Clemens Vasters comments on my answer to his post:
“Everyone writing DCOM apps must write and understand MIDL and NDR. Everyone writing CORBA apps must understand IIOP on a protocol level. Everyone who codes in C must understand x86 assembly. Correct?”
No, that’s not correct. There is a very, very important difference. The difference is about “logical” and “physical” protocols. or even better between contracts/interfaces and hard-wire protocols. On the other hand Clemens Vasters is right. Every model is passed through a transformation chain until it reaches “its final destination”. C is an abstraction of x86 assembly which in turn is an abstraction of “1001101001001…”. The trick is to decide when further transformation are of no importance to the developer.
Let’s take his example of CORBA and IIOP. Is IIOP important to the developer. No! Oh, I can hear your screams. I know about “IIOP Complete” by William Ruh et. al. This is surely a book worth reading. But I would like to reduce the required knowledge level to that of an application developer. Then, is IDL important to the CORBA developer? Well, yes and no. It is certainly helpful to know about IDL but IDL and C++, Java, and Smalltalk interfaces share a common paradigm: objects and OOP. Therefore the contract described by a C++ class is equivalent to the IDL contract.
Now, here’s my concrete answer: SOA is a paradigm based on messages/documents passed between participants. This is something completely different than invoking methods on a remote object by an RPC call. Indigo’s implementation first programming model resembles RPC calls. This may be applicable in certain contexts. And sometimes it is certainly preferable. But when SOAs are concerned stick to messages and documents, please. There is an Indigo contract first programming model. Use it by all means. But do care about the message-based SOA programming model, even if it is a little bit more, hm …, clumsy.
Maybe this has been a misunderstanding? Indigo has it all. Indigo rocks (when put to correct use) :-)!
Posted by Hartmut Wilms at 13:48 | Comments (4)
Wrong, wrong, wrong, and again: Wrong!
Clemens Vasters hasn’t given up on his anti-angle-brackets thing. It is useless to repeat all the arguments against his position, because so many people already did. Although he is right when he says that no one really enjoys authoring XSD, WSDL or policy files manually, it’s completely wrong to “start asking for tools that hide all those details”.
Never do this! Start asking for tools which help authoring XSD, WSDL, or policy files. Tools which don’t hide your contracts but help to understand them. This is not to say that APIs are bad. There are contexts which demand for APIs, even APIs which hide the contract details. But in most cases, especially when taking SOAs into account there is a great demand for APIs which closely resemble the contracts of the world you want to participate in.
I don’t want to annoy people with the details of XSD, WSDL or even worse WS-Policy. But everyone implementing a SOA MUST understand the basics and the paradigm!
Posted by Hartmut Wilms at 11:53 | Comments (3) | TrackBack
The many faces of Indigo
Tim Ewald is commenting on Indigo, again.
“What you’re doing may be ‘service oriented’ (whatever that actually means), but is it Web services? And if it’s not, will the fact that Indigo is using the same APIs to do very different things with very different implications going to help or hurt people?”
Actually I’ve been thinking about this question for a long time. Does making things as easy as possible really help people? This reminds me of Niklaus Wirth and his famous saying “Make it as simple as possible, but not simpler.”. Maybe Indigo is pushing the line too far, too simple that is. Providing a single means for doing very different things seems to be making development very easy and maintainable. But on the other hand developers and architects must not loose their grip on the underlying technologies and especially the paradigms. Service-oriented architecture is nothing you can buy but rather something you have to do and “live up to”. It is a software development paradigm with certain constraints and best practices which should ever be present when developing distributed systems. Hiding these facts from the developer may be a dangerous thing.
We will have to wait until the final release. Many things may still change and we will have to see how things work out. After all software development isn’t a black or white thing but a field of many, many shades of gray.
Posted by Hartmut Wilms at 11:00 | TrackBack
24.01.05
Generic Implementation Interface
Christian Weyer asks for additions to the WSCF wishlist. This made me think about parameter and return type handling in ASP.NET Web Services …
You can help us improve WSCF, now
Take a look here if you work with WSCF and just think: “well, it’s nice, but…”.
We want to hear your ‘but’. Thanks.
I haven’t had that much time to investigate WSCF 0.4, but I think the tool generates code in a single way, only, i.e. the way the tool (or the author) sees fit. It generates parameter classes which map to the types defined in the XSD file. Although this approach is recommended in many ASP.NET and Contract First forums, I think it is still one step from really being “losely coupled”. Why? Because your implementation is bound to the types in your service description/interface. If the interface changes chances are that you’ll have to change the implementation (of the client), too. This would destroy the most important reason for SOA being independence. Service-oriented architecture is all about reducing dependencies as much as possible.
In order to achieve this independence concerning parameters and return types the implementation should use XMLElement and XPath to access and deliver parameters, return types respectively. If the service changes (non-breaking changes!) and the client isn’t interested in the new additional features, it still would work, because all necessary data is fetched from the XML tree via XPath queries. This approach might seem odd, because C# is a strongly typed language and string queries aren’t really typed … But service description aren’t C# typed either. They are typed by the XSD/WSDL which should be the only service and data definition! There are some (few) sources for this approach:
I like to call this approach the “generic implementation interface”, because the implementation expects an “untyped” XMLNode, which is accessed in a generic way by XPath queries. The opposite is the concrete or typed implementation interface. Both approaches are valid. Sometimes it’s just more effective to generate typed parameters and the corresponding proxies. But in most cases the generic approach largely adds to the losely coupled idea. I still have to investigate how to implement this with ASP.NET Web Services. Maybe there are some serious drawbacks. The idea is to define the fully typed (XSD) WSDL and to use XMLElement or XMLNode parameters and return types in the implementation.
Therefore my most wanted WSCF feature is to make the generation process configurable, perhaps by introducing a template based approach. I know this is much asked for, but you asked, didn’t you ;-) ?
Posted by Hartmut Wilms at 10:51 | Comments (1)