create a soap response serialized to a byte array

[devnu1l <de...@yahoo.co.uk>]

Is it possible, and if so can anyone point me in the right direction, for
creating a soap response serialized into a byte array.  By this i mean using
the soap stack to create a response message that conforms to a wsdl but not
in response to a SOAP request.

We have an application where the response changes relatively infrequently
w.r.t the number of requests. At the moment we serialize the response to
SOAP for each request even though it is probably identical to the previous
request.  SOAP serialization is accounting for approx 30% of the load on our
servers.  Instead I would like to serve a pre serialized message.  When the
data does change I would then create a new response, and when it is ready,
begin serving that.

Any ideas would be greatly appreciated.
-- 
View this message in context: http://www.nabble.com/create-a-soap-response-serialized-to-a-byte-array-tp17236179p17236179.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: create a soap response serialized to a byte array

[Daniel Kulp <dk...@apache.org>]

Interesting use case.......   Definitely doable with a few interceptors.

First problem is determining when you can return a pre-canned  
response.   This completely depends on your logic.   You could  
possibly look at the byte[] of the request, you could use the  
SAAJInInterceptor to get an SAAJ model and use the SAAJ or DOM apis,  
you could run in the USER_LOGICAL phase where you would have the JAXB  
beans to look at.   Without knowing the complexity of your data, I  
don't really know what is best for this part.     This would be an  
Interceptor on the IN chain.   Once you've made this decision, one of  
two things will happen:

1) You don't want a canned response return: in this case, you need to  
record the response that is being generated so you can return it  
later.   Use our LoggingOutInterceptor as a starting point for  
this.     This would obviously be on the OutChain (and likely OutFault  
as well).

2) If your IN interceptor wants to return the byte[] is know about,  
the easiest thing would be for it to handle the entire thing itself.    
Basically, it would do something like:

Exchange ex = message.getExchange()
EndpointReferenceType target =  ex.get(EndpointReferenceType.class);
Conduit conduit =  
ex.getDestination().getBackChannel(ex.getInMessage(), null, target);
Message outMessage = new MessageImpl();
conduit.prepare(outMessage);
//probably set headers here
outMessage.getContent(OutputStream.class).write(bytes);
outMessage.getContent(OutputStream.class).flush();
conduit.close(outMessage);
message.getInterceptorChain().abort();  //stops the current chain

The nice thing about this is the outgoing chain NEVER gets called for  
the canned responses.   Thus, the LoggingOutInterceptor thing on the  
out chain that records the responses would never be re-triggered.    
It's only triggered when it really needs to record things.



Dan



On May 14, 2008, at 1:05 PM, devnu1l wrote:

>
> Is it possible, and if so can anyone point me in the right  
> direction, for
> creating a soap response serialized into a byte array.  By this i  
> mean using
> the soap stack to create a response message that conforms to a wsdl  
> but not
> in response to a SOAP request.
>
> We have an application where the response changes relatively  
> infrequently
> w.r.t the number of requests. At the moment we serialize the  
> response to
> SOAP for each request even though it is probably identical to the  
> previous
> request.  SOAP serialization is accounting for approx 30% of the  
> load on our
> servers.  Instead I would like to serve a pre serialized message.   
> When the
> data does change I would then create a new response, and when it is  
> ready,
> begin serving that.
>
>
> Any ideas would be greatly appreciated.
> -- 
> View this message in context: http://www.nabble.com/create-a-soap-response-serialized-to-a-byte-array-tp17236179p17236179.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>

---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog