Re: consequences of choosing axis

[Angel Todorov <at...@gmail.com>]

In fact any databinding framework in Axis2 relies on AXIOM. Take a
look at the generated stubs/skeletons. They are indeed XML Beans or
JAXB specific, but all of them use AXIOM behind the hood. This means
you have a dependency on axiom, regardless of the databinding you
choose.

fromOM(...), toOM(), and so on...

Regards,
Angel

On 1/7/07, Anne Thomas Manes <at...@gmail.com> wrote:
> Chad,
>
> On 1/6/07, ChadDavis <ch...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

Re: consequences of choosing axis

[Anne Thomas Manes <at...@gmail.com>]

I agree that the impeding JAX-WS stub generation will resolve this
non-standard dependency issue. But going back and looking at my
comments, my whole point was that Axis2 does not currently support the
standard Java APIs (JAX-RPC or JAX-WS). As soon as Axis2 adds support
for JAX-WS, this whole issue is moot.

Anne

On 3/30/07, Paul Fremantle <pz...@gmail.com> wrote:
> I don't really agree with Anne's point. If you use the current Axis2
> WSDL2Java then you are tied to Axis2's current stub model (which is
> pretty POJO like). But inside those stubs you can use
> JAXB/JIBX/XMLBeans, all of which isolate you from AXIOM.
>
> Were you to choose a different stack, your data objects could be
> re-used without any difference in the code you wrote to access those
> data objects. So you would have no dependency on AXIOM. In other
> words, when you write code which uses JIBX/JAXB or XMLBeans, your code
> has no imports of AXIOM.
>
> Now the fact is that our stubs are not so independent, but JAXWS stub
> generation will fix that. So Anne's point is somewhat correct - today
> Axis2 does give you a dependency, but it isnt AXIOM, its the stubs.
>
> Paul
>
> On 3/30/07, Angel Todorov <at...@gmail.com> wrote:
> > In fact any databinding framework in Axis2 relies on AXIOM. Take a
> > look at the generated stubs/skeletons. They are indeed XML Beans or
> > JAXB specific, but all of them use AXIOM behind the hood. This means
> > you have a dependency on axiom, regardless of the databinding you
> > choose.
> >
> > fromOM(...), toOM(), and so on...
> >
> > Regards,
> > Angel
> >
> > On 1/7/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > > Chad,
> > >
> > > On 1/6/07, ChadDavis <ch...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org

Re: consequences of choosing axis

[Paul Fremantle <pz...@gmail.com>]

I don't really agree with Anne's point. If you use the current Axis2
WSDL2Java then you are tied to Axis2's current stub model (which is
pretty POJO like). But inside those stubs you can use
JAXB/JIBX/XMLBeans, all of which isolate you from AXIOM.

Were you to choose a different stack, your data objects could be
re-used without any difference in the code you wrote to access those
data objects. So you would have no dependency on AXIOM. In other
words, when you write code which uses JIBX/JAXB or XMLBeans, your code
has no imports of AXIOM.

Now the fact is that our stubs are not so independent, but JAXWS stub
generation will fix that. So Anne's point is somewhat correct - today
Axis2 does give you a dependency, but it isnt AXIOM, its the stubs.

Paul

On 3/30/07, Angel Todorov <at...@gmail.com> wrote:
> In fact any databinding framework in Axis2 relies on AXIOM. Take a
> look at the generated stubs/skeletons. They are indeed XML Beans or
> JAXB specific, but all of them use AXIOM behind the hood. This means
> you have a dependency on axiom, regardless of the databinding you
> choose.
>
> fromOM(...), toOM(), and so on...
>
> Regards,
> Angel
>
> On 1/7/07, Anne Thomas Manes <at...@gmail.com> wrote:
> > Chad,
> >
> > On 1/6/07, ChadDavis <ch...@gmail.com> 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: axis-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-user-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>


-- 
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org