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.