MessageHandlers - caching of SOAP responses

Question

I have a webservice which has a number of clients who will all consume the same
message once. I've determined that one of my bottlenecks is actually turning
the results of the EJB call into the SOAP message. Since all the clients will
receive the same message once I think it would be nice to cache the soap message
resulting from a call.
Can I use a message handler to do this, or will the SOAP message already have
been generated?

Answer 1

Hi Tom,
Your previous reply clears things up :-) But for the record, serialization (converting
the value returned from the EJB to XML) has already occurred when the handleResponse(MessageContext)
method is called. That's why you can get access to (and manipulate) the SOAP response
in the handleResponse(MessageContext) method. This SOAP response has the value
returned from the EJB in it, when the handleResponse(MessageContext) method is
called.
Later,
Mike Wooten
"Tom Hennen" <[email protected]> wrote:
>
I need to call the EJB because what it returns will determine if the
message is
already cached. You see the ejb returns a message from a queue. That
message
needs to be removed from the queue, and the handler won't know if it
has the message
cached until it gets a response from the EJB.
At any rate it sounds like you're saying the serialization takes place
after handlerResponse
gets through with the Message? If that's the case then this won't work
anyways.
"Michael Wooten" <[email protected]> wrote:
Hi Tom,
You'd have to store something in the MessageContext DURING the handleRequest(MessageContext)
method processing, to make any sense here :-)
The JAX-RPC Handler infrastructure is only guaranteeing that the property
stored
during the handleRequest(MessageContext) call, will be available during
the handleResponse(MessageContext)
call.
I don't quite understand why you need to call the EJB, if you already
know what
the value of the return object will be. I'm assuming that the EJB will
return
the same result, for a given value assigned to the input arguments.If
this is
true, why can't you use a byte[] created from the payload of the <SOAPBody>
request,
as the cache item key. If you don't find the cache item key (you look
in the
handleRequest method), set a MessageContext property with the payload
byte[],
and call the EJB. When the EJB returns, retrieve the property and use
it to create
a cache item that has the value of the property as the key, and a byte[]
of the
SOAP response as a value. When the handleResponse method is called,it
will contain
the response that will become the cache item value. Create a byte[]from
it, assign
the value of the property as the key, and a byte[] of the SOAP response
as the
value. If you find the key in the cache during the handleRequest(MessageContext)
call, retreive the cache value, put it in a MessageContext property,
return false
from handleRequest(MessageContext), grab the MessageContext property
value in
the handleResponse(MessageContext) method, and create the SOAP response
with it.
I take it that this isn't something you can do in your situation :-)
Calling the EJB from inside the handleRequest(MessageContext) method
will still
have performance issues, because you'll still need to deal with serializing/deserializing
XML.
Regards,
Mike Wooten
"Tom Hennen" <[email protected]> wrote:
Hmm, that's what I was afraid of.
We actually have to call the EJB. Skipping it isn't an option.
The
ejb only
accesses data in memory, so caching it's response would be of little
value anyways.
When using RMI to bypass the jax-rpc stack I'm seeing CPU usage about
1/3 less
than when using webservices. Overall throughput also more than doubles.
Would I see a benefit to calling the EJB from the handleRequest method
and then
based upon it's response sticking a cached SOAP message into the message
context?
Of course this would bring up the problem of what to do if the message
hasn't
been cached (calling the EJB twice isn't allowed).
"Michael Wooten" <[email protected]> wrote:
Hi Tom,
The SOAP message will have already been created for both client andserver-side
JAX-RPC Handlers, but you can avoid the EJB call :-)
The flow is as follows:
1. Web service consumer code calls web service operation.
2. The client-side JAX-RPC stack creates a SOAP message from the call.
If a
client-side JAX-RPC Handler is in place for the called operation,
it's
handleRequest
callback method is invoked.
3. If handleRequest returns a true, or there is no client-side JAX-RPC
Handler
in place, the
JAX-RPC implementation connects to the endpoint URL and sends the
SOAP
message.
4. The server-side JAX-RPC stack invokes the handleRequest method,of
a server-side
JAX-RPC Handler for the operation, if one is defined. It (the server-side
JAX-RPC
stack) hasn't made the call to the EJB that is providing the service
implementation
yet.
NOTE: Seeing as the EJB hasn't been called yet, you could have thecode
in the
handleRequest method return a cached response. The assumption here,would
be that
this server-side JAX-RPC Handler had access to a shared database (or
a JCache-based
product), that it could query in the handleRequest method, and update
in the handleResponse
method. If the query returned a cached SOAP response, you would useit
to set
a property on the MessageContext object passed to handleRequest, using
the setProperty
method, and return false from handleRequest. The stack should then
bypass
invoking
the EJB and call the handleResponse, using the same MessageContextobject
you
set the property on in the handleRequest method. Call the getProperty
on the MessageContext
object in the handleResponse method, to get the cached SOAP response,
and use
it to replace the one currently in the SOAP response. If performance
is a major
factor (which sounds like the case), you might want to replace theshared
database
with an distributed cache product (i.e. Tangosol Coherence, an open-source
JCache
product, etc.), or an XML database :-)
5. If the handleRequest method of the server-side JAX-RPC Handler
returns
true,
or no server-side JAX-RPC Handler was defined for the operation, the
server-side
stack calls the EJB.
6. If a server-side JAX-RPC Handler is defined, the server-side stack
calls the
handleResponse method. If not, the stack uses the results of the EJB
call to create
the SOAP response.
7. If a client-side JAX-RPC Handler is defined, the client-side stack
calls the
handleResponse method. Afterwards, it processes the SOAP responseand
deserializes
the return value. If no client-side JAX-RPC Handler is defined, theclient-side
stack just processes the SOAP response and deserializes the return
value.
HTH,
Mike Wooten
"Tom Hennen" <[email protected]> wrote:
I have a webservice which has a number of clients who will all consume
the same
message once. I've determined that one of my bottlenecks is actually
turning
the results of the EJB call into the SOAP message. Since all the
clients
will
receive the same message once I think it would be nice to cache thesoap
message
resulting from a call.
Can I use a message handler to do this, or will the SOAP message
already
have
been generated?