Besides the performance overhead of converting the XML to a byte array and back, another big minus is the WSDL in this case has lost all the schema definition. In other words, the client and the server has to use another channel to communicate what does the detail of the request and response look like.

Rgds, Ricky

At 11:39 AM 10/29/2002 -0500, James Black wrote:
Barry Lulas wrote:

> What does your web service interface look like?  I like the idea of
> having multiple options....

  I have an input bean where the options are set regarding the graph
type that is desired (setting what is on the x, y, z axes and how to
group the data).  There is also a byte parameter that is used to
determine how to return the result.
  I figure a byte is enough, as I will never have more than that as
types to return.

- <wsdl:message name="getGraphRequest">
  <wsdl:part name="input" type="tns1:EpicVisitor" />
  <wsdl:part name="retmode" type="xsd:byte" />
  </wsdl:message>
- <wsdl:message name="getGraphResponse">
  <wsdl:part name="getGraphReturn" type="soapenc:base64" />
  </wsdl:message>
- <wsdl:portType name="GraphingTools">
- <wsdl:operation name="getGraph" parameterOrder="input retmode">
  <wsdl:input name="getGraphRequest" message="intf:getGraphRequest" />
  <wsdl:output name="getGraphResponse" message="intf:getGraphResponse"
/>
  </wsdl:operation>
  </wsdl:portType>
- <wsdl:binding name="GraphingToolsSoapBinding"
type="intf:GraphingTools">
  <wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"; />
- <wsdl:operation name="getGraph">
  <wsdlsoap:operation soapAction="" />
- <wsdl:input name="getGraphRequest">
  <wsdlsoap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
namespace="urn:GraphingTools" />
  </wsdl:input>
- <wsdl:output name="getGraphResponse">
  <wsdlsoap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
namespace="urn:GraphingTools" />
  </wsdl:output>
  </wsdl:operation>
  </wsdl:binding>



Reply via email to