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 <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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) <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -------------------------------------------------------- > > > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -------------------------------------------------------- > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
