mark nottingham

Mark - are you really starting over again, or just ignoring WS-* and using REST, which was around before WS-? I mean, starting over sounds like WS- was a good idea but they screwed the pooch and you can do it better, whereas using REST is more like they should not have been trying to screw the pooch in the first place, it was a bad idea.

I personally wouldn’t call it “disturbing”. “Sad” seems more apropos, since no large scale harm was possible because the vampiric strategy was tied to an ineffective, non-scalable architectural style.

Had they been Web-vampires (as described in the Halloween docs), that would be disturbing IMO.

I love the new mnot! 8-)

Hallelujah, brother. Tell it like it is.

I spent four years working on WS-* as an implementer. Every time I’ve heard Anne Thomas Manes talk, all I could think is that she needs to spend more time in the trenches and less time reading vendor white papers. Talk about taking the bait, hook, line, and sinker. She says this stuff is real, but show me the big deployments? I worked for a major vendor and all I saw were a handful of prototypes with mixed results.

All I can say is that if you don’t see your use case described explicitly in the interop tests for one of the specs, you are going to be in for a world of hurt if you need cross vendor interop. Notice how few intermediary test cases there are?

Let’s assume you are right. All this WS-* is crap (this is what you are meaning). What do you recommend? Start over again with no support of these “vampires”? Stay as simple as possible, ignoring all the existing complexity out there?

First of all who says that the vampires are necessarily happy with WS-*? I leave it as an exercise to the reader to figure out why my group’s VP (Brian Arbogast) goes around giving speechs about just using plain HTTP.

Second of all who says even the vampires can talk with each other in any useful way?!?!?! At least three people with text on this webpage know the answer to that question from hard real world experience.

Third, what to do without WS-*? Gosh, I don’t know, how about ship useful code? I hear that HTTP stuff is pretty cool. If anyone cares you can peruse a bunch of blog entries on my website (www.goland.org) where I walk through a number of key enterprise scenarios and show that nothing more than HTTP+XML is required.

And yes, I still work for Microsoft. In fact, one of my jobs is to write the best practices for the design of all external interfaces for Windows Live. What you will see is a lot of HTTP, microformats, URL encodings and XML. My instructions are clear, first priority goes to simple HTTP interfaces..

Oh and here is a thought that an unnamed Microsofty gave me. The new shlock movie (http://www.imdb.com/title/tt0417148/) Snakes On A Plane (SOAP). Just a thought.

I know you weren’t at Microsoft when it happened Yaron, but there were certainly two vendors working closely together at the foundation of WS-. They set the scope and approach for the standards. And I am relatively certain that their motives weren’t all pure. They may be losing the war on the homefront, but the WS- machine seems to still be chugging forward on the same path it started on.

“you’ll have the option of selecting other vampires to replace them at will”

The vendor-pires would love for you to believe this. Of course this is not, and likely never would be, the case.

I’m so loving your perspective lately, Mark.

Doesn’t this remind anyone of OSI? The standardization is too far ahead of the experience and the user need. The vendor needs are driving the process.

Technically we’ve been improving. I’ve been involved with OSI, DCE, CORBA, web services, and now SOA. The value of each of these to user orgs has improved over its predecessors. We’ve been learning. OK, except maybe the core WS-* specs are becoming too RPC-like.

It is the process management that’s poor. OASIS is like the OMG. They are companies and their goals are to get members who pay them. The end-user community does not care enough to participate strongly. The vendors become their main constituency. The vendors take this as a confirmation of thier direction when the message they should be hearing is slow down.

well if ryan is loving it, i am subscribing…

beware leaky abstractions!

There is truth in what you say, and yet our client has found a lovely little niche for SOAP and WSDL.

Our client’s difficulty is that much of his development is outsourced to three different companies - two which develop in Java, while the other develops in .NET. (We’re one of the Java companies.) With SOAP we have a protocol that both Java and .NET understand, and with WSDL we have a framework for clearly specifying interfaces. The result is that all the different pieces of code are playing nicely, despite the barriers between the teams.

Let’s not throw the baby out with the bath-water.

Show me the widespread Python, Perl, Ruby and PHP enteprise applications that are rolled out in IBM, Oracle, and BEA’s customer base … if they widely existed, there would be WS-* support.

There are many, many developers that cannot, and will not use those languages (for whatever reason), and find building SOAP services on .NET ASMX or JWS much easier than HTTP services in Servlets or a scripting langauge. Is this really a vendor-pire conspiracy, or are they just addressing the way developers and architects think in enterprises?

I work in the field at BEA, I think there’s a lot of examples of people doing large, useful things with SOAP, composing services and apps, etc., much more productively than they’ve ever done in the past. I think there’s lots of examples with just HTTP, and I encourage that (just today, at a workshop with a telco, in fact). There are times where I can’t use HTTP end-to-end, though, for a variety of socio-economic reasons.

Anne speaks from a legitimate and widely understood perspective, even by people on the ground. Instead of pointing the finger at just the vendors, I’d look at the large “enterprisey” customers too – they’ve infiltrated the W3C and other standards orgs because they’re old and big, and have decided the web is too important to not control. There is a lot of history and prejuduce in companies that have gone through 3 or 4 generations of computing… And it’s likely going to slow down the development of new approaches.

Or one could just go work for a web company to get away from that (which isn’t that bad an idea).

the new term, as introduced by Thomas Otter, is vendorprisey…

I can understand why Yahoo doesn’t think that WS-* architecture is useful in the “real world” but I think you’re avoiding the reasons why an Enterprise might be interest in WS-* and it’s view of strongly typed and described contracts. This is part of the point that I made at the WS-* workshop, which is how is Enterprise development different than other models such as Web development. Maybe there aren’t any real differences but maybe there are.

I’d suggest that Enterprises typically have many more “services” but fewer “instances” of each service than Yahoo, etc. Your typical Enterprise software deployment might have thousands of “services”, each of them being invoked fairly few times compared to a Yahoo. Because of that, I think that Enterprises tend to like strongly typied and descripted interfaces so that vendor code can help with development. This is the generated stubs and skeletons argument.

I’m not denying that there are inteoperability problems, but I think they also happen just as much in the “REST” world but nobody wants to talk about it. Tell me all about the joys of debugging an AJAX app in different browser versions with scripts within scripts. At the heart of a lot of interop problems is Schema 1.0. Support is spotty across the WS-* stacks but I don’t think it’s any better across the OSS side of things.

As for SOAP intermediaries being a pipe dream, that’s an incredibly ironic and powerful assertion coming from Yahoo, which ought to be one of the biggest intermediaries around. But maybe that’s the heart of it, is that Yahoo being an intermediary doesn’t need the SOAP processing model. I’ve recently been involved in helping a banking industry consortia define it’s specs and it absolutely needed SOAP, WS-Addressing and WS-Security. Any non-SOAP solution would have ended up recreating WS-A and WS-S. And they can add in reliability in the future via WS-RM.

I do agree with the assertion that composability is asserted and not proven. Every time we’ve tried to compose the specs in a general sense, it’s been difficult. The combination of WS-Addressing, WS-RM and WS-Policy was incredibly difficult. But yet, if you want to build an application that can arbitrarily pick and choose these kinds of functionalities across many different services, you don’t have anything like WS-* in REST land.

It’s kind of sexy for WS-* folks to knock the HTTP architecture, and vice versa, and maybe the core of it is just some folks trying to get more money. Not that there’s much wrong with making money.. But I still think that we can actually have an engineering/architecture trade-off discussion between the architecture styles and the actual system architectures. Even Roy says that REST isn’t the best thing for all systems and people have to think for themselves.