You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by ChadDavis <ch...@gmail.com> on 2007/01/07 00:46:40 UTC
consequences of choosing axis
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. 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?
---------------------------------------------------------------------
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
Posted by 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
Posted by 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
Re: consequences of choosing axis
Posted by 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
Posted by Davanum Srinivas <da...@gmail.com>.
Anne,
FYI, We just released 1.1.1 this morning. We are shooting for full
JAX-WS/JAXB compliance for Axis2 1.2. Significant work has already
been done, we are in the queue for TCK access :)
thanks,
dims
On 1/10/07, Anne Thomas Manes <at...@gmail.com> wrote:
> Yogen,
>
> That is your opinion, and you're welcome to it. But that's because
> JAX-RPC and JAX-WS compliance isn't important to you.
>
> But let me give an example of where it might be important.
>
> Let's say you purchase a piece of software that was implemented using
> JAX-RPC or JAX-WS. You cannot deploy that software on Axis2. Fine --
> you get some other platform to host this particular piece of software.
> But now you have to configure and manage two different SOAP platforms.
> Let's say the software that you want to use is a JAX-RPC handler.
> (e.g., maybe you want to use AmberPoint to manage your application.)
> You can't take that JAX-RPC handler and plug it into Axis2 as a module
> because it supports a different API.
>
> You may not view this as a "consequence", but someone else might.
>
> I don't fault the Axis2 team for making a decision to go with a more
> elegant architecture and object model that that prescribed by JAX-RPC
> and JAX-WS. In fact, I applaud it. But there is a consequence
> associated with that decision.
>
> Anne
>
> On 1/10/07, Yadav, Yogendra (IT) <Yo...@morganstanley.com> wrote:
> > Anne,
> > I think the point is moot. As long as it exposes standard APIs or work
> > with standard frameworks, a framework should be free to use any object
> > model internally.
> >
> > Which way one wants to model clients and services is a design time
> > decision and its always the case even when so called *standard*
> > frameworks are used (as a matter of fact JAX-RPC and JAX-WS are not
> > interoperable). Everyone knows it takes time for standards to catch up
> > and more time for standards compliant products to be available.
> > Constraining the design around half baked standards is probably not
> > necessary.
> >
> > IMHO it's a design time decision to ask which way I want to model
> > clients and services...
> > 1. Use standards compliant databindings
> > 2. Work directly with Stax
> > 3. Work with AXIOM (so be proprietary!!)
> > 4. Use none of the above and build SOAP messages my own way (most
> > portable way)
> >
> > -yogen
> >
> >
> >
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> > Sent: Tuesday, January 09, 2007 7:43 PM
> > To: axis-user@ws.apache.org
> > Subject: Re: consequences of choosing axis
> >
> > Yes. Axis2 communicates via SOAP, and supports reasonable
> > interoperability with any other web services platform that communicates
> > via SOAP. That is not the issue or consequence I'm talking about.
> >
> > If the client is implemented using AXIOM, then it is tied to AXIOM.
> > You cannot switch to Sun's JAX-WS RI without rewriting your code.
> > Likewise, if the service is implemented with AXIOM, then it is tied to
> > AXIOM. Again, you cannot switch to IBM's JAX-WS implementation without
> > rewriting your code.
> >
> > AXIOM is a non-standard programming model. That's not necessarily a bad
> > thing, but it does have consequences. It's like implementing an
> > application using the project-specific APIs in Hibernate, Spring,
> > Struts, or any other open source project that defines its own
> > project-specific API (i.e, not a JSR-sanctioned API).
> >
> > The fact that Axis2 supports a variety of databinding frameworks does
> > not change the fact that it does not support JAX-RPC or JAX-WS. If
> > standard Java API support is important to you, then this is an important
> > issue. If you have no objection to using a propriatary programming
> > model, then it is not an important issue. But it is still an issue that
> > has consequences.
> >
> > Anne
> >
> > On 1/9/07, Yadav, Yogendra (IT) <Yo...@morganstanley.com>
> > wrote:
> > > Clients don't have to use AXIOM. Clients could construct a WS-I
> > > compliant SOAP message whichever way they can, .Net, C++ or Perl
> > > clients would do this.
> > >
> > > Since JAXB and other databindings are supported, server side need not
> > > use AXIOM either. Only if you choose no-databinding, you would be
> > > dealing with AXIOM on the server side.
> > >
> > > HTH
> > > -yogen
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> > > Sent: Tuesday, January 09, 2007 6:58 PM
> > > To: axis-user@ws.apache.org
> > > Subject: Re: consequences of choosing axis
> > >
> > > Sorry for being vague. I was referring to the SOAP platform, not the
> > > underlying servlet/J2EE platform. As I said, Axis2 can be deployed on
> > > any platform. But AXIOM is particular to Axis2. (It is a separate
> > > project, and other SOAP platforms could use it, but to date, the only
> > > other project that I know of that uses AXIOM is Synapse.)
> > >
> > > The impact of using a platform-specific object model is that your
> > > client/service code is not portable across other SOAP platforms.
> > >
> > > Anne
> > >
> > > On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> > > > Anne,
> > > >
> > > > >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.
> > > >
> > > > This may be a dumb question, but what do you mean by platform
> > > > specific
> > >
> > > > object model? How is AXIOM platform specific? I'm thinking that
> > > > its all Java so . . . and I don't recall choosing a particular
> > > > platform flavor of the AXIS2 distribution?
> > > >
> > > > --------------------------------------------------------------------
> > > > - 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
> > > --------------------------------------------------------
> > >
> > > NOTICE: If received in error, please destroy and notify sender. Sender
> > does not intend to waive confidentiality or privilege. Use of this email
> > is prohibited when received in error.
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
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
Posted by "Yadav, Yogendra (IT)" <Yo...@morganstanley.com>.
Thanx Anne. I completely understand your point of view and may be you
have this problem at your hand.
I still think the sound design decisions made upfront in the project
lifecycle and enforced during implementation would not have mixed
platform specific code in the implementation. And, whenever this was
necessary, adapter/factory and such patterns would have been called for
isolating such code - yes, this is postmortem on which I don't want to
dwell anymore :)
-----Original Message-----
From: Anne Thomas Manes [mailto:atmanes@gmail.com]
Sent: Wednesday, January 10, 2007 11:00 AM
To: axis-user@ws.apache.org
Subject: Re: consequences of choosing axis
Yogen,
That is your opinion, and you're welcome to it. But that's because
JAX-RPC and JAX-WS compliance isn't important to you.
But let me give an example of where it might be important.
Let's say you purchase a piece of software that was implemented using
JAX-RPC or JAX-WS. You cannot deploy that software on Axis2. Fine -- you
get some other platform to host this particular piece of software.
But now you have to configure and manage two different SOAP platforms.
Let's say the software that you want to use is a JAX-RPC handler.
(e.g., maybe you want to use AmberPoint to manage your application.) You
can't take that JAX-RPC handler and plug it into Axis2 as a module
because it supports a different API.
You may not view this as a "consequence", but someone else might.
I don't fault the Axis2 team for making a decision to go with a more
elegant architecture and object model that that prescribed by JAX-RPC
and JAX-WS. In fact, I applaud it. But there is a consequence associated
with that decision.
Anne
On 1/10/07, Yadav, Yogendra (IT) <Yo...@morganstanley.com>
wrote:
> Anne,
> I think the point is moot. As long as it exposes standard APIs or work
> with standard frameworks, a framework should be free to use any object
> model internally.
>
> Which way one wants to model clients and services is a design time
> decision and its always the case even when so called *standard*
> frameworks are used (as a matter of fact JAX-RPC and JAX-WS are not
> interoperable). Everyone knows it takes time for standards to catch up
> and more time for standards compliant products to be available.
> Constraining the design around half baked standards is probably not
> necessary.
>
> IMHO it's a design time decision to ask which way I want to model
> clients and services...
> 1. Use standards compliant databindings 2. Work directly with Stax 3.
> Work with AXIOM (so be proprietary!!) 4. Use none of the above and
> build SOAP messages my own way (most portable way)
>
> -yogen
>
>
>
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> Sent: Tuesday, January 09, 2007 7:43 PM
> To: axis-user@ws.apache.org
> Subject: Re: consequences of choosing axis
>
> Yes. Axis2 communicates via SOAP, and supports reasonable
> interoperability with any other web services platform that
> communicates via SOAP. That is not the issue or consequence I'm
talking about.
>
> If the client is implemented using AXIOM, then it is tied to AXIOM.
> You cannot switch to Sun's JAX-WS RI without rewriting your code.
> Likewise, if the service is implemented with AXIOM, then it is tied to
> AXIOM. Again, you cannot switch to IBM's JAX-WS implementation without
> rewriting your code.
>
> AXIOM is a non-standard programming model. That's not necessarily a
> bad thing, but it does have consequences. It's like implementing an
> application using the project-specific APIs in Hibernate, Spring,
> Struts, or any other open source project that defines its own
> project-specific API (i.e, not a JSR-sanctioned API).
>
> The fact that Axis2 supports a variety of databinding frameworks does
> not change the fact that it does not support JAX-RPC or JAX-WS. If
> standard Java API support is important to you, then this is an
> important issue. If you have no objection to using a propriatary
> programming model, then it is not an important issue. But it is still
> an issue that has consequences.
>
> Anne
>
> On 1/9/07, Yadav, Yogendra (IT) <Yo...@morganstanley.com>
> wrote:
> > Clients don't have to use AXIOM. Clients could construct a WS-I
> > compliant SOAP message whichever way they can, .Net, C++ or Perl
> > clients would do this.
> >
> > Since JAXB and other databindings are supported, server side need
> > not use AXIOM either. Only if you choose no-databinding, you would
> > be dealing with AXIOM on the server side.
> >
> > HTH
> > -yogen
> >
> >
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> > Sent: Tuesday, January 09, 2007 6:58 PM
> > To: axis-user@ws.apache.org
> > Subject: Re: consequences of choosing axis
> >
> > Sorry for being vague. I was referring to the SOAP platform, not the
> > underlying servlet/J2EE platform. As I said, Axis2 can be deployed
> > on any platform. But AXIOM is particular to Axis2. (It is a separate
> > project, and other SOAP platforms could use it, but to date, the
> > only other project that I know of that uses AXIOM is Synapse.)
> >
> > The impact of using a platform-specific object model is that your
> > client/service code is not portable across other SOAP platforms.
> >
> > Anne
> >
> > On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> > > Anne,
> > >
> > > >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.
> > >
> > > This may be a dumb question, but what do you mean by platform
> > > specific
> >
> > > object model? How is AXIOM platform specific? I'm thinking that
> > > its all Java so . . . and I don't recall choosing a particular
> > > platform flavor of the AXIS2 distribution?
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - 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
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender.
> > Sender
> does not intend to waive confidentiality or privilege. Use of this
> email is prohibited when received in error.
> >
> > --------------------------------------------------------------------
> > - 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
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this email
is prohibited when received in error.
>
> ---------------------------------------------------------------------
> 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
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
---------------------------------------------------------------------
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
Posted by Anne Thomas Manes <at...@gmail.com>.
Yogen,
That is your opinion, and you're welcome to it. But that's because
JAX-RPC and JAX-WS compliance isn't important to you.
But let me give an example of where it might be important.
Let's say you purchase a piece of software that was implemented using
JAX-RPC or JAX-WS. You cannot deploy that software on Axis2. Fine --
you get some other platform to host this particular piece of software.
But now you have to configure and manage two different SOAP platforms.
Let's say the software that you want to use is a JAX-RPC handler.
(e.g., maybe you want to use AmberPoint to manage your application.)
You can't take that JAX-RPC handler and plug it into Axis2 as a module
because it supports a different API.
You may not view this as a "consequence", but someone else might.
I don't fault the Axis2 team for making a decision to go with a more
elegant architecture and object model that that prescribed by JAX-RPC
and JAX-WS. In fact, I applaud it. But there is a consequence
associated with that decision.
Anne
On 1/10/07, Yadav, Yogendra (IT) <Yo...@morganstanley.com> wrote:
> Anne,
> I think the point is moot. As long as it exposes standard APIs or work
> with standard frameworks, a framework should be free to use any object
> model internally.
>
> Which way one wants to model clients and services is a design time
> decision and its always the case even when so called *standard*
> frameworks are used (as a matter of fact JAX-RPC and JAX-WS are not
> interoperable). Everyone knows it takes time for standards to catch up
> and more time for standards compliant products to be available.
> Constraining the design around half baked standards is probably not
> necessary.
>
> IMHO it's a design time decision to ask which way I want to model
> clients and services...
> 1. Use standards compliant databindings
> 2. Work directly with Stax
> 3. Work with AXIOM (so be proprietary!!)
> 4. Use none of the above and build SOAP messages my own way (most
> portable way)
>
> -yogen
>
>
>
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> Sent: Tuesday, January 09, 2007 7:43 PM
> To: axis-user@ws.apache.org
> Subject: Re: consequences of choosing axis
>
> Yes. Axis2 communicates via SOAP, and supports reasonable
> interoperability with any other web services platform that communicates
> via SOAP. That is not the issue or consequence I'm talking about.
>
> If the client is implemented using AXIOM, then it is tied to AXIOM.
> You cannot switch to Sun's JAX-WS RI without rewriting your code.
> Likewise, if the service is implemented with AXIOM, then it is tied to
> AXIOM. Again, you cannot switch to IBM's JAX-WS implementation without
> rewriting your code.
>
> AXIOM is a non-standard programming model. That's not necessarily a bad
> thing, but it does have consequences. It's like implementing an
> application using the project-specific APIs in Hibernate, Spring,
> Struts, or any other open source project that defines its own
> project-specific API (i.e, not a JSR-sanctioned API).
>
> The fact that Axis2 supports a variety of databinding frameworks does
> not change the fact that it does not support JAX-RPC or JAX-WS. If
> standard Java API support is important to you, then this is an important
> issue. If you have no objection to using a propriatary programming
> model, then it is not an important issue. But it is still an issue that
> has consequences.
>
> Anne
>
> On 1/9/07, Yadav, Yogendra (IT) <Yo...@morganstanley.com>
> wrote:
> > Clients don't have to use AXIOM. Clients could construct a WS-I
> > compliant SOAP message whichever way they can, .Net, C++ or Perl
> > clients would do this.
> >
> > Since JAXB and other databindings are supported, server side need not
> > use AXIOM either. Only if you choose no-databinding, you would be
> > dealing with AXIOM on the server side.
> >
> > HTH
> > -yogen
> >
> >
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> > Sent: Tuesday, January 09, 2007 6:58 PM
> > To: axis-user@ws.apache.org
> > Subject: Re: consequences of choosing axis
> >
> > Sorry for being vague. I was referring to the SOAP platform, not the
> > underlying servlet/J2EE platform. As I said, Axis2 can be deployed on
> > any platform. But AXIOM is particular to Axis2. (It is a separate
> > project, and other SOAP platforms could use it, but to date, the only
> > other project that I know of that uses AXIOM is Synapse.)
> >
> > The impact of using a platform-specific object model is that your
> > client/service code is not portable across other SOAP platforms.
> >
> > Anne
> >
> > On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> > > Anne,
> > >
> > > >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.
> > >
> > > This may be a dumb question, but what do you mean by platform
> > > specific
> >
> > > object model? How is AXIOM platform specific? I'm thinking that
> > > its all Java so . . . and I don't recall choosing a particular
> > > platform flavor of the AXIS2 distribution?
> > >
> > > --------------------------------------------------------------------
> > > - 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
> > --------------------------------------------------------
> >
> > NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this email
> is prohibited when received in error.
> >
> > ---------------------------------------------------------------------
> > 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
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
>
> ---------------------------------------------------------------------
> 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
Posted by Anne Thomas Manes <at...@gmail.com>.
Yes -- non-standard.
On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> Anne,
>
> Thanks. The comparison to other "frameworks" makes this perfectly
> clear, almost to the "duh" point. By proprietary you don't mean non
> open source do you? Just non-standard?
>
> Chad
>
>
> > The fact that Axis2 supports a variety of databinding frameworks does
> > not change the fact that it does not support JAX-RPC or JAX-WS. If
> > standard Java API support is important to you, then this is an
> > important issue. If you have no objection to using a propriatary
> > programming model, then it is not an important issue. But it is still
> > an issue that has consequences.
> >
>
> ---------------------------------------------------------------------
> 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
Posted by ChadDavis <ch...@gmail.com>.
Anne,
Thanks. The comparison to other "frameworks" makes this perfectly
clear, almost to the "duh" point. By proprietary you don't mean non
open source do you? Just non-standard?
Chad
> The fact that Axis2 supports a variety of databinding frameworks does
> not change the fact that it does not support JAX-RPC or JAX-WS. If
> standard Java API support is important to you, then this is an
> important issue. If you have no objection to using a propriatary
> programming model, then it is not an important issue. But it is still
> an issue that has consequences.
>
---------------------------------------------------------------------
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
Posted by "Yadav, Yogendra (IT)" <Yo...@morganstanley.com>.
Anne,
I think the point is moot. As long as it exposes standard APIs or work
with standard frameworks, a framework should be free to use any object
model internally.
Which way one wants to model clients and services is a design time
decision and its always the case even when so called *standard*
frameworks are used (as a matter of fact JAX-RPC and JAX-WS are not
interoperable). Everyone knows it takes time for standards to catch up
and more time for standards compliant products to be available.
Constraining the design around half baked standards is probably not
necessary.
IMHO it's a design time decision to ask which way I want to model
clients and services...
1. Use standards compliant databindings
2. Work directly with Stax
3. Work with AXIOM (so be proprietary!!)
4. Use none of the above and build SOAP messages my own way (most
portable way)
-yogen
-----Original Message-----
From: Anne Thomas Manes [mailto:atmanes@gmail.com]
Sent: Tuesday, January 09, 2007 7:43 PM
To: axis-user@ws.apache.org
Subject: Re: consequences of choosing axis
Yes. Axis2 communicates via SOAP, and supports reasonable
interoperability with any other web services platform that communicates
via SOAP. That is not the issue or consequence I'm talking about.
If the client is implemented using AXIOM, then it is tied to AXIOM.
You cannot switch to Sun's JAX-WS RI without rewriting your code.
Likewise, if the service is implemented with AXIOM, then it is tied to
AXIOM. Again, you cannot switch to IBM's JAX-WS implementation without
rewriting your code.
AXIOM is a non-standard programming model. That's not necessarily a bad
thing, but it does have consequences. It's like implementing an
application using the project-specific APIs in Hibernate, Spring,
Struts, or any other open source project that defines its own
project-specific API (i.e, not a JSR-sanctioned API).
The fact that Axis2 supports a variety of databinding frameworks does
not change the fact that it does not support JAX-RPC or JAX-WS. If
standard Java API support is important to you, then this is an important
issue. If you have no objection to using a propriatary programming
model, then it is not an important issue. But it is still an issue that
has consequences.
Anne
On 1/9/07, Yadav, Yogendra (IT) <Yo...@morganstanley.com>
wrote:
> Clients don't have to use AXIOM. Clients could construct a WS-I
> compliant SOAP message whichever way they can, .Net, C++ or Perl
> clients would do this.
>
> Since JAXB and other databindings are supported, server side need not
> use AXIOM either. Only if you choose no-databinding, you would be
> dealing with AXIOM on the server side.
>
> HTH
> -yogen
>
>
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> Sent: Tuesday, January 09, 2007 6:58 PM
> To: axis-user@ws.apache.org
> Subject: Re: consequences of choosing axis
>
> Sorry for being vague. I was referring to the SOAP platform, not the
> underlying servlet/J2EE platform. As I said, Axis2 can be deployed on
> any platform. But AXIOM is particular to Axis2. (It is a separate
> project, and other SOAP platforms could use it, but to date, the only
> other project that I know of that uses AXIOM is Synapse.)
>
> The impact of using a platform-specific object model is that your
> client/service code is not portable across other SOAP platforms.
>
> Anne
>
> On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> > Anne,
> >
> > >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.
> >
> > This may be a dumb question, but what do you mean by platform
> > specific
>
> > object model? How is AXIOM platform specific? I'm thinking that
> > its all Java so . . . and I don't recall choosing a particular
> > platform flavor of the AXIS2 distribution?
> >
> > --------------------------------------------------------------------
> > - 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
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this email
is prohibited when received in error.
>
> ---------------------------------------------------------------------
> 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
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
---------------------------------------------------------------------
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
Posted by Anne Thomas Manes <at...@gmail.com>.
Yes. Axis2 communicates via SOAP, and supports reasonable
interoperability with any other web services platform that
communicates via SOAP. That is not the issue or consequence I'm
talking about.
If the client is implemented using AXIOM, then it is tied to AXIOM.
You cannot switch to Sun's JAX-WS RI without rewriting your code.
Likewise, if the service is implemented with AXIOM, then it is tied to
AXIOM. Again, you cannot switch to IBM's JAX-WS implementation without
rewriting your code.
AXIOM is a non-standard programming model. That's not necessarily a
bad thing, but it does have consequences. It's like implementing an
application using the project-specific APIs in Hibernate, Spring,
Struts, or any other open source project that defines its own
project-specific API (i.e, not a JSR-sanctioned API).
The fact that Axis2 supports a variety of databinding frameworks does
not change the fact that it does not support JAX-RPC or JAX-WS. If
standard Java API support is important to you, then this is an
important issue. If you have no objection to using a propriatary
programming model, then it is not an important issue. But it is still
an issue that has consequences.
Anne
On 1/9/07, Yadav, Yogendra (IT) <Yo...@morganstanley.com> wrote:
> Clients don't have to use AXIOM. Clients could construct a WS-I
> compliant SOAP message whichever way they can, .Net, C++ or Perl clients
> would do this.
>
> Since JAXB and other databindings are supported, server side need not
> use AXIOM either. Only if you choose no-databinding, you would be
> dealing with AXIOM on the server side.
>
> HTH
> -yogen
>
>
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:atmanes@gmail.com]
> Sent: Tuesday, January 09, 2007 6:58 PM
> To: axis-user@ws.apache.org
> Subject: Re: consequences of choosing axis
>
> Sorry for being vague. I was referring to the SOAP platform, not the
> underlying servlet/J2EE platform. As I said, Axis2 can be deployed on
> any platform. But AXIOM is particular to Axis2. (It is a separate
> project, and other SOAP platforms could use it, but to date, the only
> other project that I know of that uses AXIOM is Synapse.)
>
> The impact of using a platform-specific object model is that your
> client/service code is not portable across other SOAP platforms.
>
> Anne
>
> On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> > Anne,
> >
> > >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.
> >
> > This may be a dumb question, but what do you mean by platform specific
>
> > object model? How is AXIOM platform specific? I'm thinking that its
> > all Java so . . . and I don't recall choosing a particular platform
> > flavor of the AXIS2 distribution?
> >
> > ---------------------------------------------------------------------
> > 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
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
>
> ---------------------------------------------------------------------
> 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
Posted by Davanum Srinivas <da...@gmail.com>.
Anne,
FYI, Spring-WS supports AXIOM too.
thanks,
-- dims
On 1/9/07, Anne Thomas Manes <at...@gmail.com> wrote:
> Sorry for being vague. I was referring to the SOAP platform, not the
> underlying servlet/J2EE platform. As I said, Axis2 can be deployed on
> any platform. But AXIOM is particular to Axis2. (It is a separate
> project, and other SOAP platforms could use it, but to date, the only
> other project that I know of that uses AXIOM is Synapse.)
>
> The impact of using a platform-specific object model is that your
> client/service code is not portable across other SOAP platforms.
>
> Anne
>
> On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> > Anne,
> >
> > >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.
> >
> > This may be a dumb question, but what do you mean by platform specific
> > object model? How is AXIOM platform specific? I'm thinking that its
> > all Java so . . . and I don't recall choosing a particular platform
> > flavor of the AXIS2 distribution?
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
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
Posted by "Yadav, Yogendra (IT)" <Yo...@morganstanley.com>.
The databinding support is true for the client side as well. In case you
are using java for the client side then use one of the supported
databindings and you won't deal with AXIOM.
-----Original Message-----
From: Yadav, Yogendra (IT)
Sent: Tuesday, January 09, 2007 7:05 PM
To: axis-user@ws.apache.org
Subject: RE: consequences of choosing axis
Clients don't have to use AXIOM. Clients could construct a WS-I
compliant SOAP message whichever way they can, .Net, C++ or Perl clients
would do this.
Since JAXB and other databindings are supported, server side need not
use AXIOM either. Only if you choose no-databinding, you would be
dealing with AXIOM on the server side.
HTH
-yogen
-----Original Message-----
From: Anne Thomas Manes [mailto:atmanes@gmail.com]
Sent: Tuesday, January 09, 2007 6:58 PM
To: axis-user@ws.apache.org
Subject: Re: consequences of choosing axis
Sorry for being vague. I was referring to the SOAP platform, not the
underlying servlet/J2EE platform. As I said, Axis2 can be deployed on
any platform. But AXIOM is particular to Axis2. (It is a separate
project, and other SOAP platforms could use it, but to date, the only
other project that I know of that uses AXIOM is Synapse.)
The impact of using a platform-specific object model is that your
client/service code is not portable across other SOAP platforms.
Anne
On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> Anne,
>
> >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.
>
> This may be a dumb question, but what do you mean by platform specific
> object model? How is AXIOM platform specific? I'm thinking that its
> all Java so . . . and I don't recall choosing a particular platform
> flavor of the AXIS2 distribution?
>
> ---------------------------------------------------------------------
> 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
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this email
is prohibited when received in error.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
---------------------------------------------------------------------
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
Posted by "Yadav, Yogendra (IT)" <Yo...@morganstanley.com>.
Clients don't have to use AXIOM. Clients could construct a WS-I
compliant SOAP message whichever way they can, .Net, C++ or Perl clients
would do this.
Since JAXB and other databindings are supported, server side need not
use AXIOM either. Only if you choose no-databinding, you would be
dealing with AXIOM on the server side.
HTH
-yogen
-----Original Message-----
From: Anne Thomas Manes [mailto:atmanes@gmail.com]
Sent: Tuesday, January 09, 2007 6:58 PM
To: axis-user@ws.apache.org
Subject: Re: consequences of choosing axis
Sorry for being vague. I was referring to the SOAP platform, not the
underlying servlet/J2EE platform. As I said, Axis2 can be deployed on
any platform. But AXIOM is particular to Axis2. (It is a separate
project, and other SOAP platforms could use it, but to date, the only
other project that I know of that uses AXIOM is Synapse.)
The impact of using a platform-specific object model is that your
client/service code is not portable across other SOAP platforms.
Anne
On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> Anne,
>
> >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.
>
> This may be a dumb question, but what do you mean by platform specific
> object model? How is AXIOM platform specific? I'm thinking that its
> all Java so . . . and I don't recall choosing a particular platform
> flavor of the AXIS2 distribution?
>
> ---------------------------------------------------------------------
> 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
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
---------------------------------------------------------------------
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
Posted by Anne Thomas Manes <at...@gmail.com>.
Sorry for being vague. I was referring to the SOAP platform, not the
underlying servlet/J2EE platform. As I said, Axis2 can be deployed on
any platform. But AXIOM is particular to Axis2. (It is a separate
project, and other SOAP platforms could use it, but to date, the only
other project that I know of that uses AXIOM is Synapse.)
The impact of using a platform-specific object model is that your
client/service code is not portable across other SOAP platforms.
Anne
On 1/9/07, ChadDavis <ch...@gmail.com> wrote:
> Anne,
>
> >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.
>
> This may be a dumb question, but what do you mean by platform specific
> object model? How is AXIOM platform specific? I'm thinking that its
> all Java so . . . and I don't recall choosing a particular platform
> flavor of the AXIS2 distribution?
>
> ---------------------------------------------------------------------
> 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
Posted by ChadDavis <ch...@gmail.com>.
Anne,
>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.
This may be a dumb question, but what do you mean by platform specific
object model? How is AXIOM platform specific? I'm thinking that its
all Java so . . . and I don't recall choosing a particular platform
flavor of the AXIS2 distribution?
---------------------------------------------------------------------
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
Posted by Anne Thomas Manes <at...@gmail.com>.
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
Re: consequences of choosing axis
Posted by Thilina Gunarathne <cs...@gmail.com>.
Hi Chad,
I might not be the best person to answer this, but here's how I see it..
>if a web service publishses a WSDL, then the client could be built on
any web service >technology that works with WSDL -- correct?
Yes..Exactly.. That's how it works most of the times..
But to be honest, there can be exceptions arising due to
interoperability concerns with the service impl engine & your
ws-client...
Anyway most of the popular ws engines works well with each other for
most of the common cases. (ex; axis2 <--> WCF has very good proven
interoperability records)
> 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?
Yes.. But I would say 99% :)..
Thanks,
Thilina
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
--
Thilina Gunarathne
WSO2, Inc.; http://www.wso2.com/
Home page: http://webservices.apache.org/~thilina/
Blog: http://thilinag.blogspot.com/
---------------------------------------------------------------------
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
Posted by Martin Gainty <mg...@hotmail.com>.
Good Evening Chad
No consequences as long as you're willing to put in the effort to determine which version you're going to use, build the examples/samples and modify the sample to suit the features you desire
The service and the client will have to agree on style (RPC or doc/literal), namespace declarations, Datatypes and schema provided
Anyone else?
Martin --
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited.
---------------------------------------------------------------------------
Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire.
----- Original Message -----
From: "ChadDavis" <ch...@gmail.com>
To: "axisUsers" <ax...@ws.apache.org>
Sent: Saturday, January 06, 2007 6:46 PM
Subject: consequences of choosing axis
> 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. 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?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>