Microsoft KB Archive/894709

= List of SOAP interoperability issues that you may experience when you use the JBuilder client to develop and maintain SOAP client applications in SQL Server 2005 =

Article ID: 894709

Article Last Modified on 11/20/2007

-

APPLIES TO


 * Microsoft SQL Server 2005 Developer Edition
 * Microsoft SQL Server 2005 Enterprise Edition
 * Microsoft SQL Server 2005 Express Edition
 * Microsoft SQL Server 2005 Standard Edition
 * Microsoft SQL Server 2005 Standard X64 Edition
 * Microsoft SQL Server 2005 Enterprise X64 Edition

-



INTRODUCTION
You can use the native HTTP SOAP support that was introduced in Microsoft SQL Server 2005 to expose the Transact-SQL programmability of SQL Server as Web methods. For example, you can expose the stored procedures or user-defined functions as Web methods. When you use this functionality, SQL Server 2005 can be accessed as a SOAP v1.2-compliant server that is reachable over HTTP by both SOAP 1.1 clients and SOAP 1.2 clients.

This article describes SOAP interoperability issues that you may experience when you use the JBuilder client. You can use JBuilder to develop and maintain SOAP client applications.



MORE INFORMATION
If you want to use JBuilder to create applications that communicate with SQL Server 2005, we highly recommend that you use the simple Web Services Description Language (WSDL) document instead of the default (extended) WSDL document. You can retrieve the simple WSDL document by including the &quot;?wsdlsimple&quot; query string at the end of the URL. For example, the following URL retrieves the simple WSDL document:

http:// /endpoint?wsdlsimple

SQL Server 2005 requires correct Microsoft Windows NT authentication before the WSDL document can be retrieved. For JBuilder to import the WSDL document, you may have to retrieve the WSDL document and then save the WSDL document as a file or as a Web page.

Most of the following issues occur when the default WSDL setting is used together with HTTP SOAP endpoints. This default (extended) WSDL information is returned when the query value of &quot;wsdl&quot; is used in the URL query string to retrieve the WSDL for an HTTP SOAP endpoint. For example, the following URL query string includes this query value:

http:// /endpointPath?wsdl

This default WSDL query frequently returns extended SQL type information that the JBuilder client cannot fully translate.

SqlRowSet schema definition
For JBuilder to correctly parse the default (extended) WSDL document that SQL Server 2005 generates, you may have to modify the XSD schema definition for the complex type that is named SqlRowSet. The XSD schema definition that SQL Server 2005 generates appears as the following code.       You may have to modify the XSD schema definition to the following code for JBuilder to correctly interpret the default (extended) WSDL document.     

Serialization issues when binary data types are imported
The class that the JBuilder WSDL importer generates for binary data types does not serialize the binary instance value into Base64 encoding before the class sends the binary instance value across a network. Instead, the class sends the bytes in the binary instance value as a single string.

Note The binary data types are varbinary, binary, image, and timestamp.

For example, a binary instance has byte value of the following. 0x55, 0x35 This value is encoded during the request as the following. 5535 This issue only occurs when the client class codes were generated from default (extended) WSDL for an HTTP SOAP endpoint. This issue does not affect client class codes that were generated from simple WSDL.

JBuilder client support for boolean data type values
When the client code is generated based on the default (extended) WSDL document, the SQL Bit type is handled by using the built-in Java boolean data type. This data type does not support mapping of numeric equivalent values such as 1 and 0 for values that are true/false.

To work around this issue, use simple WSDL. The SQL Bit type is handled as the java.lang.Boolean data type. This data type supports mapping of numeric equivalent values such as 1 and 0 for values that are true/false.

You can also work around this issue by modifying the generated client code to change from the built-in Java boolean data type to the java.lang.Boolean data type.

JBuilder client support for datetime data type values
When the client code is generated based on the default (extended) WSDL document, the SQL datetime data type is handled by the java.util.Calendar class. On the request, the java.util.Calendar class serializes SQL datetime values into string values that are not compliant with the xsd:datetime type.

To work around this issue, create client code that is based on the simple WSDL document.

The JBuilder client generates a data type class that does not have any variables to hold the XML value
When the client code is generated based on the default (extended) WSDL document, the generated class to handle a schema bounded XML parameter has the following code. public class _RetTypedXml_a implements java.io.Serializable { public _RetTypedXml_a { } } Notice that no variable is defined to handle the actual XML value. The following code is a sample generated class for a non-schema bounded XML parameter. public class Xml implements java.io.Serializable { private org.apache.axis.message.MessageElement [] _any; public Xml { } } Notice that the code contains the _any variable. This variable is of the MessageElement type. The _any variable is created to handle the XML value.

To work around this issue, use simple WSDL. You can also work around this issue by manually updating the generated client code to include the following variable. private org.apache.axis.message.MessageElement [] _any;

The JBuilder client does not fully support the SqlResultStream response format
When the client code is generated based on the default (extended) WSDL document, the JBuilder client generates a class to handle the SqlResultStream data structure. The SqlResultStream data structure is included in the response from a stored procedure.

However, the generated class only handles the first instance of the following different types of SQL responses that can make up the SqlResultStream data structure. public class SqlResultStream implements java.io.Serializable { private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlRowSet sqlRowSet; private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlXml sqlXml; private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlMessage.SqlMessage sqlMessage; private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlRowCount.SqlRowCount sqlRowCount; private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlResultCode sqlResultCode; private com.microsoft.schemas.sqlserver._2004.SOAP.types.SqlTransaction.SqlTransaction sqlTransaction; Therefore, if a stored procedure returns more than one rowset (sqlRowSet), the client can retrieve only the first rowset. The client cannot retrieve any additional rowsets that the stored procedure may return.

To work around this issue, use simple WSDL where the response structure from a stored procedure is a sequence of xsd:any element declarations.

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.

Keywords: kbhowto kbinfo KB894709

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.