Using Web Services in PHP5 to access Java-EE applications (3)

J2ee|php5|web|web Service | program | Access Interpretation WSDL

We have successfully invoked the Weather service, but have not seen its WSDL document yet. The details in the WSDL are much more public than the soapclient. How do we know what to put in the StartDate parameter? What do we expect to actually get from the returned data? To answer these questions, you must analyze the WSDL more deeply.

You can download the WSDL for the Weather Forecast application from the download section. If you use a different Web service, just open the appropriate WSDL document in the browser.

The WSDL for the getforecast operation is:

<wsdl:operation name= "Getforecast"
<wsdl:input message= "Intf:getforecastrequest" name= "Getforecastrequest"
<wsdl:output message= "Intf:getforecastresponse" name= "Getforecastresponse"
</wsdl:operation>
The getforecastrequest message is defined as:

<wsdl:message name= "Getforecastrequest"
<wsdl:part element= "Intf:getforecast" name= "parameters"
</wsdl:message>
And the GETFORECAST structure is defined as:

<element name= "Getforecast"
<complexType>
<sequence>
<element name= "StartDate" nillable= "true" type= "Xsd:datetime"/>
<element name= "Days" type= "Xsd:int"
</sequence>
</complexType>
</element>
So we know that the function requires two parameters, Xsd:datetime type of StartDate and integer type days. This exactly matches the Soapclient::_gettypes function we know, but now we also know that StartDate can be empty (nillable). There is no doubt that if we simplify the input parameters, the function will look like the following:

$forecastResponse = $soapClient->getforecast (' StartDate ' =>null, ' Days ' =>3));

If you explicitly specify today's date, the result will be exactly the same as the specified.

What if you want to make other start dates? XML schemas define dateTime as a basic type, formatted according to the ISO 8601 standard, such as "2004-12-01t00:00:00". Assuming you want to know the weather forecast after three days, you can use the built-in function strtotime ("+3 Day") to get the date you want, the same function as the time () function, which returns the standard UNIX-formatted datetime, which is an integer that represents the number of seconds from the start of the year to the present We know that the XML Schema requirement date is encoded in an ISO 8601 format with a string field, so the timeToIso8601 function is written in the sample client to convert the integer date to the format defined by the SOAP encoding. But we were surprised to find that we didn't really need to do that, Ext/soap very cleverly converted the integer date to the Required String field format. Whether you pass an integer or a preformatted string, it doesn't matter, and the final delivery of the SOAP message is the same.

What about the dates in the response? On the return trip, Ext/soap obtained the DateTime field from the SOAP response, but did not make any format conversions. We want it to return an integer that represents the number of seconds from the year to now, but actually gets the string formatted according to ISO 8601. We then use the Strtotime function to convert it to an integer and then use strftime to format the integer so that it can be represented.

The Weather Service provides forecasts by date, but it ignores the time component in DateTime coding. So we have not considered this adjustment, and if you request weather forecasts from services running in different time zones, you may have to do so. If you want to learn more about time zone conversions, see the articles in resources that describe the ISO 8601 standard.

Now go back to the response format. The inconsistency of Getforecast return data was mentioned in the previous section. The WSDL description tells us that Getforecast returns a Getforecastresponse object that getforecastresponse can contain infinitely many lists of complex types called Weather:

<element name= "Getforecastresponse"
<complexType>
<sequence>
<element maxoccurs= "unbounded" name= "Getforecastreturn" type= "Tns2:weather"/>
</sequence>
</complexType>
</element>

<complextype name= "Weather"
<sequence>
<element name= "condition" nillable= "true" type= "xsd:string"/>
<element name= "Date" nillable= "true" type= "Xsd:datetime"/>
<element name= "Winddirection" nillable= "true" type= "xsd:string"/>
<element name= "windspeed" type= "Xsd:int"
<element name= "TemperatureCelsius" type= "Xsd:int"
<element name= "DBFlag" type= "Xsd:boolean"
</sequence>
</complexType>
The WSDL does not allow for a special case of the Unit Prime group. Unfortunately, when the response contains only one Weather object, Ext/soap does not consider the <sequence> label applied to Getforecastresponse in the WSDL, because this behavior creates unnecessary complexity in the client code.

Finally, the WSDL document also tells the SOAP client where to find the service from somewhere on the network:

<wsdl:service name= "Weatherforecastejbservice"
<wsdl:port binding= "Intf:weatherforecastejbsoapbinding"
Name= "WEATHERFORECASTEJB" >
<wsdlsoap:address location=
"Http://localhost:9080/ItsoWebService2RouterWeb/services/WeatherForecastEJB"/>
</wsdl:port>
</wsdl:service>