Essentially web-services are Java classes, so I think there is no harm in having a constructor in web-service. As far as having parameterized constructors are concerned, you can have that too but you need to have default constructors too.
The very need of default constructor is: the application server on which web service is hosted, creates the instances of the the web service class internally and absent of default constructor will cause an exception (a runtime exception in my opinion).
From design point of view, web services should not contain any methods that are not going to be exposed to the client unless they are private members.
First of all thanks for reply.
I suppose, as you said, that as a web-services is implemented in java, I can have a constructor.
But for example. I have a web-service provider and a consumer developed in java. And the consumer have a constructor with parameters and a default constructor. When the consumer want to send a request of a service, first of all have to send a request of the constructor and then the request of a service? The information send it in the first request of the constructor is save for the next request?. How knows the provider that this information is for the consumer number one and not for the consumer number 2?
You understand what I'm explaining you? You understand what is my problem?
As far as I know, web services are not like the objects you have in java/c++. Web services are actually functions/methods that you expose over web. They are not mean to be used the way you are talking.
Why don't you send all the values in one call to web services. AFAIK, web services don't maintain the conversation state (they are designed that way), and it is always a good practice to reduce number of remote calls otherwise you'll overload the network bandwidth.
Thanks for your reply. What you told me is exactly the same as I think. But the company that cooperates with us said the things that I explain you and I wanted to know who are right.