WS Interface question

[Juan Rolando Prieur-Reza]

Paul,
Can you comment on a question we have about a Web Service interface, please?
Perhaps your chapters 10-15 related to this?
The question began with this:

Originally posted by Pradeep Bhat:
…A service endpoint interface … must not have constant declarations, such as public final static….

Why is this so?
My first answer was like "...interface is stateless, so there would be no assurance that your created objects will be what you expect in subsequent invokations..."
My further explanation of why this would be so is this:
Suppose you create an instance of an object in your WS interface when a request is received.
Example.

CustomerNotes c = new CustomerNotes(); ...
c.setThings(things true during this call);

This object goes away after the call is serviced.
But what if we had:

final static CustomerNotes c = ... 

This object would stay as long as the interface is loaded,
and so a programmer might attempt to store some cumulative counts or sum upon each call.
~~~~~~~~~ But! ~~~~~~~~~
As a Web Services Interface, the interface can
(1) be a different instance for the same WS service, maybe even on a different JVM, made possible by virture of the Service Directory or Lookup Service Pattern or
(2) be unloaded, thus discarding your precious final static object, perhaps indicated in the Data Transfer Object pattern (?).
Thus, the interface must be stateless. It seems that, whether or not my answer is right, this issue would be significant to a WS developer.
That's "my take" and I do not claim to have enough WS expertise to be sure about this answer. Any comments?

[Paul Monday]

Alright, into the bits...
I don't have the context for where this came from...but I think this does come down to pure Java mechanics and trying to reconcile the Java platform with Web Services.
With Axis you could set the longevity of a service implementation (application, request, or session) that fulfills requests. So your comment that the instance goes away after the service request is not necessarily correct.
I think you are taking the approach of building a java interface, then exposing it as a Web Service...correct? If this is the case, remember that Web Services want messages, ports, and operations...a constant is not an operation. I would guess that some tools would take this and turn it into a "get" operation...but, in general, since it doesn't apply to the Web Services platform, why would you want to do it?
As an "umbrella" comment, I would be careful to not try to leverage too many Java semantics in your Web Services. Instead, be careful to take Web Services into account when you design your Java...(reverse your thinking...from a Web Services point of view, is there such a thing as a constant in a WSDL interface...if there isn't, why would you try to do it in the Java interface that is going to be expose...instead, think of the exact behavior you want and build the interface within the limitations of the WS environment).

[Juan Rolando Prieur-Reza]

Thanks, Paul. I agree, it seems that the lost context has caused confusion.
During my development on a Web Service using XML-RPC (actually JAX-RPC client and server) it was
clear that Pradeep's original quote was correct:
"A service endpoint interface must not have constant declarations"
Paul said:
" With Axis you could set the longevity of a service implementation
...your comment that the instance goes away after the service request
is not necessarily correct
But this does not address my point (1). To clarify: you cannot assume that each request will be directed to the same instance of your WS (unless you impose processor affinity (ok for intranets, maybe).
Also, I did not say that the implementation would go away. That is generally a continually running component (the "_IMPL"). I thought I said the interface (aka a service endpoint) is a separate component activated by the Web or Application Server in response to a request. The interface cannot be assumed to stay around or be the same one as in a previous request posted to the "same" WS. This would seem to be true of WS regardless of using java or C++, etc. These behaviors should be characteristic of the Service Activation design pattern that applies here.
My humble suggestion, fellow ranchers: Using XML-RPC and the like requires that you do not use final static objects in the interface. 'cus is says so

[ December 05, 2003: Message edited by: john prieur ]

[Pradeep bhatt]

Is axis proprietary stuff?

[JeanLouis Marechaux]

Originally posted by Pradeep Bhat:
Is axis proprietary stuff?

Some of axis features are JAX-RPC stuffs.
But some others are proprietary

[Pradeep bhatt]

you cannot assume that each request will be directed to the same instance of your WS (unless you impose processor affinity (ok for intranets, maybe).

Does it mean that the server creates an instance of the exposed class or does it pool the instance.