PEAR::SOAP. Some comments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Some thoughts on PEAR::SOAP

It is still in development and therefore registered as beta. I would very
much like to have a stable 1.0 release but before this can happen, in my
oppinion, to severe bugs and one less severe bug needs to be solved.

1) SOAP::WSDL (severe bug)
The WSDL implementation does not handle lists of complex types correct and
therefore making auto generated WSDL files throug SOAP::DISCO fail. An
example - Only the important part is shown:

<PHP>
$this->__dispatch_map['search'] =
    array(
        'in' =>
        array('searchRequest' => "{urn:$this->_tns}searchInput"),
	'out' =>
        array('searchResponse' => "{urn:$this->_tns}Services")
    );
$this->__typedef['Services'] =
	array(
		"Services" => "{urn:$this->_tns}Service"
	);
$this->__typedef['Service'] =
    array(
        "name" => "string",
        "serviceKey" => "string",
        "businessKey" => "string"
    );
</PHP>

<Actually>
<complexType name="Services">
	<all>
		<element name="Services" type="tns:Service" />
	</all>
</complexType>
<complexType name="Service">
	<all>
		<element name="name" type="xsd:string" /> <element name="serviceKey"
		type="xsd:string" /> <element name="businessKey" type="xsd:string" />
	</all>
</complexType>

<operation name="search">
	<input message="tns:searchRequest" />
	<output	message="tns:searchResponse" />
</operation>

<message name="searchResponse">
	<part name="searchResponse" type="tns:Services" />
</message>
</Actually>

<Expected>
<complexType name="Service">
	<all>
		<element name="name" type="xsd:string" />
		<element name="serviceKey" type="xsd:string" />
		<element name="businessKey" type="xsd:string" />
	</all>
</complexType>
<complexType name="Services">
	<complexContent>
		<restriction base="SOAP-ENC:Array">
			<attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="tns:Service[]" />
		</restriction>
	</complexContent>
</complexType>

<operation name="search">
	<input message="tns:searchRequest" />
	<output	message="tns:searchResponse" />
</operation>

<message name="searchResponse">
	<part name="services" type="tns:Services" />
</message>
</Expected>

This bug should not be hard to solve. The bug has that affect that having
clients written in .NET or Java (axis) will fail so for that reason I
personally choose to hand write my WSDL files if the service includes
lists of complex types.

2) SOAP::Server. The generated SOAP message (severe bug) The response
generated any requests does not apply to the SOAP specifications - both
1.1 and 1.2. The problem is that the response is not reflecting the WSDL
nor the way specified in the SOAP 1.1 or 1.2. The problem though is only
evident way returning lists of complex types. An example:

<Actually>
<SOAP-ENV:Body>

<ns4:searchResponse>
<return xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:Struct[2]"
SOAP-ENC:offset="[0]"> <item>
	<businessKey
	xsi:type="xsd:string">e869ee12-29de-4909-abb7-84d97b11167f</businessKey>
	<serviceKey
	xsi:type="xsd:string">b2916d6d-7ce1-4456-9d6b-dda9a11b1a45</serviceKey>
	<name xsi:type="xsd:string">IBMTestRegistryWS</name>
</item>
<item>
	<businessKey
	xsi:type="xsd:string">e869ee12-29de-4909-abb7-84d97b11167f</businessKey>
	<serviceKey
	xsi:type="xsd:string">65ab4d1c-049f-4670-b3d2-8ab787835089</serviceKey>
	<name xsi:type="xsd:string">IBMWStomcat</name>
</item>
</return>
</ns4:searchResponse>
</SOAP-ENV:Body>
</Actually>

<Expected>
<SOAP-ENV:Body>
<ns5:searchResponse xmlns:ns5="urn:uddiServer"
	SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
<Services xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/";
	xsi:type="soap-enc:Array" soap-enc:arrayType="ns5:Service[2]">
<Service xsi:type="ns5:Service">
	<businessKey
	xsi:type="xsd:string">e869ee12-29de-4909-abb7-84d97b11167f</businessKey>
	<serviceKey
	xsi:type="xsd:string">b2916d6d-7ce1-4456-9d6b-dda9a11b1a45</serviceKey>
	<name xsi:type="xsd:string">IBMTestRegistryWS</name>
</Service>
<Service xsi:type="ns5:Service">
	<businessKey
	xsi:type="xsd:string">e869ee12-29de-4909-abb7-84d97b11167f</businessKey>
	<serviceKey
	xsi:type="xsd:string">65ab4d1c-049f-4670-b3d2-8ab787835089</serviceKey>
	<name xsi:type="xsd:string">IBMWStomcat</name>
</Service>
</Services>
</ns5:searchResponse>
</SOAP-ENV:Body>
</Expected>

This bug is hard to solve since it requires a complete rewrite of a big
part of PEAR::SOAP. The bug has that affect that having clients written in
.NET or Java (axis) will fail with lists of complex types even with a hand
written WSDL file so for that reason I have made an extention to
PEAR::SOAP which is responsible for handling all responses including
returning lists of complex types.

3) SOAP::DISCO. Always applying urn: in front of the namespace if
namespace is not starting with http://. (minor bug)
According to the WSDL specifications this is wrong. Easy to compensate for
this bug.

Concluding remarks.
To solve this issue I have made an extention to PEAR::SOAP which handles
returning lists of complex types. The response generated by the extention
is closely related to the WSDL, which must be replicated correctly in
PHP. Study my example close. You can get the extention from this address:
ftp://ftp.datanom.net/pub/pear/PEAR.SOAP-list.of.complex.types.tar.gz

The package also includes the example server in PHP plus clients written
in C#, Java, Perl and Python to call the server. The clients are all
working as expected so this should prove my statements above.

Hope to hear any response or bug complains from you all.

-- 
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

-- 
PHP Soap Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [PHP Users]     [Kernel Newbies]     [PHP Database]     [Yosemite]

  Powered by Linux