Describing Web Services and SOAs As Options Proliferate

Home

News: Describing Web Services and SOAs As Options Proliferate

  1. Making web service clients able to easily consume a SOAP or REST web service is the key to interoperability. This means a standardized, machine readable description that is clean and clear, and which programmers as well as development and management tools can easily use.

    However, web services are increasingly developed from a contract-first perspective and used from an wider array of clients. These trends are showing that the standard way of describing web services, WSDL, is outmoded and insufficient. Most service developers find it trivial to inadvertently put programming idioms or XSD constructs into the service description, which makes writing clients using available tools difficult.

    Over the last year, to address this problem, a wide array of new web service description methods have been proposed to fix this issue. From the standards side, WSDL 2.0 is on the way, and will presumably handle SOAP and REST robustly, but it's considered to be overkill for many organizations and will not likely see the light of day before many ad-hoc solutions that are growing in popularity.

    The SOAP Service Description Language (SSDL), WRDL, WADL, and numerous other proposals and ad-hoc methods are getting more and more attention but all have significant strengths and weaknesses. Tim Bray, co-inventor of XML, has acknowledged the problem is serious and recently come up with his own approach, called SMEX-D. Are ad hoc methods really where the industry is headed?

    It's clear the web services community feels it has a problem on its hands, but what will happen? With WSDL showing its age in a fairly pronounced manner, it's time to examine both the alternatives and the probable future (WSDL 2).

    To this end, service-oriented blogger Dion Hinchcliffe is hosting a survey of 14 different ways to describe web services. The goal being to provide an overview of the approaches available including their strengths and weaknesses, and show where standards and interoperability are likely to head. After the survey completes, the industry will have an up-to-date reference point on the state and future directions of web service description systems and, more importantly, the actual interoperability issues as the web service description story continues to fragment.

    Threaded Messages (21)

  2. XSD .. duh[ Go to top ]

    SOAP is going the way of EJB. Unnecessary for the vast majority enterprise projects. XML schema is the language of XML interoperability. Just like people are discovering "hey, I can just write POJO code and be 10x more productive than using EJB", so are people "discovering" that using simple XML schema declarations, they can develop effective web services. XML to Java binding compilers (JAXB) is a key development in allowing simple, roll-your-own, schema-driven web services.

    It's an irony that in most situations when SOAP was touted as a boon to interoperability, it effectively reduced interoperability.
  3. What about WSIF?[ Go to top ]

    Happy to see someone finally addressing this! WSDL seems overly verbose.
    Is there any particular reason why WSIF was left out in the survey?
    http://ws.apache.org/wsif/

    Reagards,
    Andre Ranvik
  4. What about WSIF?[ Go to top ]

    I think WSIF is about invoking operations defined in a WSDL, where as the servey is about alternatives or enhancements to WSDL.

    Basically WSIL is about invocation of described services and WSDL and the alternatives are about describing the services.
  5. What about WSIF?[ Go to top ]

    Happy to see someone finally addressing this! WSDL seems overly verbose.Is there any particular reason why WSIF was left out in the survey?http://ws.apache.org/wsif/Reagards,Andre Ranvik

    Probably as its a survey of service description libraries (SDLs) and WSIF uses WSDL as its SDL.

    James
  6. IDL anyone ?![ Go to top ]

    `
  7. WS only for B2B[ Go to top ]

    I see Web Services (WSDL/SOAP) only for Business to Business communication. For interoperability inside businesses and between different platforms, CORBA is far better choice:
    - faster
    - more feature rich (security, transactions...)
    - supports OO principles (usefull when used right way)
    - simpler (yes, simpler!)
  8. WS only for B2B[ Go to top ]

    I see Web Services (WSDL/SOAP) only for Business to Business communication.

    I've heard all this before, it's like a general consensus. Dare I ask why? Why does B2B equal web services and a their slew of XML-based specs ? What is problem, really, that pointy brakets solve, and that just cannot be solved with existing, reliable, portable, available rpc, object brokerage, and data encoding schemes such as the ASN.1, XDR or IIOP?

    Apparently there's some mystical trend that it has to be "semistructured" (?! what does that even mean ?), human readable and I forget what else. Right.

    Anyway, rant mode off.
  9. WS only for B2B[ Go to top ]

    ...human readable and I forget what else. Right.Anyway, rant mode off.

    Well, for me, at least "human readable" is a big big plus. I personally do not care much about "machine readable" and "metalanguage" etc etc.

    But I know what it is like to read rpc traffic on the wire, and in any real world scenario, more often than not, this is where you will end up.

    Also, in much the same way that it is good practice to keep "information in plain text" it is excellent practice to keep "communcation in plain text". The possibilities for upgradeability, versionability etc. are just magnificent....
  10. WS only for B2B[ Go to top ]

    But I know what it is like to read rpc traffic on the wire, and in any real world scenario, more often than not, this is where you will end up.

    Say what ?!
  11. WS only for B2B[ Go to top ]

    I personally do not care much about "machine readable" and "metalanguage" etc etc.

    This is sheer nonsense. If it's not machine readabale it's obviously unusable.
  12. To this end, service-oriented blogger Dion Hinchcliffe is hosting a survey of 14 different ways to describe web services.

    I felt the urge to check it before posting because I could not believe it. I had also to count the list elements myself to be sure the number was correct, and it was. Yes, they are fourteen.

    We were told that WS were cool because they leveraged human-readable XML messages. It is now clear that binary XML must be used to solve performance issues or some media will be cut off.

    We were told that WS were cool because the language definition was standardized. It turns out that there is a cacophony of different standards that can (should) be used to describe the service syntax/semantics/contract/what-was-it-that-you-wanted-from-my-service-in-the-end .

    Is this what you call simplicity, standardization and out-of-the-box interoperability?

    One thing that I liked in this article, instead, was the focus on the contract part of the web service definition. The point is that I find the WS stack as lacking, in the domain of contract definition, as anything else (like IDL). I feel that a client/server or producer/consumer interaction that has an established contract cannot be really loose-coupled. But I might be wrong on this subject.
  13. The point is that I find the WS stack as lacking, in the domain of contract definition, as anything else (like IDL).

    How do you mean IDL is lacking in the domain of contract definition? What is exactly lacking? What are the things missing in general from (apparently) all the options available?
  14. Contracts[ Go to top ]

    The point is that I find the WS stack as lacking, in the domain of contract definition, as anything else (like IDL).
    How do you mean IDL is lacking in the domain of contract definition? What is exactly lacking? What are the things missing in general from (apparently) all the options available?

    Hmmm, I have not got my CORBA bible at hand, but I cannot remember anything like preconditions, invariants, etc. I think modern SDL are beginning to introduce such concepts in their specification (along with a lot of useless junk).

    Of course writing a good, commented IDL specification should give a fair idea of what the contract is, in fact. So I was just complaining that the syntax was not specifically designed to express contracts. Or maybe there are IDL features that I still ignore. I do not know much about COM IDL, too.

    Is this thread beginning to turn from WS debate to the usual pro-CORBA petition? I would like to read a pro-WSDL reply to my question above, but only the usual gang of IIOP supporters (including me) has shown up so far.
  15. Coupling and contracts[ Go to top ]

    I feel that a client/server or producer/consumer interaction that has an established contract cannot be really loose-coupled. But I might be wrong on this subject.
    There has to be a contract between client and server, even if it is not documented or enforced. No established contract would mean that server will respond with pretty much anything and that client can make any kind of request (for instance a request to raise Bob's salary, but given to a stock ticker server).

    Loose coupling does not mean "no coupling". If two things (components, services, applications, whatever) are to do something together, there's already a dependency between them. Personally, I interpret loose coupling as "as few dependencies as possible, but no less". Quite a truism, and as such rather useless software engineering term.
  16. Coupling and contracts[ Go to top ]

    I feel that a client/server or producer/consumer interaction that has an established contract cannot be really loose-coupled. But I might be wrong on this subject.
    There has to be a contract between client and server, even if it is not documented or enforced. No established contract would mean that server will respond with pretty much anything and that client can make any kind of request (for instance a request to raise Bob's salary, but given to a stock ticker server).Loose coupling does not mean "no coupling". If two things (components, services, applications, whatever) are to do something together, there's already a dependency between them. Personally, I interpret loose coupling as "as few dependencies as possible, but no less". Quite a truism, and as such rather useless software engineering term.

    That was well put. I find working with SOA to be challenging because many clients don't even want a wsdl or contract. They want things to be able to change dynamically. A "server responding to pretty much anything" as you put it is not very useful.

    In order for SOA to succeed there need to be a lot more education on the subject.
  17. Coupling and Contracts[ Go to top ]

    I feel that a client/server or producer/consumer interaction that has an established contract cannot be really loose-coupled. But I might be wrong on this subject.

    I fully agree with Bostjan, and myself have always favored explicit contracts such as XML schemas. Most clients/developers who don't want to go through the initial overhead of developing a contract do so primarily because of plain laziness.

    However, recently I have somewhat revised my opinion due to versioning. If you don't encode all the dependencies explicitly in a contract which by definition perform automatic validation, then it is easy/easier to change the messages. You don't have to change your messages *and* your schema.

    I think the key issue in the implicit/explicit contract debate should be around versioning which in itself is one of the central issues in all software design today. Some insight into this topic and the various tradeoffs involved would be most productive.

    For example, see "Extensibility, XML Vocabularies, and XML Schema" at http://www.xml.com/pub/a/2004/10/27/extend.html.

    David Bau has some fascinating stuff - "theoretical approach to versioning compatibility": http://davidbau.com/archives/2003/12/01/theory_of_compatibility_part_1.html

    -- Andre
  18. I really have waited for this debate.
    There is a point in mentioning IDL's here, because they are a language neutral way of describing a service, and are designed to generate code from. WSDL has really to much implementation stuff in it, which makes it inappropriate to use as your primary source of describing services. For SOA to be meaningfull it must be backed up with a repository of Meta descriptions of all your services. From this we can generate all sorts of language bindings for the service-interface: Java C#, WSDL (yes WSDL i just another implementation language in this context.)

    Lets dig up the good old knowledge from CORBA IDL's and make a XML schema for Service Descriptions. I have used code generators from my own ad-hoc Service Descriptions. They have survived C,C++ COM+ Java (pojo),EJB, WSDL and will survive many new technologies. After all, the concept of a service-interface has been around for a long time, and will be in the future.
  19. I see this line of thinking was already introduced by Martin Gudgin, Timothy Ewald 3 yeas ago. see http://www.xml.com/pub/a/2002/01/16/endpoints.html

    They propose a radically reworked WSDL. The goal can be achived by introducing a new XML based IDL format, and a simple XSL transform to all the tedious WSDL's and XSD's that nobody bothers to handcode anyway.
  20. The goal can be achived by introducing a new XML based IDL format

    I'm sorry, but why the f*ck would you do that ?!

    Cheesus has _everyone_ gone insane ? Why does everything have to be XML ?!
  21. SOA and Loose-coupling[ Go to top ]

    Service interface changed, and your client code still works? I would love to see how that can be done without using architecture patterns like broker and pub/sub. Even in that case, some changes on the transformation logic needs to be done in the broker too, therefore, not completely de-coupled.

    I guess that's why SOA is the Same Old Architecture. You can't get away from those best practices built from the past, at least not any time soon.
  22. Reality versus Hype[ Go to top ]

    I agree with you as well. The ability to abstract the service interface to the point where there are no ill affects when it changes is up to the skill set of the developer or vendor who is delivering the interfaces. I've seen very mixed results with this delivery. I think one of the reasons is the complexity and numbers of standards surrounding web services. I think another reason is that a lot of developers still don't understand the principals of loose coupling and coarse grain services. That's why I think there is still a huge role for an intermediary between services or interfaces.


    markg
    http://darth.homelinux.net