Tuesday, May 09, 2006

UnREST over WS-* and other "enterprisey" things

Mike Herrick, who just happens to be one of my Burton Group clients, has accused me of having "totally drunk the WS-* the Kool-Aid". He goes on to say, "I just was disturbed that given the history on things like J2EE she so easily assumed that WS-* will survive and thrive."

Let me make this clear:

I'm one of the folks responsible for mixing the Kool-Aid. I presented at the W3C Workshop on Web Services (representing Sun). I participated in numerous standardization efforts at W3C, OASIS, WS-I, uddi.org, and JCP. I have a vested interest in making sure that WS-* succeeds.

I had a similar vested interest in CORBA (I was working for DEC at the time), and I was just as enthusiastic about CORBA then as I am about WS-* now. At the time, CORBA was the state-of-art in distributed computing technology. And today, I think WS-* is the state-of-the-art in distributed computing technology. But I by no means assume that WS-* will always remain the state-of-the-art. I assume that something better will come along. Unfortunately, it hasn't come along yet, so we have to make do with what we have now.

The single, most important feature that inspires my enthusiasm about WS-* is that it has universal support from all the major vendors. The technology has become pretty much pervasive (although the industry is still stuggling with interoperability issues), and there's a huge ecosystem of vendors and products and tools that support it. WS-* also has some really interesting innovations (separation of header and body, the composability of the various SOAP extensions, policy-based management and control via intermediaries, etc), which I think make it particularly well-suited for enterprise-class service-oriented application systems.

There. I've qualified it. WS-* is enterprisey. But is that really such a bad thing? If you need comprehensive enterprise-class semantics (security, reliability, session management, transactions, etc), then it really helps to use an enterprisey middleware system.

