Here is a quote from this months Java Live chat.
"Roberto Chinnici: In the 0.8 specification an endpoint implementation
class is initialized with an object on which it can call back to obtain
the SOAPMessageContext for the request, so it could use that to access
the attachments. Another strategy would be to use message handlers to
deal with attachments and put the data where the endpoint implementation
class can find it -- this would work in EA2 too, incidentally. "
Well I have a problem with this answer and I have a feeling that
this interface might be broken...
Here is an excerpt from the specs :
"....After the service endpoint object is instantiated, the JAX-RPC
runtime system is required to initialize the endpoint before any
requests can be serviced. The JAX-RPC runtime system is required to
invoke the ServiceLifecycle.init method ......."
"Once a service endpoint has been initialized, the JAX-RPC runtime
system may dispatch multiple remote method invocations to the service
endpoint object. These method invocations must correspond to the remote
methods in the service endpoint interface implemented by the service
endpoint class."
This leads me to believe that the init() is *not* called for every
request
but only once, when the class is initialized....much like how servlets
are initialized in the servlet specs.
Which is fine... But heres where the problem comes in. Consider the
following code.
public class MyImplementation implements
myremoteInterface,ServiceLifecycle {
private ServletEndpointContext ctx;
public void init(java.lang.Object context){
ctx=(ServletEndpointContext)context;
SOAPMessageContext msgctx= (SOAPMessageContext)
(ctx.getMessageContext());
// =====> SOAPMessage message=msgctx.getMessage();
}
// other code
}
Well if the actual soap message is retrevied via the context ....how can
this work , unless....the init() method is (= MUST be) called for every
incoming request that the implementation is servicing....otherwise
the class will have access to only one message...the first one . And
what happens in the case when the instance is processing multiple
requests, from different clients, with different messages,
simulatneously (as per the requirements)??
And in a related question to the above para, how should developers
assume the threading model of these implementations ?? Like RMI ?
(where the object could be serviceing multiple requests from different
clients simultaenously...and hence isnt thread safe ?)...
I.E like RMI no client specific (in the case of JAX-RPC message
specific) state
should be stored in the instance variables....?? If so then again,
the above code will not work...since the only way to access
the SOAPMessage object in other methods of this class is to put
it in an instance variable.
Please clarify and advice.
/Sam
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at
http://mail.yahoo.com