The Visual Basic Web Service
| AddressRequestBean | AddressBean | OpenDaysBean |
|
|
|
The Java Client sends an AddressRequestBean to the VB Web Service which contains the Company Number and Address Number. The AXIS API serializes the AddressRequestBean into an XML Structure using the serializer (AddressBeanSerializer) provided for this purpose. The request is received by VB Web Service and the AddressRequestBean XML Structure is deserialized into an AddressRequestBean VB Type. The database is queried for the address and the returned address information is used to create an AddressBean type which is serialized by the MSSOAP Toolkit and sent to the Java Client, where the reverse process of deserialization takes place. The AddressBean also contains an OpenDays bean, which travels across as part of the reply.
Request
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope namespace info>
<soapenv:Body>
<ns1:getAddress namespace info>
<AddressRequest href="#id0"/>
</ns1:getAddress>
<multiRef id="id0" namespace info>
<CompanyNo xsi:type="xsd:string">108436</CompanyNo>
<AddressNo xsi:type="xsd:int">2</AddressNo>
</multiRef>
</soapenv:Body>
</soapenv:Envelope>
Response
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<SOAP-ENV:Envelope namespace info>
<SOAP-ENV:Body namespace info>
<SOAPSDK4:getAddressResponse namespace info >
<Result href="#id1"/>
<AddressRequest href="#id3"/>
</SOAPSDK4:getAddressResponse>
<SOAPSDK5:AddressBean namespace info id="id1" SOAPSDK3:root="0">
<CompanyNo>108436</CompanyNo>
<AddressNo>1</AddressNo>
<Name>Ubix Copy & Print Centre</Name>
<Street>Address TO BE Advised,</Street>
<City>Auckland</City>
<State></State>
<Country>New Zealand</Country>
<ZipCode></ZipCode>
<AllowDeliveries>true</AllowDeliveries>
<AcceptanceFrom>0</AcceptanceFrom>
<AcceptanceTo>0</AcceptanceTo>
<NotificationFax></NotificationFax>
<NotificationPhone></NotificationPhone>
<NotificationEmail></NotificationEmail>
<OpenDaysBean href="#id2"/>
<PreferredDeliveryTime>0</PreferredDeliveryTime>
<TruckDepartureTime>0</TruckDepartureTime>
</SOAPSDK5:AddressBean>
<SOAPSDK6:OpenDaysBean namespace info id="id2" SOAPSDK3:root="0">
<Sunday>false</Sunday>
<Monday>true</Monday>
<Tuesday>true</Tuesday>
<Wednesday>true</Wednesday>
<Thursday>true</Thursday>
<Friday>true</Friday>
<Saturday>false</Saturday>
</SOAPSDK6:OpenDaysBean>
<SOAPSDK7:AddressRequestBean namespace info id="id3" SOAPSDK3:root="0">
<CompanyNo>108436</CompanyNo>
<AddressNo>1</AddressNo>
</SOAPSDK7:AddressRequestBean>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The .WSDL file used by the Service was generated using the WSDLGen utility of the MSSOAP Toolkit 3.0. The AddressRequest user defined type is sent back with the response by default. Since we do not require this information and as it can be substantial when a request size is large, we can make editions to the .WSDL file to instruct the web service not to send the request back. This seems to occur in files for services which involve user defined types like AddressBean, AddressRequestBean, etc.
At this point in time, the implementation of the service returning multiple addresses is such that it repeatedly queries the database for address information for each address request in the array, instead of making one call to retrieve all the addresses. As a result, making multiple requests is inefficient at present. It should be possible to improve response times by making smarter database access calls.
When requesting an array of addresses from the service, the array of AddressRequestBeans should be one element longer (for instance, if I want to request 50 addresses, I should send the service an array of address requests of length 51. The final element should be of type AddressRequestBean, but the contents of which can be null).
The web service will return an array 51 addresses with one of the addresses (usually the last address) set to null. The VB web service, it seems, receives only an array of 50 requests, which it processes and sends back 50 addresses. The toolkit for some reason seems to be adding the null address to the last element.
If the Java client sends an array of 50 address requests expecting a similar number of addresses back, it in fact receives only 49, with one of the addresses (usually the last address) set to null. The workaround is to send one extra request.