Multiple agruments on interface limitation

[aaroncirillo]

I am attempting to write a SOAP service that is going to consume a message from a third party which is Salesforce. I do not have control over the format of this message, since I am not generating it. Salesforce gives me a WSDL that describes the message they are going to send. I am generating code from the WSDL and then attempting to implement the interface that was defined during the generation of the code. This is the interface for the inbound message:

public interface NotificationPort {

    /**

     * Process a number of notifications.

     */

    public boolean notifications(java.lang.String organizationId,

       java.lang.String actionId,

       java.lang.String sessionId,

       java.lang.String enterpriseUrl,

       java.lang.String partnerUrl,

       java.util.List<my.companies.data.type> notification);

}

I am not sure of the approach to take here since I am currently limited to have only 1 argument on an interface in switchyard. Every suggestion I have seen around this is to wrap your message in a single object. That makes sense if you have control over the inbound message, but I do not. Can anyone point me in the right direction on this?

[jdmarti1_rc]

Found this and trying this approach:

Due to switchyard service limitations, interface methods can only

     * have one input type. So had to create a 'composite' type

     * See https://access.redhat.com/solutions/874003

public class CompositeInterfaceParam {

    public CompositeInterfaceParam(TrainingSet trainingSet,

     PowerStatesEnum aPowerStatesEnum) {

  aTrainingSet = trainingSet;

  aPowerState = aPowerStatesEnum;

    }

    /*

     * Due to switchyard service limitations, interface methods can only

     * have one input type. So had to create a 'composite' type

     * See https://access.redhat.com/solutions/874003

     *

     * TODO:

     * Will have vet this out... right now think I'll just populate with all types of

     * parameters instead of making completely generic with an array of Object...

     *

     * Code review: please look at this and see if another/better way

     */

    public TrainingSet aTrainingSet;

    public PowerStatesEnum aPowerState;

}

The interface

public interface IVMManagerService {

    /*

     * Due to switchyard service limitations, interface methods can only have

     * one input type. So had to create a 'composite' type See

     * https://access.redhat.com/solutions/874003

     *

     * Also even though setupWebserviceConnection does not need a param, the

     * interface spec forces us to have at least one

     */

    public boolean setupWebserviceConnection(boolean startup);

    public boolean powerupVM(CompositeInterfaceParam aCompositeInterfaceParam)

     throws Exception;

}