Message-orientation in Axis 2.0

The “Web Services Messaging with Apache Axis2: Concepts and Techniques” article is a good introductory read for those who are still trying to understand the difference between explicit (SOAP-based) messaging and Remote Procedure Calls (RPCs)! I don’t think I need to write anything more in relation to the discussion on whether SOAP and Web Services equal to RPC even though I think there is much more into message-orientation (e.g. MEST :-).

The above article also briefly introduces the new Axis 2 API for In-Only and In-Out MEPs. Now, if anyone from Axis 2 is listening… how about renaming the ‘Call’ class to ‘Message’ and use methods like ‘send’ rather than ‘invoke’?

Thanks to Spiros Tzavellas for bringing the article to my attention.

6 responses to “Message-orientation in Axis 2.0”

  1. “(OMElement) call.invokeBlocking( operationName.getLocalPart(), payload);”

    Hmm, what’s wrong with that from a messaging/MEST POV?

    I personally think that article provides a poor description of the differences between messaging and RPC. It doesn’t even mention the most important difference, and, as above, the examples all disregard it! You know the difference I’m speaking of, Savas. 😎

  2. Hey Mark, I agree that the article doesn’t provide a great description of message-orientation. I too mentioned that in the post. However, I do believe that it’s a very simple introduction to the differences between messaging and RPC. When there are people who say that SOAP == RPC, I think they need to start from something like this. I do agree that uniformity of operations :-), message/state transfer, self-description, semantics, and all the other fun stuff that we talk about are not touched.

    About the ‘call.invokeBlocking’ thing. There is nothing really wrong from a messaging POV. It’s just that if one is sending a message, why presend to the developers abstractions like ‘call’ and ‘invoke’. Some may be confused and still think that they are calling a remote procedure.

  3. I was actually thinking about the “operationName.getLocalPart()” part. Why is that there? Older versions of the Axis2 API didn’t have it, and instead just had a very nice document oriented API. I hope the operation name doesn’t go out on the wire, but I wonder why it’s there at all.

    P.S. hi from London!

  4. Hey Mark,

    London eh? If you happen to come up North, let me know 🙂

    I hadn’t noticed the ‘operationName’ thing. I only paid attention to the name of the classes. Yup… I agree with you. That shouldn’t be there.

  5. Yes, we are listening. added a JIRA entry to track this. http://issues.apache.org/jira/browse/AXIS2-119

    Yes, we had major discussions on Call->Message during our F2F.

  6. Great stuff Dims! Thanks!

    I wasn’t aware of your blog. Subscribed now!