-4

I have a web service (Java/WebSphere 8.0) that is receiving duplicated SOAP messages and I am exploring various ways to handle these duplicated messages from the web service point of view.

I am at a point where I can detect when we are processing a duplicate, but I wanted to explore the possibility of just not responding to the message at all and closing the HTTP connection.

Is it possible to have the web service just not respond and close the connection when a duplicate is detected? Or is that not possible in the context of the web service application?

boskoop
  • 1,157
  • 1
  • 10
  • 17
Cypher
  • 2,608
  • 5
  • 27
  • 41
  • If you see two requests, it's because the client or intermediary has retried. Someone is generally not waiting for the original response. Are the body sizes small on these posts? Do you use theWAS WebServer Plugin? You should make sure to set the PostBufferSize to 0. – covener Feb 17 '17 at 19:03
  • @covener That's what I was assuming was happening. However, inspecting the client communication with a packet capture tool only shows one HTTP POST going out... I can try looking at that again, maybe at the TCP level. It's hard to see this stuff in production because it's all over SSL and we haven't been able to recreate this in development where we allow plain HTTP. The body sizes are quite large, actually. They contain a lot of text fields, a repeating node that can contain multiple images. Average size of the HTTP payload is about 20k. – Cypher Feb 17 '17 at 19:11
  • @covener Yes, we use the web server plugin. I probably should have mentioned that in the post. WAS is fronted by IIS using the mentioned plugin. – Cypher Feb 17 '17 at 19:11

1 Answers1

2

I don't think this kind of behavior is really supported since it (in my opinion) violates the SOAP protocol. The standard way to handle this would be sending a SOAP fault for your use case.

If a SOAP fault is really no option you could maybe try to trick the application server with an invalid SOAP response.

== Here be dragons! ==

You could e.g. try to add a SOAPHandler (for brevity i assume you know this concept and how to implement it) which constructs an invalid SOAP response:

public class DuplicateDetectingSOAPHandler implements SOAPHandler<SOAPMessageContext> {

    @Override
    public boolean handleMessage(SOAPMessageContext context) {
        if (isDuplicate(context)) {
            MessageFactory messageFactory;
                try {
                    messageFactory = MessageFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL);
                    SOAPMessage message = messageFactory.createMessage();
                    // detaching the SOAPBody violates api and causes an error
                    message.getSOAPBody().detachNode();
                    context.setMessage(message);
                } catch (SOAPException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            return false;
        }
        return true;
    }

    private boolean isDuplicate(SOAPMessageContext context) {
        // determine if message is duplicate
    }

I tried this with the standard JDK webservice implementation and it caused your desired behavior. I don't know if this works on WebSphere too. Keep in mind that this triggers some kind of error in the webservice implementation itself and could lead to other side-effects.

To be clear: I don't think you should implement this kind of behavior at all and search for a different solution.

Maybe an empty SOAP response also serves your need:

SOAPMessage message = messageFactory.createMessage();
context.setMessage(message);

This results in an empty SOAP reponse:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
   <env:Header/>
   <env:Body/>
</env:Envelope>
boskoop
  • 1,157
  • 1
  • 10
  • 17
  • @Cypher does this answer help your case? – boskoop Feb 25 '17 at 14:07
  • Thanks for this. It's both terrible and clever at the same time. :) I discovered the source of the duplicate messages and I don't think I'll have to use this, but was still curious of this was technically possible. I appreciate the effort you put into this answer. – Cypher Feb 27 '17 at 18:30
  • Ha! Very happy you found the real issue and did not have to use this (I totally agree) terrible solution. It's always good when you find the root cause instead of being forced to use some fiddly hack (poor soul who would've had to maintain this). See you around! – boskoop Feb 28 '17 at 19:18