Gridshore » webservices

SOA component design: thinking about error handling

Ben — Sat, 26 Jul 2008 20:08:27 +0000

When designing components for a SOA landscape (or any multiprocess system), the primary concern is with the communication behavior of the component: how messages are passed to and from the component and in what order, what those messages are and what constitutes a valid message and what doesn’t. When the time comes to implement the component, related concerns come into play: how are messages projected from the communication language into the domain model and into the implementation language, how are communication patterns met and ensured, et cetera. In addition the project technical architect has to consider how to implement the component’s domain without hardlinking it to any other components whose domains are known or to the communication medium du jour (unless the component’s purpose is linked to that medium).

Now here’s the strange thing: with all the concerns that go into design of components at all levels (from the enterprise architect down to the developers of the different components), one of the most overlooked things in SOA component building is the handling of cross-component error handling.

Error handling concerns

The fact that error handling is often the lowest-priority concern is doubly weird if you consider that cross-component error handling is the same concern as core functionality messaging. In both cases there are the same sets of concerns, both with regards to communication with external components and interaction between the component’s internal implementation and the communication layer. Some typical concerns that development teams have to deal with are:

Error message definition: Just as SOA components require clear definitions of the messages that will be exchanged with client components for mainline communication, clear definitions must also be given of messages that carry error information.
Error communication behavior definition: Just as mainline communication behavior between SOA components must be clearly and formally defined, so must similar definitions be given for when a component can send an error message in response to a request for operation.
Projecting exception types from the domain language onto error types from the communication language: In the case of error handling, this is one half of a problem that also exists for mainline communication. In mainline communication request messages must be projected onto domain model types and domain model types must be projected onto communication language types when the component returns a response. In the case of error handling of course there is no concept of request projection since nobody requests an error; however, the analog with projecting a domain model type onto a response communication message remains.
Maintaining component independence: This concern actually affects a component more as a consumer of other services than as a publisher of services. Maintaining component independence is related to avoiding domain models leaking over into foreign components (as Eric Evans puts it). In the case of messaging it means not building your domain model so that it is a mere copy of a foreign component’s communication model. In the more specific case of error handling it relates to not linking error handling too closely to the definition of errors used by foreign components. Instead, as with mainline messages, foreign component-generated errors should be projected onto the local domain model’s concept of errors or exceptions.

Balancing error handling strategies

Another concern in error handling (in addition to the ones mentioned above, which occur in all message processing systems) is introduced when communication layers introduce their own concept of error handling. A typical example of this is the WSDL/SOAP combination with its SOAPFault concept of error messaging. These built-in mechanisms can be very convenient in that they dictate an error handling strategy and leave you nothing to think about in your design. Not to mention that standardization is very valuable in these systems: it introduces an error handling strategy that everybody can agree to. However, there is also an inherent risk that these standardized error handling mechanisms will hardlink your component to a particular communication layer or framework (especially if the mechanism is allowed to leak through into the component’s inner domain model).

It is clear that each project must find a way to balance concerns in cross-component error handling strategy. Several strategies exist and must be considered:

Ignoring the communication layer’s mechanism

Doubtlessly the simplest strategy is to ignore the communication layer’s error handling mechanism. Instead one of several possible alternatives must then be considered. A simple alternative might be not communicating errors across components ever (this might for example be an enterprise policy) but allowing “empty” responses instead. Or else a project might define its own error reporting as part of regular messaging, creating either/or responses (i.e. responses that contain either a regular response or an error).

The upside of this strategy is its simplicity, plus the fact that it is guaranteed to keep the component implementation separate from the communication layer. However, client components (especially third-party ones) are not likely to appreciate the divergence from standardized mechanisms — making this a strategy that is only suitable for components that are for internal use only.

Using the communication layer’s mechanism

This strategy is more or less the other extreme of ignoring the communication layer’s mechanism. The choice here is to take the mechanism (and its reflection in the implementation language) and incorporate that throughout the component’s implementation. For example, a Java project might elect to use AxisFaults throughout the project instead of project-specific exception types.

Again, the upside of this strategy is its simplicity, plus its guaranteed interoperability with the communication layer. However, the component is now hardlinked to the communication layer. This is not necessarily a bad thing: there are projects and components whose purpose in life is linked to a single communication layer. A custom integration layer for different SOAP web services for instance might want to use SOAP Faults and related types for error handling (since it is technically part of the domain). In general though, this strategy will limit the component implementation’s future flexibility.

