axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anne Thomas Manes" <>
Subject Re: consequences of choosing axis
Date Sun, 07 Jan 2007 13:46:31 GMT

On 1/6/07, ChadDavis <> wrote:
> Hi.  I'm jut getting started learning about web services, and I've
> decided to use axis2.  I'm trying to figure out whether this choice
> incurs any consequences.  I could have chosen from several other
> platforms that support web service development, obviously.  From what
> I can tell so far, it shouldnt matter, but I'm not that knowledgable
> yet, so I'm asking for other people's advice.

One consequence of selecting Axis2 is that it does not [yet] support
the standard Java APIs for web services (JAX-RPC and JAX-WS). Axis2
uses a platform-specific object model, AXIOM, which is based on StAX,
for processing XML. For the most control, you can use the low-level
API, which represents message data as an OMElement. But you also have
the option of using any data binding system (JAXB, XMLBeans, JiBX,
ADB, etc) to convert the XML messages into Java objects for you. And
Axis2 supports a simple POJO programming model. But none of these APIs
is compliant with JAX-WS or JAX-RPC. If portability of code across
different platforms is important to you, you might want to choose
another platform. (Note that you can deploy Axis2 in pretty much any
servlet engine, but you can't, fo example, take an Axis2 service and
deploy it into Sun's JAX-WS implementation.) Personally, I view
portability of services the way I view portability of EJBs. Very
important if you're building software that you intend to distribute,
but not important for personal or in-house development.

Another consequence of selecting Axis2 is that it does not support
SOAP encoding. If you have the need to implement services using
RPC/encoded, you should select a different platform. Note that many
modern SOAP platforms no longer support SOAP encoding. Unfortunately,
a lot of scripting language platforms assume RPC/encoded, and they
sometimes have difficulty dealing with document/literal.

> My thinking goes
> something like this:  if a web service publishses a WSDL, then the
> client could be built on any web service technology that works with
> WSDL -- correct?  The WSDL is a black box kind of thing and the
> provider and the concsumer ( client ) are completely agnostic to one
> another?  So, if I need to write a client to consumer a web service
> that publishes a WSDL, I can use axis 100% of the time?  Is this true?

That's the way it's supposed to work. But it doesn't always work the
way its supposed to. It is possible to generate a WSDL with Axis2 that
some platforms can't consume. But as long as you follow the guidelines
specified by the WS-I Basic Profile, you should be okay. (But see the
above note regarding scripting languages and doc/literal.) As a
general guideline, never try to expose a Collection via a WSDL
interface. Always convert collections into arrays. Don't try to expose
overloaded operations via a WSDL interface. Don't try to expose
abstract types. Keep your interfaces as flat and non-object-oriented
as possible. Actually, the best approach is to define your message
schema first, then derive your service class from it.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message