Web of Services Workshop Summary

It’s not often I get to go to something like this, never mind the priviledge of co-chairing it.
I think we had a really great discussion, and I certainly learned a lot. From what others said, I think that was a pretty general impression. And I think everyone really did maintain a spirit of cooperation and pitched in.
We had a great mix of users, WS-* folks, and REST folks, with a couple of industry analysts thrown in, and experts on a variety of topics.
I think in the end we came up with a few good ideas for improving software standards for the enterprise, and a some good suggestions for how to better join the Web services (WS-*) and Web (REST) communities.
Of course, we have yet to see what will really happen. But for the past two days we had everyone into the same room, and I would say each started to acknowledge the other’s viewpoints. I even heard Mark Baker say he thought one of the WS-* companies was making pretty good progress
There’s a lot to say, more than I can get to today. There will also be a format report, including any actionable items and recommendations. (Also the program now has all the presentations, in case you want to take a look
I’ll start recording a few interesting thoughts, in no particular order. I’ve also got a few photos that I’ll upload.
The innovator’s dilemma
Also known as why it’s difficult to recognize the effects of a disruptive innovation such as the Web.
I remember in the early days, when we’d talk with customers about SOAP, they’d say “well, that’s fine, but I can’t use it until it has better security,” or reliable delivery, or transactions, etc.
We had an example during the workshop, when one of the users said something like “I need a lot more capability in Web services before I can use it to replace WebSphere MQ.”
I just think that’s the wrong way to think about it, but it’s very natural. Customers rely on these kinds of “enterprisey” features every day, and when thinking about adopting new technology they look for feature compatibility.
But I think the question isn’t really “do Web services features offer equivalence with MQ” but “can I meet my application requirements using Web services”?
Yet we keep thinking about Web services in terms of the past, an evolution of the current solution, rather than as a completely new approach, an adaptation of middleware concepts to Web technologies.
The comment also was made a few times that it isn’t the specs as much as how they’ve been implemented that creates the difficulties for Web developers, and the complexities for which WS-* gets criticized.
Start with the Web
If Web based businesses such as Yahoo, eBay, Google, and Amazon.com can handle hundreds of millions of users and thousands of messages a second, petabytes of data, etc. and with good response time in a browser — you know it can be done.
So for anything new, consider using Web based technologies, or at least consider following the architectural principles of the Web in your design.
(Unless, of course, your business has absolutely nothing to do with the Web, and will never have to scale or change very much. There are many reasons not to consider using Web technologies. But I am thinking about the general case of a large, distributed enterprise application.)
Now however if you have a bunch of old systems – or if your IT environment was created before the Web, and (like many) is a mess of heterogenous stuff, you are going to also need to tackle the problem or rationalizing or standardizing that. Here an SOA using Web services is a great approach, and one that is growing in adoption.
If you want to join up your old stuff to the new stuff, Web services seem like the way to go.
Yahoo was among the companies represented and they mentioned that they still like to create their own infrastructure – these “mega sites” use quite a bit of custom code – because they can’t really buy what they need from the vendors.
Not too long ago this was the case more generally. I remember a lot of financial services organizations inventing their own middleware and TP monitors, because their requirements were farther advanced than the features of generalized products. So this seems cyclical, a pattern that substantiates the disruptive concept.
This was the reason I proposed a hybrid solution – use the Web for new applications, and adapt (or interface) existing applications using Web services.
This was the subject of some debate, and about two or three ideas were given on how to best accomplish this.
More later…

About these ads