Mapping internal error handling to communication layer error handling

The final option seeks to combine the best of both worlds, separating the internal domain model from the specifics of the communication layer and allowing the two to touch only through a translation layer. This strategy also allows the internal component implementation to be linked to several different communication layers. For example, a component implementation might report errors using java.lang.Exceptions. Different translations might translate these exceptions into SOAP Faults for a SOAP web service publishing, a JMS exception for JMS and a specific error page for a RESTful service.

Architecturally this probably sounds like the go-to strategy for all situations. And factually this is probably the option that most projects will want to use, since relatively few projects want to be hardlinked to the communication layer. However, it is more work to implement, especially if the projection of domain errors onto the communication layer is not simple to implement.

Conclusion

Error handling is one of the most overlooked topics in the design and implementation of SOA components. However, it is at least as important as the design and implementation of mainline messaging and functionality, for the same reasons. And like mainline functionality, error handling requires some careful forethought and weighing of options. Different strategies are available, each with its own characteristics with regards to implementation difficulty and ease of use. Projects must consider very carefully which strategy fits project goals and expected future usage patterns.

Feeling secure with Web Services – Part 3 – Digital Signature

Allard — Sun, 01 Jun 2008 15:10:55 +0000

There seems to be a lot of misunderstanding about Web Service security. Using password authentication doesn’t prevent unauthorized users to access your data, while SSL / HTTPS doesn’t give you any information about who is trying to access your services. And did you ever think of signing you messages with a digital signature?

In my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.

In part 1 , I’ve dealt with Username Token authentication, an easy to use way to provide an authentication mechanism for your web service.

In part 2 , I have described Transport Layer Security (TLS) -formerly known as Secure Socket Layer- and message encryption.

In this part, the last one in this series, I will explain how the the digital signature can provide some form of security in web services.

Lets recap the security requirements I have discussed in my introduction .

The client must be sure it sends it messages to the correct provider;
The provider wants to be sure that the client is authorized to;
The provider wants to be sure that the client is who it says it is;
Both the consumer and provider want to be sure that the messages can only be interpreted by each other;
Both parties want to be sure that the message sent is received unchanged.

So far, we have dealt with the first four requirements by implementing Encryption or TLS/SSL or by requiring a UsernameToken from the client. But until now, we are still not the guaranteed that the messages are unmodified since we’ve sent them.

Encryption will prevent modification during the transport between the sender and the final recipient, the one with the private key to decrypt the message. However, once decrypted, the message is free to be modified.

Digital invoices are an example of documents that should be digitally signed. In some countries (in The Netherlands in any case) the Belastingdienst (Tax authority) requires that all digital invoices are digitally signed by the company sending the invoice. This way, the Belastingdienst is able to verify who sent the invoice -the one who signed it- and be sure that it hasn’t been tampered with in the meantime. Of course, the company receiving this invoice wouldn’t really mind to have these guarantees too, I suppose.

Now that we have a real valid use case and are really convinces of the need of the digital signature, let’s have a look at how it works.

Actually, it is almost identical to encryption, but then in the opposite way. With encryption, the message is encrypted using the public key. Only the one with access to the private key can decrypt it. When signing, the private key is used to sign the message, and the public key is used to check the signature. Since access to the private key is limited to authorized people/machines, only they can sign the message. Anyone can access the public part of the key -hence “public”-, meaning that anyone can check the signature.

When a message is signed, the actual message itself is not encrypted. That wouldn’t be very meaningful, because that would mean that anyone would have to decrypt the message, even though they might not really care about the signature. Instead, a hash is creating from all the parts that have to be signed. That hash is then encrypted using the private key. The encrypted has is then inserted in (the header of) the message. Typically, one would also include the public key, to allow anyone to check your signature. That’s it.

To check a signature, the hash is recreated the same way as it was done originally and the encrypted hash from the signer is decrypted. If the message has not been tampered with, the newly generated hash and the decrypted original hash are identical. If they are different, you know the message has been tampered with.

The signature on the message will ensure the reader that the message has not been modified since it has signed sent and that the contents were created by, or created with the consent of, the user who signed it. If you want to see it in action, you can download the example code from the Gridshore google code repository. The demo uses all three forms of security described in this series.

