Download Source Code:WebServiceArticleCT.zip
This article will try to explain the how you can build web services and/or clients with any of the three languages: .NET, MS SOAP Toolkit and Java. But the real point of the article is to show you how you can build clients for web services from any of above-mentioned languages.
Not long ago .NET was released and many of us jumped on to write ASP.NET web sites, C# programs or Web Services. I was really amazed by the relatively easy way someone can write a web service with .NET. I previously had written some web services with MS SOAP Toolkit and Apache SOAP for Java. And then someone asked me to write clients using different languages for those web services. It proved to be not trivial.
Although SOAP is now a standard, different implementations of web services are using it in ways that sometime makes the interoperability with other SOAPs hard if not impossible.
My sample application is a very simple web service with one method: addNumbers. As you already deducted it will add two numbers and return the result. The name of the application is Hello2 and the source files are attached to this message.
STK Service and Clients
First lets write the Web Service using the MS SOAP Toolkit with an ASP listener and an ISAPI listener as well.
The addNumbers method in the Visual Basic class is:
Public Function addNumbers(ByVal NumberOne As Double, ByVal NumberTwo As Double) As Double addNumbers = NumberOne + NumberTwo End Function |
Using the WSDLGen.exe wizard you can generate the ISAPI listener, the ASP listener or both (not at the same time, of course). I choosed to generate both the ASP and the ISAPI listener, so I named my WSDL files Hello2ASP.WSDL respectively Hello2Isapi.WSDL.
Now lets write some clients for this Hello2 web service.
STK Client
The first client is a Visual Basic client using high level API in SOAP Toolkit. Create a VB project add a form and then a button. The code bellow is executed when the button is hit.
Private Sub cmdDoTest_Click()
|
As you can see the client is pretty simple and there are no problems. All the details like building the SOAP request message and parsing the result SOAP message is hidden from the programmer.
WS_URL is the URL of the service. The high level API in SOAP Toolkit needs a WSDL file so this URL points to one of the WSDL files. At this point it doesnt matter which one you provide. Though, the performance is better with the ISAPI listener.
Java Client
The second client well write for our Hello2 server is a Java client. I used for this the Apache SOAP 2.1. You can download it for free from http://xml.apache.org/soap/index.html.
The Java class file for the ASP listener is listed bellow.
import java.io.*; public class testClient { // check response
|
As you can see the url variable points to the ASP listener. To point the Java client to the ISAPI listener make the following change:
URL url = new URL ("http://localhost/Hello2/Hello2Isapi.wsdl");
.NET Client
Now it is time to write a .NET client for our Hello2 Web service. Using the WSDL.exe tool from .NET Framework Beta 2 you must generate a proxy class for our service. Execute following command.
wsdl http://localhost/Hello2/Hello2Isapi.wsdl
This will generate Hello2Isapi.cs file. This is the .NET proxy class using C# (this is the default language used). Check out the params for wsdl.exe to generate the proxy using VB.NET or another language.
Now compile the proxy using
csc.exe /t:library Hello2Isapi.cs
Its time to write the .NET client, which uses the proxy class to access the Hello2 web service. Here is the code for the C# client.
using System; public class Hello2ISapiClient {
|
Compile the client using Hello2IsapiClient.cs /reference:Hello2Isapi.dll and run it with Hello2IsapiClient.
At this point we have a MS SOAP Toolkit web service and three clients written with: SOAP Toolkit, Java respectively .NET
Apache SOAP for Java Service and Clients
Lets move on now and write the same service using Apache SOAP for Java. Here is the service:
package samples.MyService; import java.util.*; |
I used the name MyService for my service and I added it to the samples package. This way you dont need to add a context into the Tomcat server. Just deploy the service into SOAP using the following deployment descriptor file:
<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment" id="urn:myservice-service" checkMustUnderstands="false"> <isd:provider type="java" scope="Application" methods="addNumbers">
<isd:java class="samples.MyService.MyService" static="false"/>
</isd:provider>
</isd:service>
I wont explain here how to set up Apache SOAP into Tomcat since there is enough guidance in the Apache SOAP documentation.
Apache SOAP Client
Its time to write the clients for this service. The first one is written using Java. Here is the code:
package samples.MyService; public static void main(String[] args) throws Exception { Call call = new Call();
|
As you can see the code is pretty straightforward. No problems expected since the same SOAP library is used.
The code for a STK client is bellow:
STK Client
There are errors in both high level and low level clients because xsi:type is required in Apache SOAP for Java.
.NET Client
Due to the same issue a .NET client wont work either.
.NET Service and Clients
.NET Framework Beta 2 is the newest technology and changes are expected to happen from Beta 2 to the final release. Major changes already have been made when Beta 2 was released. This is no surprise since Microsoft had warned developers that might happen.
Writing a web service with .NET is very simple and can be done in several ways. I choose to write my web service in C# using a ASMX file. Here is the content of the file.
<%@ WebService Language="C#" Class="MyService" %> |
The advantage of using a ASMX file is that no compilation is needed so a hot deployment can be done.
Place the file into a virtual directory under IIS. You can test the service with your IE with http://localhost/testdotnetws/myservice.asmx
.NET Client
Writing a client for this service is similar with the .NET client we write earlier. When generating the proxy file specify the WSDL file with http://localhost/testdotnetws/myservice.asmx?WSDL. This is the way .NET framework creates the WSDL file on-demand.
STK Client
Using the high level API would be a faster solution but there are some issues there and I couldnt solve them out so I used the low level API. The client code is not difficult. The only trick is to enable the .NET service for RPC type of calls. Thanks to Christian Weyer who helped me with this issue.
Look at the web service code and notice the System.Web.Services.Protocols.SoapRpcMethodAttribute attribute for our method. Without this attribute the default type of conversation in .NET is message.
Java Client
In the java client youll have to modify the url as follows:
URL url = new URL (http://localhost/aspnet_test/myservice/myservice.asmx);
Compile and run.
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抰 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抰 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抯 is that the former relies on WSDL files to fully describe the service when the latter doesn抰. 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抰 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" |
That抯 all. Believe it or not that抯 all you have to change. The MS STK client doesn抰 need any change either. The same mention for the .NET client, don抰 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抰 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抦 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 搒ignature?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抰 a set of categories with businesses. For example we抣l make the convention that Math businesses will be stored under Math category. Next we抣l query for the URL where the web service stores the WSDL file.
This is the first step to finalize our solution. I抣l 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抣l parse this file and find out information about the web service. Based on this information we抣l build a SOAP request. To build a soap request I used the low level API in STK since we don抰 know from the beginning how many parameters the service will call.
And here is the code:
Option Explicit Function BuildOperation( _ Dim Reader As WSDLReader Dim objWSDLOperation As CWSDLOperation Set objWSDLOperation = New CWSDLOperation Do While Fetched = 1 If InStr(1, Operation.soapAction, "." + sOperation) > 0 Then EnumMapper.Next 1, Mapper, Fetched If bAddParts Then EnumMapper.Next 1, Mapper, Fetched EnumOperation.Next 1, Operation, Fetched EnumPort.Next 1, Port, Fetched EnumService.Next 1, Service, Fetched |
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 Private Const WRAPPER_ELEMENT_NAMESPACE = "" Public Sub Execute() Dim Serializer As SoapSerializer Dim part As COperationPart Set Serializer = New SoapSerializer sMethod = Mid$(m_SoapAction, InStrRev(m_SoapAction, ".") + 1) Serializer.startEnvelope For Each part In m_Parts Serializer.endElement Connector.EndMessage Set Reader = New SoapReader If Not Reader.Fault Is Nothing Then Exit Sub ErrorHandler: |
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
Compile and you are ready to go!