Partager via

WS-* Specifications: Are there too many and are they too complex?

  • Article

Tim Bray and others have questioned the plethora of WS-* specifications.  Tim says:

I still think the WS-* stack is bloated, opaque, and insanely complex. I think it’s going to be hard to understand, hard to implement, hard to interoperate, and hard to secure.

and then states how he wants to be the loyal opposition to the work going on in this space.

Are there too many specs?  If you think so, then there are.  So don't use them all.  You don't have to use any of them.  But if you need the capabilities they provide, like message-level security, then use the ones you need (in this case WS-Security).  The composability aspect of the Web service specifications is such that you can pick and choose what capabilities you need.  You don't have to use every spec that comes out.

Is the stack opaque?  I'm not sure I understand exactly what Tim means here, but I don't know how Microsoft and our partners can be more open about how we are creating these specs.  We are doing things differently in that we aren't going to a standards body first, then coming up with a draft of a spec.  This takes too long.  However, through the Workshop process we are getting public feedback, posting materials and results, creating discussion groups and bringing a well-fleshed out spec to the standards body for expedient ratification.  If you have an opinion on a spec, there is no reason why your voice cannot be heard.

Is the stack insanely complex?  The release of WS-Transfer and WS-Enumeration has understandably made a few  heads swim -- "Boy, more specs!  What are they thinking?"  But I cannot imagine that anyone would really look at either of these two specs and say that they are too complex.  They are trivial.  When I consider the work we did to make the initial SOAP implementations when it was a young spec and dozens of people stepped up to play around and create an implementation, I think it is safe to say that it would be significantly easier to create a WS-Transfer or WS-Enumeration implementation given todays tools.  Admitadly, they are specs, so they aren't something I'll give my wife to read for a little light-reading before bed, but they are pretty simple.  The same goes for most of the recent specs.  In fact, its probably safe to say that the most complex spec is WS-Security, which needs a certain level of complexity to handle the important issues it deals with.  But it just so happens that WS-Security was the first WS-* spec to be ratified by a standards body.

Is the stack hard to understand, implement and interoperate? Here's an article that explains the specs, but again, if you don't understand all the specs, don't worry about it.  Tools are being created by people everywhere to make it so you can just indicate the capabilities you need and the rest will be done for you.  If you look at all the major players signed on as authors on the specs, you get a pretty complete picture for all the popular platforms.  Add to that the people creating implementations that don't happen to be authors on the specs and you will find a lot of people dedicated to creating implementations.  And by and large, the specs are pretty darned simple.  A major portion of the standardization process (both the Workshops and the standards bodies' ratification process) is how well implementations interoperate.  If during the Workshop process implementations don't interop for some reason, the authors can go back and modify the spec to address any problems.

Will the stack be hard to secure?  I think the answer to this question will be answered very soon.  WS-Security has been ratified for a few months and implementations are being developed in a lot of different places.  Is it hard to make WS-Security interoperate?  This is probably the hardest of all the specs.  But there has been success in the past with early versions, and I suspect a lot of success as supported versions start being released by all the major vendors within weeks.  Obviously it is hard to look good if your WS-Security implementation does not interoperate, and there are definitely efforts being made by all the major players to test against the other implementations.  If 6 months from now we don't have implementations from most major platform providers that interoperate, I will be stunned and will question the future of the WS-* stack.  But I am really, really, really confident that this will not be the case.

   -Matt

Comments

  • Anonymous
    September 21, 2004
    <gripe>

    My main problem is one that impacts my ability to offer interoperable, service based functionality to my clients. The problem is that the specs keep changing in non-backwards compatible ways. Sure, I can implement WS-Security. Which version? Each version has it's own namespace. WS-Addressing, again, there have been several revisions, each with it's own namespace. Am I supposed to wait until I think they will never change again before I implement a solution using one of these specs? I may implement a solution today and have perfect interoperability today, but in 3 months, the spec will get a minor revision, a new namespace, and if any of the collaborative peers decides to move to the new spec, they can't talk to me anymore. What's even worse is when my software can't talk to a slightly old version of itself because we decide to use an implementation of WS-Whatever that is slightly newer.

    I don't expect these things to not change. And on some level, changing the namespace seems like the obvious way to version the the spec, but it sure does throw a wrench into the real world where deployed software has to stay interoperable for years and not just months.

    </gripe>

    Sorry about ranting...
  • Anonymous
    September 21, 2004
    Hello Matt,

    We recently posted a news item posing the same question, are there too many specs? We'd welcome you to ask this question of our readers by commenting on the post at http://www.theserverside.net/news/thread.tss?thread_id=28858.

    Thanks,
    Paul Ballard, Editor
    TheServerSide.NET
  • Anonymous
    September 21, 2004
    If your building implementations of these specs then the one that is carved in stone is the one that is ratified by the standards body. For instance the Oasis version of WS-Security (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf) is the version that you will want to create. Any version before that time you will need to expect to change if for nothing else then for the namespace update. But you can expect interoperable WS-Security with the current Oasis version for years and perhaps decades. Unfortunately WS-Security is the only spec that has reached this far yet. The next ones: MTOM and WS-Addressing. Others to follow.
  • Anonymous
    September 21, 2004
    In V2 of your stuff for Web Services, I still have yet to figure out how to do a shared key encrypted web service. in V1 it was easy and there was lots of documentation and samples. Now, you've depreciated the old stuff so it won't work at all, and you don't bother to give a sample on what replaced it. I just want simply encrypted security between a web server and multiple clients. I would say that this is the baseline need for web services, and yet you don't give any samples that don't require Windows Login info (which they won't have) or a radius server (which they won't have) or some other bizzare requirement. If you're going to have all of these complex standards, that's fine, just make sure that the baseline is trivial to impliment.
  • Anonymous
    September 21, 2004
    "if you don't understand all the specs, don't worry about it. Tools are being created by people everywhere to make it so you can just indicate the capabilities you need and the rest will be done for you."

    The seductiveness of programming-by-wizard. Go and read Ellen Ullman http://archive.salon.com/21st/feature/1998/05/13feature.html

    Not understanding something you want to integrate tightly into your app is a bad idea, because "Abstractions are leaky" and ignorance is not bliss to anyone who wants to do solid work.

    Having too many small specs leads to complexity. Unexpected interactions and behavior will arise when more than two of these WS-specs are composed on top of each other.

    Too many specs, too few real-world solutions.
  • Anonymous
    May 29, 2009
    PingBack from http://paidsurveyshub.info/story.php?title=matt-powell-ws-specifications-are-there-too-many-and-are-they-too