This concludes this three-part article about web service security. The type of security you would choose for your web service clearly depends on the needs of your specific service. UsernameToken provides for an easy to use authentication mechanism, while TLS or message encryption prevents a third party from reading the messages. Finally, the digital signature will ensure that a message is not modified after it is signed.

Feeling secure with Web Services – Part 2

Allard — Mon, 26 May 2008 19:23:04 +0000

In my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.

In part 1 , I’ve dealt with Username Token authentication.

In this article, I will describe Transport Level Security (TLS), formerly known as Secure Socket Layer and message encryption.

Lets recap the security requirements I have discussed in my introduction.

The client must be sure it sends it messages to the correct provider;
The provider wants to be sure that the client is authorized to;
The provider wants to be sure that the client is who it says it is;
Both the consumer and provider want to be sure that the messages can only be interpreted by each other;
Both parties want to be sure that the message sent is received unchanged.

Transport Level Security

Using “Transport Level Security” (TLS), formerly known as Secure Socket Layer (SSL), and also referred to as HTTPS, will take care of requirements 1 and 4.

TLS is a technically very complex algorithm, with a lot of varieties. Fortunately, the general concept is not as hard to grasp. It works as follows:

The client will send a “Hello” to the server.
The server will response with a “Hello”, and send a certificate to the client
The client will decide whether it trusts the server’s certificate
The client will use the servers certificate to encrypt its own certificate and send it back to the server
Depending on the exact algorithm chosen, the client and server will exchange some more encryption information to make the communication “water tight”.

If you really want to know the technical details of TLS, have a look at this page: http://an.wikipedia.org/wiki/Secure_Sockets_Layer. For the typical Web Service developer, these details are not really important. However, knowledge of how the first three steps work can help you prevent a lot of problems.

Especially step 3 is of great importance. The client has received a certificate from the server, and has to decide whether it is safe. This decision is based on a few factors.

First of all, the certificate has to have been issued for the domain that has been requested. So if you access a service on http://somecompany.com/service and get a certificate issued for someothercompany.org, the client will reject the certificate. Some clients, such as web browsers allow the users to override this decision and accept the certificate anyway. A web service client doesn’t typically have a user, so there is no room for second chances.

Secondly, the certificates timestamp has to be valid, meaning that it hasn’t reached it’s expiry date yet. Depending of the type of certificate, it is valid from 1 to tens of years.

The third requirement can sometimes give some problems: the client has to trust the certificate. This can best be explained using a real life example. Imagine yourself at the border control on a foreign airport. If you show them a paper with your name and a signature on it, chances are small that they let you through? Why? Because they can’t trust a self-signed certificate, or one that is signed by a relative. However, if that same name is written on a legal passport, given and signed by your country’s authority, border control will trust it, because they trust them. In TLS, it is exactly the same.

If you order a certificate from a certificate authority (CA), nobody will actually know that you have that certificate. And you don’t trust what you don’t know. However, you have paid the CA to sign your certificate. And maybe the CA certificate has been signed with yet another certificate. Now, if you trust the CA, you will automatically trust all certificates that have been signed with that CA. Back to our border control. If you trust the US government to issue correct passports to people, you will automatically trust all passports of US citizens, even if you don’t know that person.

To mark a certificate as trusted, the certificate has to be stored in a so-called “trust store”. Your browser has a truststore that includes the large CA certificates by default. Just look around in the configuration of your browser. You’ll be able to install other certificates if you like. For example, one that you have created and signed yourself.

You can also configure a truststore for your web service client. By default, your JVM will probably include the large CA certificates, such as Verisign and Thawte. If you’re running on an application server, chances are big there is a trust store configured in them, too. Of course, you can override the truststore by defining your own.

Ok, now that we’ve seen a lot of misery on the client side, let’s have a look at what has to happen on the server side. Well, luckily, not all that much. All you have to do is configure your web server to use SSL. Somewhere along the line it will require you configure a certificate to use. And since you probably want to be trusted, make sure to have your certificate signed by a large CA.

The good part is that all communication between client and server is encrypted in such a way, that only these parties are able to read the messages. And, as a bonus, the client is ensured that it is really talking to the server it was expecting to communicate with.

Message encryption

TLS is nice, but if you have a message that will pass a few endpoints, or has to be logged in the mean time, it doesn’t really help you. If you have to keep your data secure after is has arrived at your first endpoint, message encryption could be your solution.

