Creating multiple parameterless functions using JAX-WS

I am having trouble creating a Web Service in Java that contains two methods that are parameterless. It's simple to create a single one, but I have not figured out how to get it to work with more than one:

<message name="messageOneRequest" />
<message name="messageOneResponse" />

Would lead to

public void messageOne() { }

But adding

<message name="messageTwoRequest" />
<message name="messageTwoResponse" />

Leads to a "signature" collision. I know the cause of the signature collision, and it's because JAX-WS/JAX-RI are trying to be more efficient with the parameterless method by simply leaving an empty SOAP Body for the incoming message, thus representing a single, parameterless method. As a side note, I am using Document and not RP开发者_如何转开发C.

Is there a way to allow this? Am I simply missing an attribute?

The goal of my question was to achieve parameterless methods like the following:

int someMethod();
ArbitraryObject someOtherMethod();

Even though the two methods do not share the same name, they have a conflicting SOAP body because the incoming SOAP body would be technically identical (most engines seem to supply a blank body for efficiency when there are no arguments, rather than something like <someMethod /> inside of the SOAP body).

To make a long story short, there are two simple ways to fix this problem when using Document/Literal. The simplest way to work around this issue is to simply give them different parameters. I originally just supplied a dummy, no-op parameter (called "IgnoredParameter") to differentiate the two. The other way is to provide a unique value for the SOAP Action of each operation that has non-unique parameters. In the case of using wsimport to generate, you also need to supply "-extension" to have it use that feature, or it will simply error out and ignore the presence of the SOAP action.

The drawback to the second approach is that SOAP Action is highly coupled with HTTP (it's used as an HTTP Header). In my case, that was not a problem. But, obviously that is not always the case especially given that SOAP is meant to be generic.

An example binding with this in use (note the actually supplied soapAction versus being commonly blank):

<operation name="someOtherMethod">
    <wsdlsoap:operation soapAction="urn:someOtherMethod"/>
    <input name="someOtherMethodRequest">
        <wsdlsoap:body use="literal"/>
    </input>
    <output name="someOtherMethodResponse">
        <wsdlsoap:body use="literal"/>
    </output>
</operation>

The other, non-conflicted operations/methods can still use soapAction="".