How requests are handled in webservices ?
avneesh atri
Greenhorn
Posts: 20
posted 4 years ago
Hi,
i am new to web services so i am having trouble in understanding its object creation and life cycle. So far what i have understood is that , web service provides a mechanism for calling remote methods by sending http request using soap protocol. But what i dont understand is when the request is sent to a webservice , does a single object of the service is created and same object is used in multiple threads to handle multiple request like servlets ?or multiple stateless objects are created which works like a ejb stateless session bean ,in which multiple objects are created in a pool and the same client can have a different object processing its second request.
As we can create a webservice using a statless session bean , i used to think that this is how its done . But then i created a webservices(with simple pojo ,not an ejb ) and put instance variables in it and created getter and setter method for it. I created two clients A and B , the i called the methods in following sequence.
A setter method- sets a value eg A1
B setter method - sets a value eg B1
A getter method - returns B1
This behaves just like a servlet .
Please can anyone explain this properly .
thanks
i am new to web services so i am having trouble in understanding its object creation and life cycle. So far what i have understood is that , web service provides a mechanism for calling remote methods by sending http request using soap protocol. But what i dont understand is when the request is sent to a webservice , does a single object of the service is created and same object is used in multiple threads to handle multiple request like servlets ?or multiple stateless objects are created which works like a ejb stateless session bean ,in which multiple objects are created in a pool and the same client can have a different object processing its second request.
As we can create a webservice using a statless session bean , i used to think that this is how its done . But then i created a webservices(with simple pojo ,not an ejb ) and put instance variables in it and created getter and setter method for it. I created two clients A and B , the i called the methods in following sequence.
A setter method- sets a value eg A1
B setter method - sets a value eg B1
A getter method - returns B1
This behaves just like a servlet .
Please can anyone explain this properly .
thanks
Ulf Dittmer
Rancher
Posts: 42970
73
posted 4 years ago
Note that WS does not have to mean SOAP - these days RESTful services (in the Java world defined via the JAX-RS API) are much more common for new projects.
Whether the object that handles a WS request is created once for each request, or if it's shared between multiple threads (like a servlet) is an implementation detail that could differ from implementation to implementation. Check the documentation of whatever API or implementation you're using whether it says anything about that.
Offhand I'd say that it's more common that the request handling objects are not shared between threads (in other words, a new one is created for each request), but it doesn't have to be that way; it would seem that you stumbled upon a counter-example.
Whether the object that handles a WS request is created once for each request, or if it's shared between multiple threads (like a servlet) is an implementation detail that could differ from implementation to implementation. Check the documentation of whatever API or implementation you're using whether it says anything about that.
Offhand I'd say that it's more common that the request handling objects are not shared between threads (in other words, a new one is created for each request), but it doesn't have to be that way; it would seem that you stumbled upon a counter-example.
avneesh atri
Greenhorn
Posts: 20
posted 4 years ago
So different api's have different implementations , but i thought that jax-ws is the only api present to implement WS. What other apis are there apart from it ?
Ulf Dittmer wrote:Note that WS does not have to mean SOAP - these days RESTful services (in the Java world defined via the JAX-RS API) are much more common for new projects.
Whether the object that handles a WS request is created once for each request, or if it's shared between multiple threads (like a servlet) is an implementation detail that could differ from implementation to implementation. Check the documentation of whatever API or implementation you're using whether it says anything about that.
Offhand I'd say that it's more common that the request handling objects are not shared between threads (in other words, a new one is created for each request), but it doesn't have to be that way; it would seem that you stumbled upon a counter-example.
So different api's have different implementations , but i thought that jax-ws is the only api present to implement WS. What other apis are there apart from it ?
Ulf Dittmer
Rancher
Posts: 42970
73
posted 4 years ago
JAX-WS is the standard Java API for SOAP-based WS. As I mentioned, there are other forms of WS - chiefly REST-based WS, as defined by the JAX-RS API. Furthermore, it's of course possible to implement WS without using either JAX-WS or JAX-RS.
As I also mentioned, thread safety is an implementation detail - it may depend not on the API you use but on the implementation of the API. In the case of JAX-WS it could be Metro, JBossWS, Axis-2 or one of various alternative implementations.
As I also mentioned, thread safety is an implementation detail - it may depend not on the API you use but on the implementation of the API. In the case of JAX-WS it could be Metro, JBossWS, Axis-2 or one of various alternative implementations.
Hikari Shidou
Ranch Hand
Posts: 88
posted 4 years ago
I've been using Axis2, had some trouble in begining but now I'm liking it.
As I understand about WebService, we're doing a remote call to an object's operations. So I understand that object is created by Tomcat and shared among all requests, unless I demand it otherwise (I'd create different WebServices/WS operations to handle remote calls to different objects).
Let's consider your example. We have an object with a get and a set. Client A makes a remote call to its set method, and sets a value on it. Then, client B remotely calls its get method. I myself at least would expect to receive the value setted by A, and not default value created during object construction. This is a simple example of 2 softwares using a WebService to talk each other.
When we use Axis2, we can create a WS server from an existing class. And, as I understand it, that WS instantiates the object that will be called.
Axis2 doesn't provide many options regarding which methods in the class will become operations in the WebService, or how to name these operations.
For example, in a test I was doing, a method receives an AuthenticationInfo bean as parameter. That class was therefore added to WSDL. But for testing it had a getPasswordTruncated() method, that returns the upperlettered first letter of password. Axis2 thought it was a property and turned it into a type's field, which could be setted and getted separated from getPassword(), lol.
Because of that, when creating a WS, I feel it safer to create a package and in it create a class and new beans, with sole purpose of being used as "shells" between WS creating and real classes on the app. I fear creating a WS and in the future adding new methods to classes that are indirectly used by the WS, and therefore upon recreating the WS add information/services to it that shouldn't be available to outsiders.
If I need to handle multithread writes, I'd do that in this class used to create the WS. After that, it depends on your app's architeture. If it's not thread safe, think about creating a whole environment for each WS client... but, while in Servlet you have this handled for you, here u'll have to manually handle it. Objects usually don't eat too much RAM, so depending on the size of your app it's safer to have a set of objects (app environment) for each user than worrying everywhere with threads.
As I understand about WebService, we're doing a remote call to an object's operations. So I understand that object is created by Tomcat and shared among all requests, unless I demand it otherwise (I'd create different WebServices/WS operations to handle remote calls to different objects).
Let's consider your example. We have an object with a get and a set. Client A makes a remote call to its set method, and sets a value on it. Then, client B remotely calls its get method. I myself at least would expect to receive the value setted by A, and not default value created during object construction. This is a simple example of 2 softwares using a WebService to talk each other.
When we use Axis2, we can create a WS server from an existing class. And, as I understand it, that WS instantiates the object that will be called.
Axis2 doesn't provide many options regarding which methods in the class will become operations in the WebService, or how to name these operations.
For example, in a test I was doing, a method receives an AuthenticationInfo bean as parameter. That class was therefore added to WSDL. But for testing it had a getPasswordTruncated() method, that returns the upperlettered first letter of password. Axis2 thought it was a property and turned it into a type's field, which could be setted and getted separated from getPassword(), lol.
Because of that, when creating a WS, I feel it safer to create a package and in it create a class and new beans, with sole purpose of being used as "shells" between WS creating and real classes on the app. I fear creating a WS and in the future adding new methods to classes that are indirectly used by the WS, and therefore upon recreating the WS add information/services to it that shouldn't be available to outsiders.
If I need to handle multithread writes, I'd do that in this class used to create the WS. After that, it depends on your app's architeture. If it's not thread safe, think about creating a whole environment for each WS client... but, while in Servlet you have this handled for you, here u'll have to manually handle it. Objects usually don't eat too much RAM, so depending on the size of your app it's safer to have a set of objects (app environment) for each user than worrying everywhere with threads.