Let’s start off with an example. Let’s image we have a service where consumers can place orders. Just for the sake of the example, the request will first be processed by an endpoint that checks the stocks. If the stocks are sufficient, the payment is processed. If TLS were used between the consumer and the first endpoint, the message would be sent unencrypted. Of course it is possible to encrypt that communication too, but that would probably be a performance hit.

The idea behind encryption is not really complex. The entire message, or part of it is encrypted using the public key part of the certificate. Since the private key is required to decrypt it, only the recipient (or at least only systems with access to the private key) will be able to so. Even if a message is stored for future reference, the contents will be unreadable to any third party.

Typically, only parts of messages are encrypted. You could think of elements containing payment information or other private contents, such as social security numbers. The example project in go ogle code shows an example of a message where an ID is encrypted. Not a really powerful use case, but it shows how the technology works.

As with TLS, message encryption will deal with items 1 and 4. However, it will only do so for the parts of the message that have been encrypted.

Conclusion

Both TLS and message encryption give the communication between consumer and provider some form or privacy and protection against eavesdropping. If configured correctly, they can work transparently to the implementation of both the client and the consumer, but will claim some of your performance.

My next and last article in this series will discuss message signing, which will deal with the security item that hasn’t been covered yet: “Both parties want to be sure that the message is received unchanged”.

Feeling secure with Web Services – Part 1 – The UsernameToken

Allard — Tue, 20 May 2008 19:25:59 +0000

Recently, I’ve been helping a customer with some Web Service issues. One of the problems was their limited knowledge of security in that area. He asked me to explain, in Jip and Janneke language [1] how SSL works and what it actually secures.

There seems to be a lot of misunderstanding about Web Service security. Using password authentication doesn’t prevent unauthorized users to access your services, while SSL / HTTPS doesn’t give you any information about who is trying to access your services. And did you ever think of signing you messages with a digital signature?

In my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.

This article will go more in-depth in the Username Token authentication.

First, I’ll list the 5 security requirements we usually have to feel really secured. These have been treated in the introductory post in this series.

The client must be sure it sends it messages to the correct provider;
The provider wants to be sure that the client is authorized to;
The provider wants to be sure that the client is who it says it is;
Both the consumer and provider want to be sure that the messages can only be interpreted by eachother;
Both parties want to be sure that the message sent is received unchanged.

The username token will take care of items 2 and 3. The username token is typically a security header in the soap message from the client towards the server. This header contains a username and a password, in one form or another.

In the simplest form, a UsernameToken authentication header contains an element with a username and one with a password. This is the “PasswordText” option of the UsernameToken. When you send this message unencrypted, anyone would be able to read your username and password, an log in on your behalf. Encrypting the communication will solve this risk. However, if the message has to pass several endpoints and one of the connections in unencrypted, your password is open again, despite effort to secure it.

To prevent giving away the username and password combination for free, it is possible to use the “PasswordDigest” version of the UsernameToken. This will actually pass a hash of your password, instead of the password itself. This prevents malicious ears from plucking you password off the wire.

However, although the password is encrypted and unknown to any third party, that third party could log log in by copying the entire security header. After all, if one client can get in using that header, any client could. To prevent this, a Nonce and/or a Timestamp are made part of the hash too. The Nonce is a random value, chosen by the client. The Timestamp is the date and time the password was hashed.

So how does this prevent another user from replicating your authentication header? Well, if a Timestamp is used, the server could require that that timestamp may not be older than for example 5 minutes. This still gives the third party a 5 minute window to abuse your password. That’s where the Nonce comes in. The server can (and should) require that the Nonce may be used at most one time. If the same header -and thus the same nonce- is sent again, the UsernameToken is refused based on a duplicate nonce.

In the end, the security header could look like this:

username Zb5nkZdaXM3hH/bVPQRdMdYSbdo= hHDHOSh3akTwwZFs+6o13A== 2008-05-20T19:00:06.937Z

So, does this make us absolutely secured from any attacks? Well, the likelyhood of anyone abusing your security header is very slim, but nowhere near to zero. Hackers keep lists of commonly used passwords and can use these lists to guess your password. They will see which passwords will create the given hash using the Nonce and Timestamp you have provided. It is therefore very important to generate a password instead of choosing one which is easy to remember. Why would you anyway, a client is usually a piece of software that doesn’t really have difficulties remembering any password. It is of course still not water tight, but it is more likely that the service won’t exist anymore by the time the password has been guessed.

