Re: consequences of choosing axis
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: Chad, On 1/6/07, ChadDavis [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: consequences of choosing axis
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 [EMAIL PROTECTED] wrote: Chad, On 1/6/07, ChadDavis [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
Re: consequences of choosing axis
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: Chad, On 1/6/07, ChadDavis [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service
RE: consequences of choosing axis
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
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) [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
RE: consequences of choosing axis
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:[EMAIL PROTECTED] 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) [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
Re: consequences of choosing axis
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
Re: consequences of choosing axis
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]
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]
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:[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]
RE: consequences of choosing axis
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:[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] 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]
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]
Re: consequences of choosing axis
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: consequences of choosing axis
Yes -- non-standard. On 1/9/07, ChadDavis [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: consequences of choosing axis
Anne, FYI, Spring-WS supports AXIOM too. thanks, -- dims On 1/9/07, Anne Thomas Manes [EMAIL PROTECTED] 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 [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] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: consequences of choosing axis
Chad, On 1/6/07, ChadDavis [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: consequences of choosing axis
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 [EMAIL PROTECTED] To: axisUsers axis-user@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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: consequences of choosing axis
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thilina Gunarathne WSO2, Inc.; http://www.wso2.com/ Home page: http://webservices.apache.org/~thilina/ Blog: http://thilinag.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]