SOAP Purification Wired Protocol (iii): Writing services in scripting languages

Script Are you a Java developer who longs to stand at the forefront of technology forever? The software industry is changing, you are eager to grasp the future of the web, more importantly, how to put their own years of Java experience to the extreme. To find the answers to these questions, you don't have to go too far, and the answer lies in soap.

SOAP (Simple Object Access Protocol) is a wired protocol that utilizes XML encoding data, which brings a higher level of collaborative operation capability for Java platform Independence and portability. In the second installment of this series on soap, I introduced Apache soap. As one of the implementations of the SOAP specification, Apache Soap simplifies the construction of soap applications. We used Apache soap to construct two simple HelloWorld services and client programs that invoke the Sayhelloto () method of these services. We see that while creating a SOAP service is fairly straightforward, a client program must do a lot of extra work, such as it must set the Call object, invoke the Invoke () method of the calling object, and then parse the response object returned as the result of the call.

In fact, the process of creating SOAP services with Apache SOAP can be simpler, and the only prerequisite is that you have to understand one of several scripting languages. For me-and for most Java developers, fortunately, these scripting languages contain JavaScript. Indeed, in Apache soap, you can create SOAP services with JavaScript. This article is about the specifics of creating a soap service with JavaScript.

first, reconstruct the Apache SOAP
The script support for Apache soap is based on the Bean Scripting Framework (Bsf,bean Script framework). BSF, originally developed by IBM and now released as a source-code project, enables Java programs to run scripts written in other languages, and enables other scripting languages to use existing Java classes. Apache SOAP leverages the former capabilities of BSF. The standard binary version downloaded from the Apache Web site does not support scripting. Specifically, Soap.jar does not contain the Org.apache.soap.server.InvokeBSF class, which is the binding point and interface of Apache soap and BSF. The developers of Apache soap know that not everyone who uses SOAP needs BSF, and not everyone has a scripting engine installed, so script support is omitted from the Soap.jar. To write a SOAP service with scripting, you must reconstruct the source code to introduce the INVOKEBSF class.

First you download the source code (SOAP-SRC-2.0.ZIP) from the http://xml.apache.org/dist/soap/. Then, unzip the downloaded file to the directory installed by Apache soap. In my case, it is the root directory of the E: drive. When you're done, you'll get an src subdirectory in the soap_2-0 directory that contains all the source code for Apache soap. Before you reconstruct Apache soap from your source code, you must also download the required BSF jar files. You can find one in ftp://ftp.mozilla.org/pub/js/. Please use it in conjunction with Mozilla's JavaScript engine rhino, Rhino can download a zip file from http://www.mozilla.org/rhino/download.html. I unzipped this file into the E: Packing directory and finally got a E:\rhino directory containing rhino, and we are interested in its js.jar.

Next, you need a tool that actually performs the reconstructed operation, Ant. Ant is also an Apache software project, and it's a java-based tool. Ant actually works in the same project as Jakarta, which creates the Web server tomcat. In ant, all construction information, such as construction targets, dependencies, etc., is specified through an XML configuration file, which is unique to ant. In addition, Ant is extensible. See the article in the "Reference resources" section at the end of this article to learn how to give full play to Ant's potential. You can download ant from the link provided by the reference resource and unzip the compression (I put it in the root directory of the C: disk).

Now execute the following command from the Apache SOAP installation directory:


Set
Classpath=e:\jakarta-tomcat\lib\servlet.jar; E:\xerces-1_2_0\xerces.jar;
E:\soap-2_0\lib\bsf.jar
C:\build\bin\ant
Because the above command does not specify an XML configuration file, the ant batch command file looks for a file named Build.xml in the current directory (here, E:\soap_2-0). This file is provided by Apache soap. Open this file to see that the INVOKEBSF class is compiled only when Com.ibm.bsf.BSFManager is in Classpath. That's why I put the Bsf.jar (which contains the Bsfmanager class) into the classpath. Copy the newly constructed Soap.jar file from the Build\lib subdirectory to the Lib subdirectory (I recommend modifying the original Soap.jar file for backup). Finally, add Bsf.jar and Js.jar to the classpath of the Web server.

Done! Now you can start writing SOAP services with scripting.

second, the use of JavaScript to write HelloWorld applications
Now, we're rewriting the HelloWorld service for the second article with JavaScript. The complete code for the service program is as follows:


function Sayhelloto (name)
{
Return "Hello" + name + ", how are you?"
}
What could be easier than that? However, do not let this simple and easy to deceive you. In fact, you can do quite a lot of processing in a service program. For example, you can access any standard Java class from the scripting code. Take a look at the modified scripting code below, which outputs the server's time:


function Sayhelloto (name)
{
var today = new Java.util.Date ();
Java.lang.System.out.println ("Today is" + today.tostring ());
Return "Hello" + name + ", how are you?"
}
In addition, you can import and use any of your own Java classes. For example, we could modify the scripting code to use name JavaBean:


Importclass (Packages.hello.Name);
function Sayhelloto (name)
{
var today = new Java.util.Date ();
Java.lang.System.out.println ("Today is" + today.tostring ());
var beanname = new Name ();
Beanname.setname ("John");

Java.lang.System.out.println (Beanname.getname ());
Return "Hello" + name + ", how are you?"
}
third, Deployment Services
Before you use a JavaScript version of a service, you first deploy it. As described in the second article in this series, there are two ways to deploy services in Apache soap: Using the Web interface's administrative tools, or deploying services from the command line. Let's take a look at the specific procedures of both approaches.