People accuse WS-* of being too complex. (Somewhat remarkable when you think back to 2000 when everyone was extolling SOAP's simplicity.) Well -- if, as a developer, you need to understand the details of all 60+ WS-* specs, then, yes, WS-* is way too complex. But that's a symptom of WS-*'s immaturity. If we had proper tooling, the only folks that would need to be concerned with all the 60+ specifications are the folks implementing the WS-* toolkits. Developers should really only need to be concerned with a handful of the specs: SOAP, WSDL, and XML Schema--maybe WS-MetadataExchange. Everything else should be handled transparently by the toolkits. I think we'll get there. Microsoft's WCF ("Indigo") demonstrates how easy it can be to use WS-Addressing, WS-ReliableMessaging, WS-Security, WS-Trust, and WS-SecureConversation. All you have to do is specify an annotation, and everything is automatically implemented behind the scenes. I expect the other vendors to deliver better tooling at some point. Now that WS-Policy has finally moved into the standards track, we should start getting much better configuration tools.

But I can't ignore the debate between REST and WS-*. I'm a huge proponent of the KISS principle. So I don't recommend using WS-* for all service interactions. If an application doesn't require enterprisey infrastructure semantics, then it's much more appropriate to use a simpler middleware system, such as "plain old XML" (POX) over HTTP. In fact, for applications that require Internet scalability (e.g., mass consumer-oriented services), POX is a much better solution than WS-*.

But that doesn't mean that POX is the best solution for all systems, either. POX doesn't support a clean separation of business and infrastructure functionality, so if you are using POX and you need enterprisey infrastructure semantics, then you need to code the infrastructure functionality in your application code. Bad idea. The reason you use middleware in the first place is to help reduce the amount of infrastructure functionality the developer has to write.

The point is that you should always use the tool that best fits the job. Let the application requirements dictate your selection of middleware.

10 comments:

fuzzy said...

Hi Anne,

Thanks for taking the time to respond.

You have more experience then I do. I am a young pup - I have only been at this for 10 years. I lived through CORBA, EAI, J2EE, and started with WSDL/SOAP pre WS-I. I have been working on ESB/SOA/EDA style integration for the past 4 years. Maybe I just am jaded from making these systems work. I have come to really appreciate simple things. I just look at WS-* and don't see it happening. J2EE failed due to over complexity. WS-* makes J2EE look like a toy in terms of complexity.

You said, "The single, most important feature that inspires my enthusiasm about WS-* is that it has universal support from all the major vendors. The technology has become pretty much pervasive (although the industry is still stuggling with interoperability issues), and there's a huge ecosystem of vendors and products and tools that support it. WS-* also has some really interesting innovations (separation of header and body, the composability of the various SOAP extensions, policy-based management and control via intermediaries, etc), which I think make it particularly well-suited for enterprise-class service-oriented application systems."

Admitedly, the vendors all are on the WS-* bandwagon. But we've seen this before many times ... granted not to this extent. And you hit the nail on the head on what my fundamental problem with WS-* is. I don't want all that cruft in the XML document. It makes my eyes hurt. I think that payload formats should be independent of message framing. This was discussed on REST list:
http://tinyurl.com/s3pld

I have no problem with enterprisey ... I just don't think that enterprisey must == complex.

Then you said: "All you have to do is specify an annotation, and everything is automatically implemented behind the scenes."

Sounds like XDoclet papering over a fundamental flaw in EJB. They hid the complexity. That was great - got us through it, but it never had to be that hard to begin with.

I do like REST and/or POX because it is simpler. But as I was discussing on the REST list, I don't see it cutting it for major integration:
http://tinyurl.com/s3pld

I'd like to see a "rebel framework" as Richard Monson-Haefel calls it built on top of REST to take on WS-*. It would do all the things we need for integration (no not all 60+ of the WS specs ;) ), but leverage HTTP (rather then subvert it like WS-* does).

We'll just have to see where this goes. I think that the market place is getting a little wiser in terms of spotting complexity. Perhaps the next wave of tools (Microsoft WCF, SCA/SDO) will simplify things. Microsoft has a beta out now and will have something for real in the not too distant future. IBM has a baby version of SCA/SDO out (WebSphere ESB 6), but the SCA/SDO specs are babies.

If you want to do SOA/EDA today, you really *really* have to choose wisely. I guess that is my whole thing - I don't have time to wait. I have to deliver today, not 3-5 years from now.

Thanks again for the response.

Mike

Sam Ruby said...

Hi Anne!

re: "everything is automatically implemented behind the scenes"

here's a puzzle.

Loek Bakker said...

Anne, I recently wrote nearly the same thing on the whole debate.
The bad thing about the Enterprisey term is that it is used in the same way the term "FUD" is used in open source vs the rest of the world debates: it ends any serious argumented debate. Which is a shame i.m.o.

Chui Tey said...

Let me approach this from another perspective.

The dominant programming platforms around now .Net, Java, PHP, Python, Perl. The dominant communications protocol are HTTP, SMTP. All of them share one characteristic: Either there exists only one dominant implementation, or they are easy to implement.

WS-* adoption by multiple vendors is actually a minus point. You will find that when integrating across a different platform stack that only the simplest ideas will safely interoperate and navigate around the sea of bugs and incompatibilities. When engineers spend more time discussing port numbers and various technical issues rather than the business issues, you know you have a problem.

Anne Zelenka said...

Hi Anne,

I found your blog through James Governor. What a really interesting and informative post.

I am interested in the comparison to CORBA. I was working on enterprise software when CORBA got really popular. Then I took a hiatus from the workforce, I come back, and CORBA's completely off the map. What happened? I wonder if the same fate awaits WS-*.

Glad to have discovered your blog. I'm interested to hear more of your perspective so I'll be subscribing.

Anne Thomas Manes said...

Sam -- Thanks for pointing out the Atom error. That's what I get for cutting and pasting a prettily formatted table from Word into my WS-Convergence blog post and then not editing the XHTML.

It's fixed now.

Sam Ruby said...

re: It's fixed now.

What? The tools? The data?

What happens when you layer on more tools?

Anne Thomas Manes said...

I fixed the data (edited the XHTML).

Eric Roch said...

I agree that SOA should be considered enterprise in scope. At this point though you do have to mix and match ws-* with legacy technology to get an enterprise solution. Your readers might be interested in this post on the topic. Eric Roch

abby brock said...

But, as I said earlier, we must accept that there are two sides of every aspect or a thing, one is good, and one is bad. Human being has not even spared Xanax, and used it as an intoxicating drug, rather abused it.

movers in marryland