Use Web services in PHP5 to access J2EE applications (3)

Using Web services in PHP5 to access J2EE applications (3) explanation WSDL <br/> we have successfully called the Weather service, but have not read its WSDL document. WSDL

We have successfully called the Weather service, but have not read its WSDL document. The details in WSDL are much more open than that in SoapClient. How do we know what to put in the startDate parameter? What do we expect from the returned data? To answer these questions, you must analyze the WSDL in depth.

You can download the WSDL of the Weather Forecast application from the download section. To use different Web services, you only need to open the corresponding 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:

<Wsdl: message name = "getForecastRequest">
<Wsdl: part element = "intf: getForecast" name = "parameters"/>
</Wsdl: message>
The getForecast structure is defined:

<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 this function requires two parameters: xsd: startDate of dateTime type and days of integer type. This exactly matches the SoapClient: _ getTypes function we know, but we still know that startDate can be null (nillable ). Without a doubt, if we simplify the input parameters, the function will be as follows:

$ ForecastResponse = $ soapClient-> getForecast (array ('startdate' => Null, 'Days '=> 3 ));

If the date of today is specified, the result will be exactly the same as that specified.

What if I want to set other start dates? XML Schema defines dateTime as a basic type, formatted according to ISO 8601 standard, for example, "2004-12-01T00: 00: 00 ". If you want to know the weather forecast for three days, you can use the built-in strtotime ("+ 3 days") function to obtain the required date. This function is the same as the time () function, returns the date time in the standard UNIX format, that is, an integer that represents the number of seconds from the year of the year. We know that XML Schema requires that the date be encoded in ISO 8601 with string fields. Therefore, the timeToIso8601 function is compiled in the example client to convert the integer date to the format defined by SOAP encoding. However, we were surprised to find that we didn't actually need to do this. ext/soap was very clever enough to convert the integer date into the required string field format. No matter whether it is an integer or a pre-formatted string, the final SOAP message is the same.

What about the date in the response? In the return request, ext/soap obtains the dateTime field from the SOAP response, but does not perform any format conversion. We want it to return an integer to indicate the number of seconds from the year of the year to the present, but what we actually get is a string formatted according to ISO 8601. So we use the strtotime function to convert it into an integer, and then use strftime to format the integer for easy representation.

Weather Service provides forecasts by date, but it ignores the time component in dateTime encoding. Therefore, we did not consider this adjustment. if we request weather forecasts from services running in different time zones, we may have to do so. For more information about time zone conversion, see the document describing ISO 8601 in references.

Now return to the response format. The previous section mentioned the inconsistency of the data returned by getForecast. The WSDL description tells us that getForecast returns a getForecastResponse object. getForecastResponse can contain an infinite number 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>
A single element array is not allowed in WSDL. Unfortunately, when the response contains only one Weather object, ext/soap does not consider the <sequence> label applied to getForecastResponse in WSDL, this behavior creates unnecessary complexity in the client code.

Finally, the WSDL document tells the SOAP client where the service can be found in 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>