Skip to main content

Why rethink the Java SOAP stack ?

Posted by arungupta on June 7, 2005 at 9:52 AM PDT

Steve Loughran and Edmund Smith, from HP Labs, published a paper
on "Rethinking the Java SOAP Stack". The paper examines JAX-RPC
programming model for Web services. Here I post my comments on the article.

Marc Hadley posted his comments
last week. And I agree with Marc that the paper is based upon JAX-RPC 1.1 and
ignored the advances made in JAX-WS
(Java API for XML Web Services, nee JAX-RPC 2.0). Again, it is mainly focused on
XML <-> Object mapping and have mentioned about interoperability concerns
at multiple places as well.

I've been with the JAX-RPC team since it's inception (phew, that's almost 4
yrs now) and so have a strong sense of belonging (read passion) for the
technology. I used JAX-RPC 1.0 implementation for SOAPBuilders
interoperability
testing
. I also represent Sun in WS-I Sample
Applications Working Group
and have used JAX-RPC 1.1 implementation (SI,
available in Java Web
Services Developer Pack
and Sun
Java System Application Server
) for interoperability testing
there. This implementation has been tested for interoperability with all the
major players including IBM, Microsoft,
Oracle, BEA,
and SAP. Most of  the vendors are in
different time zones, using different operating systems, using different
platforms, and using different language and fully interoperate with each other.
For folks not familiar with the sample applications, read this.
A short summary is that the WS-I Sample Applications consists of 8 different Web
services that enables potentially 8 vendor to be able to demonstrate
interoperability with each other. 

Key Message: Production-quality
and interoperable
JAX-RPC standard implementation is available for past 3 years. We've tested it
pretty hard for full compliance with Basic
Profile 1.1
, Simple
SOAP Binding Profile 1.0
, Attachment
Profile 1.0
.

