I am going to use Web Services in my project. We are going to develop the project using Spring and hibernate as persistence layer. My question is either i go with the Springs own Web Services or others like XFire, Axis2. I have read many articles and everything ends up with their choice. I need more performance as the number of users will be high. Currently i am in dilemma for choosing between web services, because once i chose it, it'll be fixed. So please help me with that
Never try to be a hard-worker. Be a smart-worker.
My Blog
Ulf Dittmer
Marshal
Joined: Mar 22, 2005
Posts: 32768
posted
0
Currently i am in dilemma for choosing between web services, because once i chose it, it'll be fixed.
You should be able to avoid lock-in by sticking to standard APIs like JAX-RS, SAAJ and JAX-WS. Those are supported by various implementations and you should be able to swap implementations without too much effort if need be.
I need more performance as the number of users will be high.
If you keep your code generic enough that you can swap implementations, then you can perform load testing against different server WS stacks and see if they satisfy the performance requirements.
Ulf Dittmer wrote:
You should be able to avoid lock-in by sticking to standard APIs like JAX-RS, SAAJ and JAX-WS. Those are supported by various implementations and you should be able to swap implementations without too much effort if need be.
I didn't get your point Ulf. What do you mean by lock-in???
Ulf Dittmer wrote:
If you keep your code generic enough that you can swap implementations, then you can perform load testing against different server WS stacks and see if they satisfy the performance requirements.
Ofcourse, i do load test it, but i need to make the decision now. No looking back.
Ulf Dittmer
Marshal
Joined: Mar 22, 2005
Posts: 32768
posted
0
Lock-in is the situation you described: you pick one product or technology and can't change to something else later: vendor lock-in Using standards (like JAX-WS and JAX-RS) helps to avoid this because the cost of switching is comparatively low.
David Newton
Author
Rancher
Joined: Sep 29, 2008
Posts: 12612
posted
0
Perhaps you could read those articles and form your *own* opinion, rather than relying on somebody else to tell you what to think.
If your application has properly separated its concerns, the worst possible scenario is that you have to change the way your functionality is exposed as a web service. Tedious, but hardly a major issue in the grand scheme of things.
After digging out regarding this i find Axis 2 bit more interested than SWS. But a simple question is , i need a XML parser to form XML(to send to the API as input) and parse the resultant XML(get from API). So which one you would suggest
Ulf Dittmer
Marshal
Joined: Mar 22, 2005
Posts: 32768
posted
0
The general approach would not be to generate the XML/SOAP yourself, but to use the SOAP stack's tools (called "wsdl2java" in Axis' case) to generate Java code to access the web service. Creating SOAP manually is tedious and error-prone to develop, and hard to maintain. It also becomes downright prohibitively complex if you want to use further Axis capabilities like WS-Security.
^^ So its better to stick with axis and a XML Parser. Right?
Ulf Dittmer
Marshal
Joined: Mar 22, 2005
Posts: 32768
posted
0
What do you mean by "stick" with Axis? Are you considering developing a SOAP service without using a SOAP stack? If so, please give up on that right now.
I think you missed the point of my previous post - you should not be using a parser to handle the SOAP, but instead use the Java code generated by the tools that are part of whichever SOAP stack you end up using.
^^
Its a REST based service. XML is used for server/client communication.
Ulf Dittmer
Marshal
Joined: Mar 22, 2005
Posts: 32768
posted
0
Its a REST based service.
That's the kind of crucial information that you should have mentioned in your first post. Be sure to check out the JAX-RS API for the server-side implementation, and the various JAX-RS implementations (like Jersey) for what they offer to develop the client side.