3.1 management tools using the Web interface
To use the Web interface's administrative tools, open the http://localhost:8080/apache-soap/admin in a browser. Click the Deploy button on the left side of the window. Remember, the ID input box is used to set the object Id,soap infrastructure uses object IDs to associate RPC (remote procedure Call) requests to the SOAP service. Each Apache SOAP service must have an object ID, and this object ID must be unique between all the services deployed on that server. Set the ID to Urn:hello, which is the ID of the object we set for the service in the second article.

Set the scope input box to application. In retrospect, the scope input box is used to specify the lifetime of the service instance in response to the call request (refer to the second article for more instructions).

In the Methods input box, enter the name of the method that the currently deployed service allows to invoke, separated by a white space character between the names of several methods. Our service supports only one method, namely Sayhelloto ().

Because the service is implemented in JavaScript, rather than in Java, as in the second article, the Provider type input box should be filled with script. Accordingly, the Java provider input boxes (including provider class and static input boxes) do not need to be filled in. But now you must fill in the Script provider input box and choose JavaScript (Rhino) as the scripting language. Since we will provide the script body in the Scripts text input box, we do not need to fill in the Scripting FileName input box now. Copy the following scripting code to the script input box:


Importclass (Packages.hello.Name);
function Sayhelloto (name)
{
var today = new Java.util.Date ();
Java.lang.System.out.println ("Today is" + today.tostring ());
var beanname = new Name ();
Beanname.setname ("John");
Java.lang.System.out.println (Beanname.getname ());
Return "Hello" + name + ", how are you?"
}
Now scroll to the bottom of the screen and click the Deploy button (not the Deploy button on the left side of the window) below the form. To verify that the service has been successfully deployed, click the list button on the left side of the window. At this point, the Urn:hello service should appear in the list of services. Click on this service to confirm that all the information matches the one you just entered.

3.2 Deploying services from the command line
To deploy services from the command line, all deployment information must be placed in an XML deployment descriptor file. The following is the XML deployment descriptor file that I used to deploy this service:


<isd:service xmlns:isd= "Http://xml.apache.org/xml-soap/deployment"
Id= "Urn:hello" >
<isd:provider type= "Script" scope= "Application" methods= "Sayhelloto" >
<isd:script language= "JavaScript" >
Importclass (Packages.hello.Name);
function Sayhelloto (name)
{
var today = new Java.util.Date ();
Java.lang.System.out.println ("Today is" + today.tostring ());
var beanname = new Name ();
Beanname.setname ("John");

Java.lang.System.out.println (Beanname.getname ());
Return "Hello" + name + ", how are you?"
}
</isd:script>
</isd:provider>
</isd:service>
The main difference, compared to the deployment descriptor file used in the second article, is to set the provider type to script instead of Java. For this reason, the deployment descriptor file no longer specifies a Java class, but rather provides scripting code for the service.

You should ensure that the Web server is started before you deploy the service. The following code shows how to deploy the service:


Java org.apache.soap.server.ServiceManagerClient
Http://localhost:8080/apache-soap/servlet/rpcrouter Deploy
Deploymentdescriptor.xml
Deploymentdescriptor.xml is an XML file that contains the deployment description information described earlier. To verify that the service has been successfully deployed, execute the following command:


Java org.apache.soap.server.ServiceManagerClient
Http://localhost:8080/apache-soap/servlet/rpcrouter Query Urn:hello
At this point, we should see the same content as the Deploymentdescriptor.xml file.

Four, test
We used the second article to provide the client program Client.java to test the HelloWorld service. Why can I use the same client program to access a service written by JavaScript? Because the client program doesn't care what language the service is written in. As long as the service understands the SOAP request and is able to return the SOAP reply, the client program does not care how the service is implemented. To recap, here's what I used to run hello. Client's Batch command file:


Set
classpath=e:\soap-2_0\samples\; E:\soap-2_0\lib\soap.jar;
E:\xerces-1_2_0\xerces.jar
Java Hello. Client Tarak

Watch the Web server's console window, and each time we run the client, we can see the current date and the output "John".

Concluding remarks
In this article, I introduced the scripting language support provided by the Apache SOAP implementation. Why do you say it's important? Just analyze why web development is so popular. In my opinion, one of the key reasons is that Web development is mature and almost anyone can construct complex web pages with simple scripting languages like HTML and JavaScript. Similarly, in the server side of web development, people can use JSP, such as easy to learn but powerful scripting language. I think the same reasoning applies to SOAP development. If soap wants to go mainstream and get the majority of people's support, it should be as simple as possible. Apache soap adds support for scripting for this purpose; it dramatically expands the scope of the developer who created the SOAP service.

Don't forget, though, that there is another factor to consider: The client developer, the developer who invokes the SOAP service. As mentioned earlier, the client-side developer of Apache soap has a "disadvantage", adding some work that would otherwise not have been done. So, in the next and final installment of this series, I'll look at a framework based on the new dynamic proxy class introduced by the Java 2 Platform version 1.3, making client programs as straightforward as creating soap services.
Reference Resources

SOAP 1.1 Specification for the Consortium

http://www.w3.org/TR/SOAP/

Download Apache SOAP:

http://xml.apache.org/dist/soap/

For more information on IBM SOAP Engineering:

Http://www.alphaworks.ibm.com/tech/soap4j

For more information about Mozilla Rhino:

http://www.mozilla.org/rhino/

For more information about ant:

Http://jakarta.apache.org/ant/index.html

Leverage Java and ant automation construction processes (javaword,2001 October):

Http://www.javaworld.com/jw-10-2000/jw-1020-ant.html

Download ant:

http://jakarta.apache.org/builds/jakarta-ant/release/v1.2/bin/