Another way to minimize the chance of abuse of your credentials is by encrypting the messages, or parts of it. This shall be treated in my next post in this series.

The configuration of UsernameToken security in your WebService is fairly simple. Both in client and server only little configuration is needed. There are libraries that can assist you in setting up security, such as Apache’s WSS4J and Sun’s XWSS. If you want to see these libraries at work, make sure you download the code samples for this series on the Gridshore code repository: http://code.google.com/p/gridshore/source/checkout [1].

If you want to go into a little (or a lot) more technical depth of the UsernameToken specification, make sure you read the OASIS WSS specification from http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss#technical.

This concludes this post about the UsernameToken. In my next post in this series, I will shed some light on Transport Level Security and Message Encryption.

[1] Make sure you checkout the code in the /trunk/feeling-secure-with-webservices/ folder. If you check out the entire trunk, you’ll have to deal with lots of samples.

Feeling secure with Web Services – Introduction

Allard — Sat, 17 May 2008 13:45:27 +0000

In this article, I’ll explain the different methods of securing your Web Services, how each of the methods work and what you actually secure by applying each method.

First, let’s start with a definition of security. Wikipedia describes it as: “Security is the condition of being protected against danger or loss” [2]. This just means that you don’t want anyone stealing your data (expecially during transportation) or doing something unwanted with it. To feel secure in the Web Services area, we want to be assured of the following:

The client must be sure it sends it messages to the correct provider;
The provider wants to be sure that the client is authorized to;
The provider wants to be sure that the client is who it says it is;
Both the consumer and provider want to be sure that the messages can only be interpreted by eachother;
Both parties want to be sure that the message sent is received unchanged.

I will briefly explain each of these items.

Let’s start with the first item. The client is the one initiating the connection. Typically by accessing a URL. For example, http://services.somecompany.com/someService. However, messages towards this endpoint are routed through many routers, switches and proxy servers around the internet. How can you be sure that your messages don’t end up in the servers of “some competiting company”?

On the other side of the connection we want a similar kind of ensurance. How can you be sure that the message comes from a client that has been authorized to access that service? And how do you know the message really comes from that client and not from someone pretending to be an authorized client? Quite often, the use of services is paid for, and you’d want to be sure that nobody is using your services without paying for it.

Regarding the fourth item, just imagine sending a request to a web service provider with an order. That order will probably contain some order items, an address and payment information. If anyone can read that information, it is only a matter of minutes before the credit card number has been abused. We want to be absolutely sure that only the client and the server are aware of the contents of the messages.

And finally, if a message has been tampered with, we want both the client and the server to be able to reject that message. After all, when sending the order again, we wouldn’t want our competitor to intercept the message, change the delivery address to their own (although that would be really easy to trace for law enforcement) and forward the message to the service provider. In some countries, at least in The Netherlands, the tax authority requires that digital invoices are signed by the sender using a trusted digital certificate.

There are several tools, methods and libraries available to achieve one or more of these goals. In my next articles, I will elaborate more on the following topics:

[1] Jip and Janneke are two very popular cartoon characters for small children. You might just recognize them: http://images.google.nl/images?q=jip+and+janneke&hl=nl&um=1&ie=UTF-8&sa=X&oi=images&ct=title

[2]http://en.wikipedia.org/wiki/Security

Shooting ducks

Ben — Fri, 21 Mar 2008 15:39:42 +0000

If you want to make an omelette… you have to shoot some ducks!

A counterpoint to Arjen Poutsma’s WS-DuckTyping

Author’s note: this was actually an article written by me for a different publication some time back. However, this is its first publication.

Introduction

In his blog on WS-DuckTyping, Arjen Poutsma gives some tips on using duck typing (essentially dynamic typing) in the implementation of web services. In this response to his blog, I explain why I disagree fundamentally with everything he says.

Don’t validate incoming messages!

The first tip Arjen gives in his blog is not to validate incoming messages. He has two reasons for this, the first being that schema validation is slow and the second being that validation violates Postel’s law of be conservative in what you do; be liberal in what you accept from others.

Schema validation may be slow (or at least slower than, say, no validation) and unaccepting of faults in others, but it does tend to buy you one major advantage: the absolute knowledge that answering an incoming request is within the capabilities of your (web) service.

