Risks to the success of Web services

I spent last week at DevWeek in the UK. This is probably my favorite conference. It's small and independent, gets great attendees, and is just generally a great time. I got to see and talk to lots of friends. Web services were a theme throughout the week (what a surprise ;-). Jon already posted about our dinner at Veeraswamy with Simon Horrell and Dominik Baier. Before we got to the important stuff, we dealt with Simon's assertion that Web services had failed. What he really meant was that a lot of the big visions people have for orchestration, all kinds of advanced protocols, etc. seem less likely to him. For the most part, I agree; but I don't think that means that WS have failed, just that people are getting more realistic about what they'll actually be able to achieve.

That said, I spent the plane ride home the next day thinking about what might make WS actually fail. Here's my list:

• WS-* has raised so many expectations that it has a high potential to disappoint. A lot of people draw the parallel to the later years of CORBA, which followed a similar track. We can avoid this if we start to get more realistic about what can be done easily and interoperably (which is what made basic WS sing). I think looking at the WS features in kits like Indigo is a good way to trim things down to a more realistic subset of what's been talked about. Worst case, if people become disillusioned with WS-* (and WS-Security is already too far along to say this is the case) and choose to discard those protocols, we need to make sure that basic WS aren't discarded as well.
  
• Lack of interoperability means that people don't get service reuse in a heterogeneous environment. You've heard me rage against code-first development for quite a while now, and this is the main reason why. Anyone in the trenches actually building systems knows that deriving the details of your contract from your implementation is a sure fire way to cause interop issues. This doesn't mean I think you should have to type XSD and WSDL by hand, just that you ought to be deliberate and explicit in your contract design. We need tools to help with that by abstracting away details. Inferring contract from your implementation is not the right way to do this, however.
  
• Treating everything as a service, even within the context of a single distributed application on a single LAN. I keep seeing people talk about modifying existing Web apps that talk to databases to talk instead to a service that talks to the database. The idea is that the service can be exposed directly to customers. I probably wouldn't take that approach for two reasons. First, the service interface is (or should be) designed for the external customer and therefore probably is not what I want to use from the Web site. Second, this requires an extra protocol hop that is unnecessary. The reason people pick this design is that they want to reuse the same data access code for both the site and the service. I would solve this problem by building a DLL that encapsulates access to the database and using it to implement both the site and service, which would be peers of one another. Anyway, this tendency to make even internal pieces of a system (which are almost by definition tightly-coupled) into services, despite the overhead this incurs reminds me a lot of the move to make everything a COM+ (or EJB) component. How long will it take people to realize that here to, this is not a good idea?
  
• Finally, the tendency to focus on RPC style or at least on object models (code-first again!) as the starting place for designing WS will limit the extent to which we can build loosely-coupled systems. How many loosely-coupled object models have you seen in your life? XML can be loosely-coupled, but you need to start from the right place and proceed in the right direction when you begin your design. Of course without loose-coupling, you end up back in a world where all clients and services have to be updated at the same time. This is essentially where we are with services today. If we don't get past it, a lot of the promise of Web services will not be realized. Instead we'll have yet another RPC-style stack. Okay, it may be interoperable in a heterogeneous environment (although this is not guaranteed) and it may be easier to use than some, but this is the worst case scenario. Since we're 7+ years into inventing a distributed system stack yet again, I hope we can do better.

Okay, that said, I don't mean to get anyone down. I think WS has HUGE potential IF we do it right. We can mitigate all four of these risks if we:

1. Are realistic about advanced protoocls
2. Design for interoperability
3. Use services where they make sense, which isn't everywhere
4. Design for loose-coupling

So let's do those 4 things. :-)