I have a problem that I was hoping someone already has solved.
My team is somewhat divided over using Axis 1.x and Axis2. The issue is that Axis2 doesn't really support RPC/encoded web services fully and an application that we need to interface with as a client uses that with Axis 1.4. My gut feeling is to stick with Axis2, since it is now stable and seems to be where everyone is going.
So, my questions are:
1. Does Axis2 support RPC/encoded web services well enough to just use that? Documents say that it supports RPC/lit only.
2.Would there be a problem with using both Axis 1.x AND Axis2, basically tying the client that interfaces with the Axis 1.x application to Axis 1.x and moving forward with all other web interfaces using Axis2. Has anyone out there done this?
Also, if everyone using a certain version of Axis may be tied to only others using that version, what is the point of using web services for interoperability anyway?
Originally posted by Scott Wilson: Also, if everyone using a certain version of Axis may be tied to only others using that version, what is the point of using web services for interoperability anyway?
The point is that RPC/encoded was one of the major obstacles to interoperability which is why most current SOAP stacks have abandoned it. WS-I Basic Profile 1.0a was the first standard to concern itself with web services interoperability and it allowed only literal XML.
In the days of Axis 1.x everybody wanted to beam their objects over the internet - which they could as long as they were willing to write their own serializers/deserializers - which effectively tied both ends to those serializers/deserializers on Axis.
While everybody is able to handle HTTP connections and parse XML, the data carried by the XML has to be interpreted in the context of the (non-interoperable) processing platform. JVM Objects aren't interopable, CLR objects aren't interoperable, etc.
As long as everybody exchanges easily decipherable XML messages, everything is OK.