As we were all taught by the likes of Tony Hoare and Edsger Dijkstra (see Hoare Logic), the precept of all programs is that a program S is guaranteed to terminate in a well-defined state Q if and only if it starts in a state conforming to precondition P of S. That is to say, a program can only function correctly if it is started in a state that matches certain assumptions. It is not possible, in general, to write a program that will always carry out its task no matter what. This is why we do things like input validation and parameter checking — to ensure that our programs can work at all.

In a web service, incoming message validation is precondition verification. Message validation is what tells us whether we are dealing with an answerable question or whether we are dealing with syntactic (and sometimes even semantic) junk. Moreover, message validation is what tells us that we can have our service implementation process the message without choking on the message contents (and throwing an exception because the data is unmanageable). It is also a security aspect – in web services too, we validate to prevent SQL injection.

Poutsma has a point in that the processing involved in validation may be slow. However, he seems to forget that the considerations mentioned above mean that if you do not validate automatically against a schema, you will still have to validate manually (i.e. with hand-written code) to prevent program errors. He also ignores that the cost of program errors (ranging from transaction rollback to catastrophic service failure) and recovery (e.g. queueing and manual processing in a high-volume environment like KLM) may be significantly higher than the cost of upfront service denial.

Use XPath!

Arjen’s next tip is to use XPath to query an XML document for data rather than rely upon its structure to find the data. His main argument here is that using XPath is more forgiving of structural errors in non-conforming documentation than traditional parsers and XML marshalling (which is also a parser technique, by the way). Using XPath allows you to find the data, even if the client put it in the wrong place — just skip over the XML document tree and go directly to the leaf of the right name.

That’s a very nice idea, except that (unless your project architect is a complete idiot), you are usually actually interested in the intermediate document structure. The structure often carries as much meaning as the attribute leaves themselves. Some typical examples from the airline domain:

It’s very nice that you can use an XPath expression to loop quickly over the names in a travel party, independently of whether the passengers are adults, children or infants. But very often, whether a passenger is an adult, child or infant is actually interesting – it makes a difference in all sorts of business rules.
Again, very nice that you can use XPath to retrieve all the segments of a flight quickly, no matter how those segments are organized. But the ordering of those segments is significant (Amsterdam – Detroit – Anchorage is not the same as Amsterdam – Anchorage – Detroit). Also, how the segments are grouped into Origin-Destination blocks is significant (on a return flight, some segment belong to the outgoing flight and others to the flight home).

That aside, what if you want to use a name (element name or attribute name) twice in your message, with a different meaning based on context? A simple XPath expression will capture too much data, including the wrong data. Of course, you can still use XPath; you simply make the expressions more specific. However, if you have to specify the whole path from root to leaf in your XPath expression (or a significant part of it), it begs the question of why you should bother with XPath at all.

A completely different point is that if you use XPath, you persist in seeing your service request as an XML document. And you might not want that. You might want to define your service indepently of messaging infrastructure. Using XPath in your service implementation binds you to a single view of your data.

Don’t create stubs or skeletons!

Arjen’s final tip is against using stubs and skeletons to represent parts of an XML document (in other words, don’t use object marshalling). This is an extension of his flexibility argument, since stubs rely on an exact XML grammar for their definition and adherence to that grammar for marshalling and unmarshalling.

The counter-argument is much the same as well. Stubs rely on an exact grammar in the same way that the service implementation itself does. Certainly, not using stubs or validation and simply considering a message to be a flexible mass of accumulated data allows for far more flexibility. But how far do you think you can go before your service allows for so much flexibility that it simply cannot assume anything about an incoming message anymore? Before it becomes impossible to assign meaning to that message and therefore impossible to have a working service?

And yes, it is also true that a more flexible, duck-typing approach makes a service implementation more flexible in the face of change. But so what? If the service changes with a widening change to its interface, this change will be transparent to the clients. If it is a non-widening change, no matter how many ducks, the client will have to be informed. And why would you want to make it possible for a client to send over data that you were never expecting in the first place? A service is not something you spout data at in the hopes that it will somehow reply to a useful subset — clients that do not know how to use a service have no business trying.

Conclusion

Arjen Poutsma presented some tips on web service implementation and I didn’t believe him. In fact, I still don’t. It seems to me his tips result in unwanted binding at best and make it impossible to implement reliable web services at worst. I’m scheduled to follow a training given by Arjen on web services and perhaps we will discuss eachother’s points of view. And perhaps he will be more convincing to me then. But he has a lot of quacking left to do. In the meantime, my motto is this:

Fly away, ducks — leave the web services to the spiders.