page 1Chapter 12: Building Serversand Clients: Application Servers

laboredbumbaileyΛογισμικό & κατασκευή λογ/κού

7 Ιουν 2012 (πριν από 5 χρόνια και 5 μήνες)

499 εμφανίσεις

page 1
Chapter 12: Building Servers
and Clients: Application Servers
Although it's possible to build simple servers (and clients) without support, in practice you would build them
using an IDE like netbeans
or, minimally, ant; and deploy them using an application server, like Glassfish or. If
you want the examples in this section to work, then you will need to download netbeans and Glassfish and install
them. You should end up with Glassfish running on port 8080, with the Admin Console port being 4848 (you
access the Admin Console with a web browser at URL http://localhost:4848). Be careful because it's
pretty easy to end up with multiple JAS instances running (e.g. if you're also experimenting with Glassfish) and
then you can have a lot of trouble getting services to deploy properly.
.1. Getting and Deploying NetBeans and Glassfish
The easiest way to do this is to download them both as a package from here:
http://www.netbeans.org/downloads/index.html
Note that if you choose the Java version (which you obviously should) you get glassfish bundled with it - both
the stable version 2.1 and the pre-release version 3 (which we will not use). The Windows version is about
240MB - Linux and Mac OS X are slightly smaller. To start it on Windows navigate to the Glassfish bin folder
(usually, C:\Program Files\glassfish xxx\bin, where 'xxx' depends on the version) and type:
asadmin start-domain domain1
In all cases, the installation contains a docs folder with a quick start guide. As usual with this kind of software,
it's very capable and flexible. As is also usual in a short module, we're only going to be doing very basic things.
If you are running Windows 7 (or Vista) then you might get an error message about not being able to get the
server file lock. If you do, then navigate to the folder 'domain1' within glassfish and add write and modify
permissions for the user(s) you are running glassfish as.
Once you have glassfish installed and running, you can open up the Admin Console (the URL is
localhost:4848) and you should see something like this (you may have to enter the admin username
('admin') and password which you may have been prompted for in the install. If not, then no username/
password should be necessary.
page 2
Fig.1. Java Application Server Console
The trouble with building applications with tools is that sometimes it turns into 'magic' - you don't know what's
going on. So we will try to explain some of the detail as we go.
12.2. The Server
In netbeans, create a new Web Application project (start with File -> New) and add a new package (mine's called
ObiWan and a new class (UseTheForce). The class needs to contain this code:

package ObiWan;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService
public class UseTheForce {

@WebMethod
public String useTheForce(String name){
String retVal = "Use the force, " + name + "!";
return retVal;
}
}
That's more or less it - right click the project and choose 'Deploy' and the project should build and be deployed to
glassfish. You'll see something like this:
page 3
Fig.2. The Service
Now you can test the service by clicking the test button:
page 4
Fig.3. Testing the Service
Fig.4. The Result
So what happens when you deploy the service? Not much really - a set of deployment descriptor files get added
to the project (sun-web.xml, web.xml, webservices.xml) along with the WSDL and schemas but if you look in
page 5
them they don't seem to contain much - which is because they are not strictly required for JAX-WS. Writing and
deploying a service is pretty easy. Note though the style of building applications from a mixture of executable
code and declarative XML is becoming very common - for building interfaces as well as web applications - and
is likely to spread to other areas.
12.3. The Client
To build a client, you need to create a new Java application project (not a Web project), and add the following
source code (in an appropriately-named package):

package jediclient;
import javax.xml.ws.WebServiceRef;
public class Luke {
@WebServiceRef(wsdlLocation = "http://localhost:8080/ObiWan/
UseTheForceService?wsdl")

public static void main(String[] args) {

try {
obiwan.UseTheForceService service = new
obiwan.UseTheForceService();
obiwan.UseTheForce port = service.getUseTheForcePort();
java.lang.String result = port.useTheForce("Luke");
System.out.println("Result = "+result);
} catch (Exception ex) {
// TODO handle custom exceptions here
}
}
}

NOTE: the package name 'obiwan' is in lower case even though we entered it as 'ObiWan'.
If you've changed the name(s) of the service, then the WSDL URL will be wrong. The easiest way to fix it is
to open the WSDL in JAS and cut and paste the URL into the @WebServiceRef annotation. We are not
quite finished yet: you need to add the WSDL to the project to get it to work. To do this, right click on the
project and choose New -> Web Service. Then you need to specify the WSDL file - either by choosing the
project containing the service (which is the easiest if, like here, you are developing both on the same machine);
specifying the actual file; or (essential for a service that is actually remote) by specifying the URL.
Now you should be able to run the project and get the string 'Use the Force, Luke!'. What does the code above
to? Hopefully, only the first two lines of the 'try' block should be unclear. The first line looks like it creates and
instance of the service proxy. But notice it's called UseTheForceService - and we wrote UseTheForce.
UseTheForceService is actually a system-generated factory class that is used to create server proxies,
called ports. This happens in the second line.