Developing Web Services with WSAS IDE -Part2

Submitted on January 28, 2008 - 03:05. Story :

Articles

Level :

Introductory

Project :

WSAS > Java

Realm :

Tooling

This tutorial by Lahiru Sandakith will walk you through the process of developing a gaming service exposed as a Web service, to show how easy it is to test and debug a POJO web service with WSAS's newly introduced feature of Eclipse WTP IDE Integration. This is the second part of the tutorial.

Introduction

WSAS WSO2 Web Services Application Server (WSAS) allows Web service developers to easily and speedily expose, configure and manage any type of Java application as Web services and Web services related artifacts. WSO2 WSAS comes with integration for the Eclipse WTP, which enables the Web service developers to easily work within their favorite IDE on all their Web services requirements, covering the full cycle of developing, deploying, testing and debugging.

It is recommended that you read the 1st Part of this tutorial, in order to follow the steps in this tutorial smoothly.

As a pre-requisite to this tutorial, it is recommended that you go and explore the Online Documentation of WSO2 WSAS to get to know the workings of the WSO2 Web Services application server.

This tutorial is applicable to the Sun JDK 1.5, Eclipse WTP v2.0 and WSO2 WSAS 2.1 or higher.

Applies To

WSO2 WSAS	v2.1
Eclipse WTP	v2.0
Sun JDK	v1.5

Part 2
- Locally Test the WSASGameService with JUnit.
- Debug WSASGameService Web service using the WSAS IDE
Conclusion
References

Part 2

In the 1st Part of this tutorial, we covered the steps involved with the installation and configuration of WSO2 WSAS, together with Eclipse WTP and steps on developing and deploying WSO2GameService using WSAS IDE. In this second part of the tutorial, we explore the steps necessary to test the WSO2GameService locally, with a test case written in JUnit, and debug the service to cheat the game play. Lets first look at how we can write a JUnit to test WSO2GameService deployment.

Locally Test the WSO2GameService with JUnit.

Let us first create a TestCase on the same package as org.wso2.wsas.example. We will name it as WSO2GameserviceTestCase. We use the New Class wizard available in eclipse for this purpose.
Copy the contents of the WSO2GameServiceTestCase into the new class created, and compile and build it. If we look at the TestCase functionality, we will see that there are two test methods. One method will test the WSO2GameService against a given array of guesses - without setting a custom guessing range, and the other - with a custom range set.
In the next step, lets run the JUnit against the deployed service. You can select Run and in the proceeding dialog box, select the JUnit tab and select the newly created WSO2GameServiceTestCase and execute it. Make sure that you have successfully deployed the WSO2GameService on WSAS IDE, as mentioned in Part 1 of the tutorial. You will be able to successfully run the testcase and observe results again and again.

Debug WSASGameService webservice using WSAS IDE.

Now, let's see how we can debug the Web service using the WSAS IDE. First, you need to generate client stubs and write a client using those stubs to invoke the Gaming Service. So, as the first step, let's create client stubs. For this, startup the Web Services client wizard in Eclipse by selecting File -> New -> Other... -> Web Services -> Web Service Client.
On the next page of the wizard, you will have to select the service definition url of the Web service. You can obtain this from the WSAS Admin console page where all the services are listed. It would look similar to the value in the following image. Also make sure that configuration settings for Server, Web Service Runtime and Client Project, are set according to your settings. You can click "Next >" if you need to edit client code generation options, o,r you can click "Finish" to generate client stubs.
If you click "Next >" you will be taken to the client code generation - options page. Here, according to Axis2 Client code generations options, you can configure your preferences, such as, entering a custom package name or to generate both 'sync' and 'async' clients. In this case, just select the default settings and select "Finish".
You will see some additional files that were created and added to the WSASDebugCheck project, along with client stubs.
After generating client stubs, in the next step, you will create the WSO2GameServiceClient using those same stubs, in order to invoke the service. So, using the "New Java Class" wizard, create the WSO2GameServiceClient class within the package org.wso2.wsas.example.
After creating the class, you can open the WSO2GameServiceClient class on the editor in order to fill in the contents. As you can see, it uses client stubs created from the WSDL document, to invoke the WSO2GameService hosted on WSAS. If you look closely, you will see that this client has the ability to invoke the WSO2GameService with a default range and also the ability to set a custom range. See that only the stub needed to be instantiated, and, that it was done with the WSAS IDE. The stub is used to call startGame, guess etc service methods for game play.
Now we can run the client against the service, and look at the console output of the game play. You can right-click on the client and choose Run As -> Java Application, or, use the Run menu to run the WSO2GameServiceClient.
We can observe the different behavior in different invocation of the client, because of service being behaving on a random value generated by it self.
As we have now seen the behavior of our gaming service against stubs, we will go ahead and try to debug the service. For that, we have to set a debug pointer on service code and invoke the service. First of all, we need to start the server in the debugging mode. Lets shutdown the server, and start it on debugging. On the WSAS IDE select the Menu WSAS -> WSAS Server -> WSAS Server Stop and wait for the message detailing the server inactivity. Then you can start WSAS IDE in debug mode by selecting, WSAS -> WSAS Server -> WSAS Debug
You will then see, that at the startup, there is a socket opened by the server. The default server port is open and is available under the preferences option in WSAS configuration.
After server startup, we then have to next setup a debug point in the service, to suspend the service on client invocations. For convinience and with a plan to cheat the guessing game, we will set the debug point at a point, where we match the guess with the machienGuess in the WSO2GameService. Click on the left boader to toggle break points at different lines of the WSO2GameService.
Then we have to start the eclipse IDE to listen in to the remote application. For this purpose, we need to start the Debug Console. This can be done by selecting Run -> Open debug Dialog and then selecting on the Remote Java Application and selecting the new remote application. Point it to WSO2GameService. Here, you can set connection information for the WSAS server on the debug mode. Note that the host is selected to localhost and that the port is 8088 (this is the port the WSAS server starts in debug mode). You can give any name to this configuration but going with the convention, we gave it WSASDebugCheck.
Now when you click debug, and start the VM, it will wait for remote application. Whenever clients invoke the Web service, we can now suspend the application and inspect the parameters that were set for that particular instance of the service. In our case, we can see which the machine guess is, and cheat the next time with ease.
Now, we can either run the WSO2GameService client to invoke the service, or WSAS management console and use Tryit facility to invoke and play the game service. Lets run the client again as we did earlier.
Because of the client invocation, we can see that the eclipse debug point is reached, and the the service is suspended. On the variable pane of the debug perspective, you can see that the local varible of the current invocation is being initialized and that the machineGuess was 2. With that, we can see how we are able to win the Guessing game in the next invocation. We can use all the eclipse debug options to step, navigate, inspect etc. on the suspended service invocation and then, release it to WSAS to send the service response back to the client invocation.

This completes the tutorial. Now you can stop the remote service lister and the WSAS IDE to get back to your normal environment.

Feel free to send in your feedback on this tutorial to: wsas-java-dev@wso2.com, wsas-java-user@wso2.com. Optionally, you can make a post on our user forums for clarifications and requirements on WSAS.

Conclusion

Thanks to the WSAS IDE plug-in, the creation, deployment, testing and debugging of Web services - is no longer a tedious task. Using the WSAS IDE you can do it all for all your own custom made Web services, using the wizard.