The case for document-centric Web services development

Discussions

News: The case for document-centric Web services development

  1. In this Q&A for SearchWebServices, Edmund Smith, who recently co-authored a white paper, "Rethinking the Java SOAP Stack," makes the case for document-centric Web services development and specifies where Alpine, the service implementation detailed in the white paper, might fit in JAX-WS.

    What do you think? There's a movement afoot to redesign web services altogether; are JAX-WS and similar offerings likely to be overridden as they mature?
  2. As one of the authors of the "rethinking the SOAP stack" paper, my thoughts on the matter are now fairly well known.

    What has been interesting is the feedback we've been getting. Most people agree that JAXRPC1.x is horribly flawed, the only issue is what to do about it.

    The JAXRPC2.0 team think that it is the solution, by letting them do all the XML and WSDL work they will solve all interop problems, and offer an XML back door for retro-grouches like myself. Oh, and they will have a more asynchronous option for long haul links.

    But I think that by still focusing on blocking calls, with a "seamless" XML to Java mapping (now handled by JAXB), and WSDL generated by refection on the implementation, is wrong. Ease of use is being achieved at the expense of sensibility. Does it really make sense to automatically create the public service interface from a Web service by reflecting on the implementation, or should you actually design and specify a public service interface? Because if a web service (even an intranet one) does become popular, then it will have lots of callers, and that means you cant change its interface easily from then on. Generated service interfaces are only as stable as the implentation code, and the stack it is hosted on. Redeploy your code on an updated version of your SOAP stack, and suddenly the WSDL changes. Is that any way to run a public endpoint? Not in my opinion. WSDL and XSD may be hard to work with, but lets just fix those, rather than amplify the problem.

    So the issue is not so much RPC vs Document SOAP, but firstly between handwritten XSD+WSDL versus machine-reverse-engineered, and secondly between working with the message at the XML level versus having some kind of mapping performed. I'm prepared to say that the second issue is not clear cut; we will have to build something and see. But as for the WSDL first versus WSDL last, I don't see why the JAXRPC model is still built on reflection and making SOAP look like RMI.

    Finally, I need to point out that there are already multiple lightweight stacks in existence, xFire is one ActiveSOAP the other. We are looking at both of these to see which already -or can be made to- meet our needs.

    -Steve Loughran
  3. I saw an early draft of the Alpine paper some months ago and it struck me that the critique of RMI semantics in JAX-RPC was pretty good. However, a lot of the complaints in the paper were about databinding and XML: they aren't SOAP/WS problems per se.

    JAXWS is a rework of sorts and to be fair, your complaints in this post don't really hold up. 1) there is nothing prescriptive about bottom up development in JAXWS 2)you can certainly work with XML as a first class entity if you choose -- and a lot of projects would be better served by this approach 3)if you want asynchronous logic for long haul operations, you're probably better off with a good BPEL engine rather than hand-rolled application code.

    In general, contract driven systems are the way to go, especially for large scale solutions like integration scenarios. We know enough about distributed systems to know that annotations and code aren't the best starting point for that approach. This is one of the problems with Indigo: as it stands, its all about the platform as the source of truth for the public contract. Frankly, I don't think that approach is going to fly as a governing model.

    However, there are use cases and users that will want bottom up service support and it may well be appropriate for things like basic client server applications. JAXWS supports that as well, which seems perfectly appropriate.

    If you look at the latest drafts of the spec, it is an improved model and addresses a number of concerns people have had with JAX-RPC. It's pretty clear you can get a lightweight, XML based solution with the new Dispatch and Provider mechanisms.

    Greg
    Oracle
  4. It's pretty clear you can get a lightweight, XML based solution with the new Dispatch and Provider mechanisms.GregOracle

    True, true. But you have to note that part of the paper covered the engineering costs of implementing the whole of JAXRPC, especially in an OSS project. The fact that JAXRPC2 adds even more to the game, means that cost of implementing is bound to increase. Furthermore, the hard split between XML work (in the API implementation) and the stuff that calls the API, makes it that much harder for developers to cross over from user to maintainer.

    If you can explain away jaxrpc by saying "it's ok, the dispatch/provider stuff lets you bypass the rest of it", why do I need the rest of it at all?
  5. If you can explain away jaxrpc by saying "it's ok, the dispatch/provider stuff lets you bypass the rest of it", why do I need the rest of it at all?

    I would say in your case its pretty clear you don't ;-)

    Greg
  6. The most important part of SOA is shared document contract, as opposed to shared somehtin else (objects, database, etc.). Just because we are using XML (message)and XML Schema (contract def) doesn't mean we have to use all the bells and whistles of it and say OO can't match XML Schema, so don't use it!

    For example, the article says XML Schema inheritance can be restrictive. If so, why should that be used! This and other aspects mentioned as the "impedence-mismatch" are not the key enablers of SOA. We could well stay awy from them and yet have a good contract-based SOA going that is evolvable - all using features of XML Schema that can be easily mapped to current popular languages (Java, .Net).

    All this argument is like saying, oh Hibernate allows you to generate DB tables from objects and that might turn out to be horrble DB design, so Hibernate is flawed. Just because something is there doesn't mean you got to use it!
  7. All this argument is like saying, oh Hibernate allows you to generate DB tables from objects and that might turn out to be horrble DB design, so Hibernate is flawed. Just because something is there doesn't mean you got to use it!
    Your analogy is flawed as restrictive inheritance is not a "horrible XML design".

    But let's agree for the sake of the argument that we should restrict ourselves to the subset of XML techniques that can be (easily) mapped onto (Java) OO. Why bother then with XML at all? Just use an OO RPC or messaging API, such as JMS or RMI. Even then, how would that solve interop between different languages and different views of what OO is?
  8. All this argument is like saying, oh Hibernate allows you to generate DB tables from objects and that might turn out to be horrble DB design, so Hibernate is flawed. Just because something is there doesn't mean you got to use it!
    Your analogy is flawed as restrictive inheritance is not a "horrible XML design".But let's agree for the sake of the argument that we should restrict ourselves to the subset of XML techniques that can be (easily) mapped onto (Java) OO. Why bother then with XML at all? Just use an OO RPC or messaging API, such as JMS or RMI. Even then, how would that solve interop between different languages and different views of what OO is?

    Agreed. If you want easy marshalling and comms in a single platform, stick to RMI or .NET remoting. These of course have versioning and distributed GC problems, but otherwise everything works nicely, in their closed world.

    But you cannot easily work across platforms. Corba is the best system that is x-platform, but look at its exception model; it is radically different from that of java, because, well, it isnt java.

    JAXRPC1.0 is very much RMI-over-XML; you should be able to talk between compliant implementations, and java types (including faults) get marshalled. But that lulls you into complacency, thinking that it works everywhere.

    Now imagine the caller is running, say, python, or vbscript. what are they going to do.

    -steve
  9. My analogy was referring the criticism that JAX-WS lets generating of WSDL from Java objects/interfaces.

    Well, OO-RPC is tightly coupled to technologies
  10. It's not an all-you-can-eat buffet[ Go to top ]

    JMS is a great vehicle for document-oriented interactions as long as it is within your environment. One should remember that the limitation is not technological, it is political - people just couldn't seem to agree on an efficient binary document exchange standards.
  11. Satus of Alpine[ Go to top ]

    Steve,

    Is "Alpine" stack still in WIP, or has had some alpha/beta releases.

    please do let us know.

    -Abhijeet Rai
  12. I really enjoyed Steve and Edmund's white-paper! Thanks guys!

    Here is the source of some thoughts listed below.

    The World Wide Web Consortium (W3C) defines Web Services as a "standard means of interoperating between different software applications." Well, that is pretty cool. If only we, the industry, could do that:-)

    Some really bright guys at HP, Steve Loughran and Edmund Smith, recently authored an article entitled "Rethinking the Java SOAP Stack." Basically, they suggest, with quite sound evidence, that the current Web service stacks have failed to realize what Web services set out to do in the first place, that is, interoperate. Most Web service (can I just say it already, SOAP) stacks take this great idea of Service Oriented Architecture and bastardize it by applying classic middleware approaches.

    Steve and Edmund do a great job at depicting how we are currently experiencing an impedance mismatch from message (documents) to objects much like we see in the relational database to object mapping world. In short, these really great, flexible technologies like XML and XML Schema are shoved onto OOP. Since XSD and WSDL are at the very least mildly unpleasant to write by hand, the Web service stacks try to help us by making assumptions about document to object mapping. As a result, we as programmers are spared the details of schema and WSDL; however, the framework just serialized a definition of some platform specific data type:-) Now, that won't be very pleasant in another world.

    So, Steve and Edmund accurately point out that what we are left with is a brittle, constrictive approach (much like RMI, Remoting, etc) to some great open, interoperable standards. How did that happen?

    Enter Alpine. The HP crew suggest a lightweight SOAP stack that is only a SOAP stack. By delegating the mapping to the user application, the framework imposes no blanket assumptions about mapping. The caveat, we have more work to do with XML. But, at least, in theory, Alpine will get closer to that interoperable thing that Web services are supposed to do.

    Okay, so now some whimsical questions:

    Why are objects so hard to map to? Impedance this, impedance that. Are our modern-day programming languages in need of some rethinking (in particular, message documents and relational models sort of throw a wrench into OOP when a mapping paradigm is used)? Are SOA concepts creeping into OOP? How could we express SOA better in a high-level language like Java or C#? I mean annotations (and attributes) are great; but, are they really the answer to making services easier to deal with? Personally, I think Steve and Edmund are right; we should suck it up and do contract-first development and work with message objects until there is a better form of expression for services. But, what and when will that form of expression be?

    Thanks Steve and Edmund; I look forward to hearing more about Alpine!
  13. I think it's because contracts sound good, but forcing yourself to see the world one way at compile time just doesn't work as things change and grow.

    The bag-of-bits approach used in messaging means you can toss in all bits you want without hurting anyone who doesn't care. Yes, the navigation is done at runtime, but it's the runtime code you control so can always make changes.
  14. WSDL is just another way for specifying a contract between two
    parties that want to interoperate. I think, also, it was meant to be extensible and transport agnostic. So, people usually think that WSDL means SOAP(XML) over HTTP, but this equation is not mandatory. What I like in WSDL is that it can be a very expressive way for the definition of interaction patterns among distributed peers. What, probably, we have to rethink is that SOAP/HTTP is not the most efficient way for doing RPC, but probably we should force the standard organizations to extend the WSDL to have as transports more efficient protocols.
    Following this way we could use WSDL to describe the
    interfaces of CORBA servers, JMS end-points, and off course,
    SOAP end points. In other words, SOAP and HTTP is just one
    of the many combinations of binding/transport we could model using a unique conceptual framework, the WSDL. This is the philosophy behind the Apache's open source project WSIF and the IONA's product Artix (IONA is the company I belong to).