Web Service Between .NET, Java and MS SOAP Toolkit - Part II

RTM Changes:

1. Include the following at the start of the file:
   Imports MSSOAPLib
   Imports WSDLGENLib
   
   
2. Replace "Debug.Print" with System.Diagnostics.Debug.WriteLine
   
   
3. Click on Project, References and Click on the COM tab.

Add Reference to Microsoft Soap Type Library

This second article in this series dedicated to Web services comes as a sequel to the first one in which I started to tell you how you could build different kind of clients and services using MS SOAP Toolkit, Apache SOAP for Java and .NET Framework.

In the last article I mentioned something about the incompatibility between a MS SOAP client and an Apache SOAP server (the infamous xsi:type). As far as I know the version 2.2 didn't solve this problem, which is Apache SOAP Server is still expecting all parameters to have a type specified. But, the good news is that there is a work around to this problem. Many of you sent me e-mails asking how to do this. Well it is fairly simply.

Apache SOAP Server and clients

Do you remember the Apache SOAP server we wrote last time? Well another good news is that you don't have to change anything inside the server. You only need to change the deployment descriptor.

Let me tell you more about the workaround before writing anything. The major difference between MS implementation of SOAP and Apache for Java's is that the former relies on WSDL files to fully describe the service when the latter doesn't. This is why in the initial implementation of the Apache SOAP for Java the type is required to be specified for each parameter. The server has no other mean to know the type of the parameters unless is specified in the call. In the MS implementation the WSDL file has enough information and the server can figure out even if the call tells nothing about this.

Now, the solution to our problem is: when you deploy your service you can specify the type mapping of each parameter in your methods. The Java service uses this whenever there isn't enough information in the method call.

So you must add a mappings section to your deployment script. I modified the deployment descriptor for our service.

<isd:service xmlns:isd=http://xml.apache.org/xml-soap/deployment
id="urn:MyService ">
....<isd:mappings>
<isd:map encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
xmlns:x="" qname="x:num1"
xml2JavaClassName="org.apache.soap.encoding.soapenc.DoubleDeserializer"/>
<isd:map encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
xmlns:x="" qname="x:num2"
xml2JavaClassName="org.apache.soap.encoding.soapenc.DoubleDeserializer"/>
</isd:mappings>
....</isd:service>
 
That's all. Believe it or not that's all you have to change. The MS STK client doesn't need any change either. The same mention for the .NET client, don't change anything.

This will complete our incursion to building clients and services (simple ones) using the three major frameworks available. I must mention here that there are other frameworks for building SOAP servers and clients so don't be shy and publish source code and information so we can all learn about them. I remember seeing among people on SOAP Builders discussion group another name: Glue. They were at beta version last time a checked their web site but I'm sure they will quickly be releasing their product.

Generic client for Web Services

Ok so now we know hot to build a web service when we have enough information about the service itself: we are either the developers of the service or good friends with the developer, so we can get the "signature" of the service at the time we write the client.

Now, suppose you want to build a client that is able to call a service knowing only the name of the methods or something similar. My example will try to add two numbers searching a Math service and calling the methods. A more practical example could be a stock checker or something similar.

The steps I follow are:

• search the UDDI and find businesses which can help me solve my   problem. The way we find the business is not standardized since there isn't a set of categories with businesses. For example we'll make the convention that Math businesses will be stored under Math category. Next we'll query for the URL where the web service stores the WSDL file.
  
  
• This is the first step to finalize our solution. I'll skip the code for this section since UDDI and related APIs are the subject of a future article.
  
  
• Once we have the WSDL file we'll parse this file and find out information about the web service. Based on this information we'll build a SOAP request. To build a soap request I used the low level API in STK since we don't know from the beginning how many parameters the service will call. 

And here is the code:

Option Explicit On
Function BuildOperation( _
ByVal WSDLFileName As String, _
ByVal WSMLFileName As String, _
ByVal sOperation As String) As CWSDLOperation
Dim Reader As WSDLReader
Dim EnumService As EnumWSDLService
Dim Service As WSDLService
Dim EnumPort As EnumWSDLPorts
Dim Port As WSDLPort
Dim EnumOperation As EnumWSDLOperations
Dim Operation As WSDLOperation
Dim EnumMapper As EnumSoapMappers
Dim Mapper As SoapMapper
Dim Fetched As Long
Dim objWSDLOperation As CWSDLOperation
Dim objOperationPart As COperationPart
Dim bAddParts As Boolean
objWSDLOperation = New CWSDLOperation
Reader = New WSDLReader
Reader.Load(WSDLFileName, WSMLFileName)
Reader.GetSoapServices(EnumService)
EnumService.Next(1, Service, Fetched)
Do While Fetched = 1
Service.GetSoapPorts(EnumPort)
EnumPort.Next(1, Port, Fetched)
Do While Fetched = 1
Port.GetSoapOperations(EnumOperation)
EnumOperation.Next(1, Operation, Fetched)
Do While Fetched = 1
' check to see if the operation is here
bAddParts = False
If InStr(1, Operation.soapAction, "." + sOperation) > 0 Then
With objWSDLOperation
.m_Parts = New Collection
.m_PortAddress = Port.address
.m_SoapAction = Operation.soapAction
End With
bAddParts = True
Operation.GetOperationParts(EnumMapper)
EnumMapper.Next(1, Mapper, Fetched)
Do While Fetched = 1
If bAddParts Then
objOperationPart = New COperationPart
objOperationPart.m_Name = Mapper.partName
Call objWSDLOperation.m_Parts.Add(objOperationPart)
End If
EnumMapper.Next(1, Mapper, Fetched)
Loop
End IfEnumOperation.Next(1, Operation, Fetched)
Loop
EnumPort.Next(1, Port, Fetched)
Loop
EnumService.Next(1, Service, Fetched)
Loop
BuildOperation = objWSDLOperation
End Function

Function build BuildOperation() parses the WSDL file and gathers information about the service: name, parameters, namespaces used, etc and finally returns a CWSDLOperation object.

With this information we can move next to build the SOAP request and invoke the web service. The service is invoked by calling Execute method on CWSDLOperation object. In my example the Execute method will simply print the result of the add operation.

In my example the rule I applied for finding the right method and passing the parameter is pretty simple but in a real application you can implement more sophisticated mechanisms or assume there are few patterns for each method naming.

Here is the code for the CWSDLOperation class.

Option Explicit On
Private Const WRAPPER_ELEMENT_NAMESPACE = ""
Public m_PortAddress As String
Public m_SoapAction As String
Public m_Parts As Collection
Public Sub Execute()
If m_SoapAction <> vbNullString Then
On Error GoTo ErrorHandler
Dim Serializer As SoapSerializer
Dim Reader As SoapReader
Dim Connector As SoapConnector
Dim part As COperationPart
Dim sMethod As String, sNamespace As String
Connector = New HttpConnector
Connector.Property("EndPointURL") = m_PortAddress
Connector.Property("SoapAction") = m_SoapAction
Connector.BeginMessage()
Serializer = New SoapSerializer
Serializer.Init(Connector.InputStream)
sMethod = Mid$(m_SoapAction, InStrRev(m_SoapAction, ".") + 1)
sNamespace = Left$(m_SoapAction, InStr(m_SoapAction, "/action") - 1)Serializer.startEnvelope()
Serializer.startBody()
Serializer.startElement(sMethod, sNamespace + "/message/", , "m")
For Each part In m_Parts
Serializer.startElement(part.m_Name)
Serializer.writeString("20")
Serializer.endElement()
Next
Serializer.endElement()
Serializer.endBody()
Serializer.endEnvelope()
Connector.EndMessage()
Reader = New SoapReader
Reader.Load(Connector.OutputStream)
If Not Reader.Fault Is Nothing Then
MsgBox(Reader.faultstring.Text, vbExclamation)
Else
Debug.Print(Reader.RPCResult.Text)
End If
End If
Exit Sub
ErrorHandler:
MsgBox("ERROR: " & Err.Description, vbExclamation)
Err.Clear()
Exit Sub
End Sub

COperationPart class is very simply:

Option Explicit
Public m_Name As String
If you want to simplify the code you can substitute the COperationPart class with a String variable. There are more fields that can be added to the COperationPart class but I removed them for simplicity of the code. The other information available in the WSDL file for a OperationPart are:

• elementName
• callIndex
• elementType
• messageName
• isInput
• partName
• xmlNameSpace
• comValue
• parameterOrder

To test the sample application you need to build 2 simple Web services with STK MathLib1 and MathLib2. MathLib1 implements add method and MathLib2 implements addNumbers method. Both methods accept 2 parameters as double values.

After you create these two web services change the namespace in one of them so something else than default, so you replicate a real situation.

Create a VB project, add the two classes, than add a form, on the form add a button and insert the following code in his click event.

Private Sub cmdCallServices_Click()
Call BuildOperation("C:\work\xarea\soap\MathLib\MathLib1\MathLib1.WSDL", _
"C:\work\soap\MathLib\MathLib1\MathLib1.WSML", "add").Execute()
Call BuildOperation("C:\work\xarea\soap\MathLib\MathLib2\MathLib2.WSDL", _
"C:\work\soap\MathLib\MathLib2\MathLib2.WSML", "add").Execute()
End Sub

This article is tested and/or updated to RTM by Dipal Choksi.