Lets clarify some of the points mentioned in the paper.

  1. Section, Part A, bullet 1 talks about accurately modeling an
    XSD type hierarchy in a Java class hierarchy. I think the issue is more to
    do with schema validation rather than representing in a Java class
    hierarchy. I don't know of any SOAP processor that validate the schemas (at least
    by default) for performance reasons.

  2. Section I, Part A, bullet 2 says: 



    The dispatch of operations to Java methods, Enterprise Java Bean
        methods or other destinations is generally implemented by specific handlers,
        making the handler chain the foundation for the rest of the system.

    Neither the JAX-RPC 1.1
    specification
    , nor the JAX-RPC reference
    implementation
    require using handlers for dispatching operations to Java
    methods. Anybody is free to make their own proprietary dispatching mechanism
    based upon handlers and thus mandating the dispatch handler on the service
    endpoint. Here are couple of quotes from Chapter 12 of JAX-RPC 1.1 spec:

    A typical use of a SOAP message handler is to process
        the SOAP header blocks as part of the processing of an RPC request or
        response.

    The dispatching information exists in the body, so wonder how handlers
    can be used for that purpose at all.

    SOAP message handlers are tied to web service
        endpoints (either on client or server) and are used to provide additional
        SOAP message processing facility as an extension to these components.

    The keyword is "additional". Handlers do not
    provide the core information like which method to dispatch. 

  3. Section, Part II, bullet 3 says:



    The defect would only show up in interoperability testing.



    WS-I Sample Applications does use enumerations and yes, JAX-RPC mapping of
    enumerations is fully interoperable with other language/platform/operating
    systems.

  4. Section II, Part A, bullet 4 says:



    If both client and server are in the UTC time zone all works well, but
        if either of them are in a different location, hours appear to get added or
        removed. Clearly a different expectation regarding time processing is at
        work.

    This is an insidious defect as it is not apparent on
        any testing which takes place in the same time zone, or between Java
        implementations. It is only apparent when remote callers, using different
        platforms, attempt to use the service.




    Again, WS-I Sample Applications use xsd:dateTime in their
    LoggingFacility Web service, and as you expect, it is fully interoperable in spite
    of multiple time zones, multiple operating systems and multiple languages.
  5. Section II, Part A, bullet 6 says:

    We therefore believe that future versions of JAX-RPC
        will address this problem by way of the annotation facility recently added
        to the Java language.

    JAX-WS 2.0
    is doing exactly that for past one year and this paper was written quite
    recently only.

  6. Section II, Part A, bullet 7 says:

    When a message is received, the serialised form is
        generated and passed to the handlers for processing.

    I think this statement relies from the assumption that
    handlers are used for message dispatching. But as I mentioned earlier, that
    is not the recommended programming model in JAX-RPC 1.1.

  7. Section II, Part A, bullet 8 says:

    Any O/X mappings which may exist for data within this
        piece of the message are now inaccessible: all that is left is the low-level
        JAXM API.

    I believe this is better than dealing everything in raw XML.
    And all SAAJ (not JAXM) elements are now accessible as DOM elements so if
    you really want to play with XML, it's all for you. Rather JAX-RPC 1.1 SI
    allows you to turn off data binding so that all method parameters are indeed
    bound to SOAPElement instead of JAX-RPC defined data binding.

  8. Section II, Part A, bullet 9 says:



    In our opinion, the only sensible approach for working with faults in
        JAX-RPC is to have services throw pure SOAP faults and leave it to the
        recipient to process them.

    I agree that Web service developer should have some
    knowledge of XML, but here we are asking the developer to be intimately
    familiar with understanding the SOAP fault structure and know the SOAP
    processing rules regarding faults. In that case who takes care of Basic
    Profile conformance, the developer ?

  9. Section II, Part B talks about long-haul connections and
    asynchronous communication:

    While this works, it provides the programmer no way to
        give the user effective feedback or control over the communications. There
        is no way to receive progress notifications or cancel an active call,
        despite the face that the underlying transport code invariably permits such
        features.

    JAX-WS 2.0 introduces client-side asynchrony. Read Doug
    Kohlert
    's blog
    entry
    for detailed list of new features in JAX-WS 2.0 and a code sample
    of how to achieve asynchronous communication. It allows a user to poll
    whether an operation has been completed on the service endpoint and also
    allow to cancel the execution of the current task as well.

  10. Section III, says:

    JAX-RPC makes it harder to write true, interoperable
        SOAP services.

    I feel that any Web service developed using JAX-RPC is
    interoperable since interoperability is baked into JAX-RPC specification
    since JAX-RPC 1.1 requires conformance with WS-I Basic
    Profile
    .

    Have a look at the Sun's WS-I Sample Application source code
    bundled with JWSDP.
    If you ignore the business logic part of the Web service, I think it's
    really simple to write a SOAP-based Web service, which by the fact that it
    is developed using JAX-RPC, is interoperable. In JAX-WS 2.0, this
    programming model is made really intuitive and further simplified to write a
    SOAP-based Web service, and of course by the fact it is developed using JAX-WS,
    is interoperable by default. JAX-WS 2.0 source code repository is available here.
    Check out Doug's blog
    on how to check out the repository. Once you check out the repository go to
    the samples directory and have a look at some of the simple
    samples. I plan to check in many more samples later this week.

There are many points that I don't like about the
"Alpine" proposal but my big ones are

  1. Section IV, Part A says:

    If a WSDL/XSD description of an Alpine-hosted service
        is required, the user will be required to write it

    It's hard to believe the paper expects the developer to
    understand all the WSDL intricacies and subtleties of XSD. Web services is
    not meant for the privileged few. I don't think we could have made the
    progress in Web services if everybody would have been hand editing all their
    WSDL/XSD.

  2. It further says:

    Developers will be expected to use XPath
        specifications to work with contents of the message

    As if WSDL/XSD was not sufficient, XPath syntax adds to all
    of it.

  3. Who takes care of interoperability with different WS-I
    profiles ?

I believe, Web services should be for anybody and everybody
irrespective of whether they know XML or not. JAX-RPC hides all these plumbing
details from you. JAX-WS 2.0 further leverages that to ease the development of a
Web service and invoke an already existing one. JAX-WS 2.0 EA2 bits will be
available in next few weeks (before JavaOne) with bunch of samples and hopefully
you'll enjoy playing with them.

Let me repeat the key message: Production-quality
and interoperable
JAX-RPC standard implementation is available for past 3 years. We've tested it
pretty hard for full compliance with Basic
Profile 1.1
, Simple
SOAP Binding Profile 1.0
, Attachment
Profile 1.0
. JAX-WS 2.0 standard implementation will be available in the
next version of Sun Java System Application Server 9.0, expected to go final
next year.

JAX-WS is developed as JSR
224
in the Java Community Process and the
Expert Group consists of a wide variety of representation from the developer
community. They have done their due diligence to produce a feature-loaded, useful and
interoperable specification to support XML (and thus a subset, SOAP) Web Services in the
Java platform. Why rethink the Java SOAP stack ?

 

Related Topics >>