[MOBY-dev] soap encoding

[Dmitry Repchevsky]

Hello Martin,

>I think (please correct me if I am wrong) that jMoby implements what BioMOBY
>API (specification) asks for. jMoby is tied by this spec. We cannot
>suddenly switch to a different protocol without breaking existing software,
>can we?

Well I am new to jMoby as well as BioMoby, so what is the specification you talk about?
Could you please give me a link?

>Java skeleton does what BioMOBY spec dictates. If you take it, however, and
>try to use it for generating a WSDL, it is you are doing things that the
>skeleton was designed for. The BioMOBY spec has its own API call to get WSDL
>for each service (and which, from various reasons, cannot give you the full
>WSDL, anyway). Please let me know if I am interpreted your comment wrongly,
>or if I am missing something.

Well you got the point. Actually I use the generated skeleton to generate my end point, not the wsdl from BioMoby.
What I'm talking is that the generated skeleton is not strictly compatible with BioMoby wsdl.
The WSDL I'm getting through BioMoby expects that end point accepts xsd:string, but the skeleton accepts an Object.
I am not talking here about the ontology. Actually BioMoby do not use web services architecture (correct me if I'm wrong), but rather 
just sends a plain xml file that you have to parse later to get the parameters.
So the web service is always the same - 1 parameter (xsd:string) in, another out.
Using java.lang.Object in an endpoint is against of WS-I specification.

So by now my request is just to change the endpoint generated by MoSeS to accept the String according both (WS-I and BioMoby).
Such a thing makes both WSDL (from BioMoby and generated from endpoint) 100% equal. 

>There is no problem to change the Object to String
:-)

>But the point is to have a skeleton that deals with Java objects, not with
>MOBY data types. But perhaps give me an example of service you have in mind.

****************************************************************************************************************
abstract public class runEmbossAntigenicFromSequenceSkel
    extends BaseService {

    /**************************************************************************
     * Default constructor.
     *************************************************************************/
    public runEmbossAntigenicFromSequenceSkel() {
	super();
    }

    /**************************************************************************
     * <b>The main method (available as a Web Service). </b> <p>
     *************************************************************************/
    public String runEmbossAntigenicFromSequence (String data) { // Just change Object -> String

	MobyPackage mobyOutput = null;
	try {
	    // reading the whole input
	    MobyPackage mobyInput = MobyPackage.createFromXML (data, "AminoAcidSequence");


****************************************************************************************************************
so in wsdl we will get
****************************************************************************************************************
  <message name="runEmbossAntigenicFromSequenceSEI_runEmbossAntigenicFromSequence">
    <part name="String_1" type="xsd:string"/>
  </message>

****************************************************************************************************************
EXACTLY AS IS FROM WSDL THAT I GET FROM MOBY!!!

>Probably (I guess) that you are barking on the wrong tree because you are
>using the skeleton for generating wsdl.

Well, if they done well they MUST be compatible.
I use netbeans 5.5.1 that allows me to generate all the things from my endpoint and generates WAR file for me, so I do not have to use an ant script.
It takes me 2 seconds to change the service, deploy it to jboss and even debug it on another machine.

Another way could be to generate an endpoint from moby's wsdl, but in this case I have to parse the string (xml) by myself and I still didn't went so deep.

>That's fine with me and I agree with this vision. But it requires to change
>BioMOBY API. Ask for it the community. When we agree on it, I will make
>changes in MoSeS to support it.

Well if we are talking about changing an Object to String - no any another changes needed.

My NEXT point was that (at least in JBoss < 4.04) the generated service supports both encodings "soap encoding" and "rpc-literar".
As you pointed it's up to the community to move forward out the obsolete encoding... ;-)

Regards,

Dmitry