Monson-Haefel's EJB 2.1 Web Services Article (Part 2) Posted


News: Monson-Haefel's EJB 2.1 Web Services Article (Part 2) Posted

  1. The second part of Richard Monson-Haefel's "EJB 2.1 Web Services" column has been posted on TheServerSide. This installment looks at SAAJ (SOAP with Attachments API for Java) which enables you to build object-oriented representations of SOAP messages, including attachments. The second half of this column looks at why the JAXM API didn't become a part of J2EE.

    Read "EJB 2.1 Web Services (Part 2)" from Richard Monson-Haefel's Guide to Enterprise JavaBeans
  2. I can't believe no one has said anything yet...Sheesh.

    Excellent work, Richard!!

    One question: the de-committment of JAXM - Does this imply that there will be a re-emphasis on JMS? It's hard to imagine that the JCP or BEA or IBM would back off of something like JAXM unless it isn't actually necessary.


    Rich Katz
  3. JAXM isn't necessary. Its semantics are mostly duplicated by JAX-RPC except for profiles, which makes it possible to generate and de-serialize SOAP messages that adhere to some infrastructure protocol like ebXML or GXA. The semantics of profiles in JAXM are not very portable and so that approach has its own problems.

    There are a couple different directions the industry will go on this:

    (1) The JMS vendors could close the gap by enhancing JMS so that its more SOAP friendly. Perhaps adding support for SAAJ and profiles.

    (2) JAX-RPC could be used with a store-and-forward transport. In this case message handlers could do all the work of adding profiles. I think JAX-RPC would need some tweaking to support this sort of functionality. For example, message handlers in JAX-RPC are not portable enough.

    In the mean time, there doesn't seem to be a huge demand for the kind of functionality that JAXM provided. Web services is still young and most people are grappling with the fundamentals and waiting for the Infrastructure Protocol Wars to settle on some clear winners (i.e. ebXML, WS-I, GXA, OASIS, W3C, etc).

    Richard Monson-Haefel
  4. I see how JAX-RPC duplicates JAXM semantics for SOAP-RPC but not for a service client to perfrom general SOAPprocessing.
  5. (sorry for the partial post...that darned "Reply" button...)

    I see how JAX-RPC duplicates JAXM semantics for SOAP-RPC. However, I'm not clear on how a JAX-RPC client performs general SOAP processing. A service can implement ServiceLifecycle and retrieve the SOAPMessageContext so service methods can access the SOAPMessage. But how does a client pass a SOAPMessage? If the client creates a SOAPMessage and passes it to a service method using a DataHandler, for instance, the client's message because a element within the <Body> of the SOAPMessage generated by JAX-RPC. And what if the client needs to add elements to the message <Header> (i.e., use JAX-RPC to send ebXml documents)?

  6. Richard,
    Sonic is working with the Apache Axis group to address these issues. Apache Axis 1.0, which will be released next week, is a full JAX-RPC implementation. We (Sonic) have contributed a JMS transport layer to Axis 1.0 that allows JAX-RPC invocations to be carried over JMS. This includes RPC-style, message-based request/response, and one-way invocations.

    In addition, we have agreement with other JMS vendors on the Axis developer team (IBM, Macromedia) to define an asynchronous callback API to add further support for asynchronous SOAP communications, JMS or otherwise. We will definitely try to draw on previous standards work that has been done, although I can't say for sure at this point whether we would use JAXM.

    Oh yeah, nice article(s) by the way.
  7. Good Articles, I look forward to getting the book (I have all your other books)

    I disagree that JAXM isn't necessary.
    The big difference between JAX-RPC and JAXM is that JAXM has
    the concept of a message provider which takes care of things
    like reliability (based on the profile), and the big
    difference between JAXM and JMS is that JAXM defines interoperability over the wire using SOAP.
    You don't get this just by using JMS and SAAJ together, because JMS does not define the over the wire protocol for interoperability between message providers. This is probably why IBM voted against it, they probably did not want interoperability for their $$ generating MQ series.
    Also JAXM is a better model (than JAX-RPC) for document oriented asynchronous messaging, this was retrofitted into JAX-RPC in my opinion after JAXM lost votes. Asynchronous document oriented messaging with reliability is the preferred way of doing things for B2B communications.
    Therefore JAXM is needed. Currently ebXML messaging vendors exist, but most do not have a common Java API.

    Maybe SAAJ needs some improvements, but interoperability between message providers is the way to go in my opinion.

    Dave Chappell's comments on Axis and JMS are interesting. I
    would still prefer to see JMS vendors offering JAXM options.
  8. I have not been happy with SAAJ so far. Problem I see are

     - not using DOM
       o Integration with third party APIs is hampered by this decision. The reason given in the paper - lack of namespace support - is a poor justification as the namespace support in SAAJ is little better (addNamespaceDeclaration, getNamespacePrefixes) and could easily have been provided in a helper class. Every implementation of SAAJ will have to provide a mechanism to convert back and forth to DOM to allow using DOM based APIs for things like security
      o people are familiar with DOM and there are many mature implementations
      o SAAJ is a subset of DOM and some message information could be lost using the SAAJ model

     - combined abstract factory and parent-as-factory patterns. DOM is document based and so should SAAJ be (the document is the root message part). It should have settled on the parent-as-factory or used a DOM like document concept where the message or SOAPPart acted as the factory. This way the elements could be owned. This would allow easier interaction with DOM

     - the APIs for SOAPElement can potentially cause problems. The various addChildElement methods are a problem because they add a SOAPElement. However, specializations require the children to be of specific (possibly multiple) types. For example, Fault has a Detail and possibly 3 SOAPElement (with fixed names) children. No text. But because Fault extends SOAPElement there is plenty of scope for adding arbitrary elements. To prevent this requires much effort in each specialization (SOAPBody requires SOAPBodyELements, SOAPHeader requires SOAPHeaderElements, etc.)

     - the use of Name means that interracting with other APIs using QNames requires a lot of converting back and forth. Name should have extended QName for maximum interoperability and minimum useless object creation. In fact, since the prefix is redundant in the semantics of the Name on its own (it is only relevant in an element), QName + prefix should have been used instead

     - what is the point of the SOAPBodyElement? Since the body content may actually just be element content for the document/literal case, why would you want it as a SOAPBodyElement, especially when this interface adds no methods

     - SOAPConstants hard-codes the SOAP 1.1 constants. This was even though the authors new that 1.2 was in the pipeline. They have made it pretty tricky to upgrade smoothly

     - the default of creating the SOAPHeader in the envelope is a pain. When parsing extra steps have to be taken to ensure it is removed if not in the message, and when writing extra steps have to be taken to remove it if it is empty. Since it is optional it should not be present by default

     - the Text class provides a method isComment() but no way to create a comment!

     - the MimeHeaders code is a mess of mixed use of String, String[] and MimeHeader. There doesn't seem to be much sense to it and the header APIs are pretty clunky to use

     - ... Can you tell I've been using SAAJ in some detail?

  9. I agree with most, if not all, of what you said. SAAJ can be a pain to work with and its design seems shortsighted at times. I point out a lot of these problems in my J2EE Web Services book, but you mentioned a couple issues that I missed.

    I think the people who designed SAAJ had good intentions. They wanted to make it easy to create and peruse SOAP messages. Unfortunately, the semantics of SAAJ sometimes betray this goal.
  10. Nice article Richard. Good accurate comments from the readers too. Its not part of J2EE, but its part of their JDWSK thingy. Jonathan Schwartz listed it in a speech last week as part of their WS stack to be included in Solaris. Hhhhmmmm. What's the deal with that?

    Keep your eye on Apache Axis.