axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Rineholt" <rineh...@us.ibm.com>
Subject Re: Problems with SEOM
Date Wed, 26 Sep 2001 18:09:44 GMT
1. The algorithm that's used today always assumes that the return is listed
as first part in the message.  I thought for sure that I read this
somewhere in WSDL , but could not find this by just skimming through the
WSDL spec.  This this could be incorrect.  For now, I think if you switched
the order of the parts in the message you would get the signature your
looking for.
2. The emitter I wrote never took advantage of the fault information. It
was  added "quickly" before sending out the code since it was obviously
missing.  So it was never exercised too thoroughly.  Probably a bug.
3. I believe this to be doable.

I'd like to point out one other aspect that the code only take into account
SOAP encoded RPC.  I found little information and fewer response to
questions I had regarding if or how to model document and literal in an RPC
type fashion.  So as it stands today the parser just gives a warning that
these are not supported.

>Here are some problems I found with SEOM when I ran my inout test's WSDL
>through it.
>1.  If the first output parameter is really an inout parameter, then SEOM
>splits it into two, returning the output part and making the input part an
>input parameter.  For example:
><message name="Msg1">
><part name="name" type="xsd:string"/>
></message>
><message name="Msg2">
><part name="name" type="xsd:string"/>
><part name="address" type="typens:address"/>
></message>
><operation name="out1_inout1_in0">
><input message="tns:Msg1"/>
><output message="tns:Msg2"/>
><fault name="TestFailed" message="tns:Msg0"/>
></operation>
>This SHOULD produce the signature:
>public Address out1_inout1_in0 (StringHolder name) throws
>java.rmi.RemoteException, TestFailed;
>instead, it produces:
>public String out1_inout1_in0(StringHolder name, AddressHolder address)
>throws java.rmi.RemoteException;
>I don't know what it would take to fix this.
>
>2.  As you can see from the signature above, SEOM hasn't given the emitter
>the TestFailed fault, so the emitter didn't create the TestFailed
exception
>from it.  The code exists to handle faults, so I'm guessing that this is
>just a simple bug to fix.
>
>3.  Since the collection of interfaces is a HashSet, and HashSet has no
>order, the order of method signatures in generated code ends up being
>different than the order of operations in the WSDL.  This isn't a bug
since
>the spec makes no statement about operation order, but it's a real
nuisance
>if you made an attempt to organize the operations in the WSDL doc like I
>did.  Rick, would changing this to a Vector or some other ordered
>collection preserve the WSDL order?
>
>Russell Butek
>butek@us.ibm.com
>>Here are some problems I found with SEOM when I ran my inout test's WSDL
>>through it.
>>1.  If the first output parameter is really an inout parameter, then SEOM
>>splits it into two, returning the output part and making the input part
an
>>input parameter.  For example:
>><message name="Msg1">
>><part name="name" type="xsd:string"/>
>></message>
>><message name="Msg2">
>><part name="name" type="xsd:string"/>
>><part name="address" type="typens:address"/>
>></message>
>><operation name="out1_inout1_in0">
>><input message="tns:Msg1"/>
>><output message="tns:Msg2"/>
>><fault name="TestFailed" message="tns:Msg0"/>
>></operation>
>>This SHOULD produce the signature:
>>public Address out1_inout1_in0 (StringHolder name) throws
>>java.rmi.RemoteException, TestFailed;
>>instead, it produces:
>>public String out1_inout1_in0(StringHolder name, AddressHolder address)
>>throws java.rmi.RemoteException;
>>I don't know what it would take to fix this.
>>
>>2.  As you can see from the signature above, SEOM hasn't given the
emitter
>>the TestFailed fault, so the emitter didn't create the TestFailed
exception
>>from it.  The code exists to handle faults, so I'm guessing that this is
>>just a simple bug to fix.
>>
>>3.  Since the collection of interfaces is a HashSet, and HashSet has no
>>order, the order of method signatures in generated code ends up being
>>different than the order of operations in the WSDL.  This isn't a bug
since
>>the spec makes no statement about operation order, but it's a real
nuisance
>>if you made an attempt to organize the operations in the WSDL doc like I
>>did.  Rick, would changing this to a Vector or some other ordered
>>collection preserve the WSDL order?
>>
>>Russell Butek
>>butek@us.ibm.com


Rick Rineholt
"The truth is out there...  All you need is a better search engine!"

rineholt@us.ibm.com


Mime
View raw message