Ksuweb.kennesaw.edu



Chapter 8 JAX-WS Web Services

8.1. Introduction to Web Services

8.2. WSDL

8.3. SOAP

8.4 Your First Web Service

8.5 Accessing Web Services

8.6 Web Services, Session Beans, and State

8.7 RESTful Web Services

8.8 Practice Labs

8.9 Summary

8.10 Chapter Review

8.11 Exercises

In This Chapter:

JAX-WS Web Services

WSDL

SOAP

Accessing Web Services

REST/RESTful Web Service Concepts

Practice Labs

8.1 Introduction to Web Services

What is a web service? If you asked some people on the street they would probably say things like “DSL,” “dial-up,” or even start naming their favorite websites or browsing program. But web services aren't something that people use directly. A web service is a service meant for consumption by another application or component, much in the same way that session beans are meant to be used by other application components. The Internet connects millions of computers across the world together to allow people to communicate and access services provided by other people. Web services work in much the same way, using the standard technologies already in place to allow applications to communicate and provide services to other applications.

Business logic can be put into session beans for enterprise applications and accessed remotely as we learned earlier. But there may be some situations in which it is undesirable or even impossible to allow this level of access to an enterprise application's session beans. What if you don't control the network that the other components are on? What if you don't have control over any aspect of the code that needs your business logic (including the language it is written in)?

Let's say that you have a business idea to create an authentication service. Customers will be able to pass a username and password to your application from their client applications and get a boolean value of true if the authentication succeeds, or false if it does not. This would free developers from having to write authentication logic into their applications, managing security policies, and maintaining a database of user information. This would be easy to implement using session beans. But some customers may be behind a firewall and unable to make a direct connection to the application server hosting the session bean. Other customers might not be using Java in the client application.

If you were able to use a ubiquitous protocol, one that is likely to be available even in restricted networks, you could use that protocol to communicate with the client application. Web services were designed for situations just like this. Rather than limiting potential clients to only those using Java, web services allow applications to communicate over the widely used HTTP protocol, the same protocol that powers the World Wide Web. Most networks are Internet-accessible and it is increasingly unlikely that HTTP traffic will be blocked. In addition, the technologies involved are accessible from a wide variety of programming languages. This is just what Web Services do – allow communication between two applications using standard technologies like HTTP and XML.

Web services use existing Internet application protocols like HTTP as a carrier for messages between the web service and the client. The HTTP protocol becomes a sort of box for shipping web services messages back and forth between applications. The basic transport protocol that provides Internet connectivity is TCP/IP, without which there would be no Web for the web services to be part of. Dependent upon that protocol is the application protocol that wraps up the web service message. Normally, this would be the end of the line – it is the protocol that web browsers and web servers use to communicate. HTTP wasn't designed to carry information about remote method calls, however, so another layer is needed to allow such information to be communicated. In the case of web services this other layer is called SOAP (originally an acronym for Simple Object Access Protocol), a protocol that defines the messages that are sent between applications so that they can communicate useful messages to each other, like “run this method,” or “here is the result of your message request.” The following diagram shows how the different levels of protocols work together.

[pic]

Figure 8.1: Web Service Messages

8.2 WSDL

Java's web service API is called JAX-WS, for Java API for XML Web Services. It uses the SOAP protocol (which in turn uses XML) to exchange messages between applications. The services are defined by a WSDL (Web Services Description Language) document. The WSDL document is yet another XML document that defines the capabilities of the web service and allows remote applications to see which methods the web service provides. One of the advantages of using NetBeans to develop web services in Java is that the creation is greatly simplified. While it is a worthwhile activity to learn XML, you will not have to write a single line of XML by hand to get a web service up and running. Here is a sample of a simple web service with one method:

The types are defined in the following file, imported in the element. It defines the messages “add” (the message from the client to the server) and “addResponse” (the return message from the server to the client) and the parameters each message contains. The “add” message takes two parameters of type “int” named “addend1” and “addend2.” The “addResponse” message returns a single parameter of type “int” named “return,” which is the sum of the two parameters received in the “add” message:

The WSDL document contains several important elements:

-- The types element defines the acceptable types of data used in various parts of the web service messages that correspond to data types in regular Java programs, which define the type and range of values that can be stored in a variable. Types are defined with XML schema.

-- The message element describes some communication between a web service and a client. Messages are used in web service operations and are analogous to parameters or return values in normal programs. A message could define some information that is sent to the web service by the client (like a parameter passed to a method) or information sent to the client from the web service (like the return value from a method). Messages are composed of parts, which are associated with the types defined in the WSDL document. For example, the message tag in the preceding example with the name=”addResponse” attribute defines a message that contains a part named “parameters.” The data that the “parameters” part can contain is defined by the XML schema in the element.

-- The bindings element describes the format of the message (like SOAP) and protocols that the web service will use. Web services are not restricted to the HTTP protocol. While HTTP is a very widespread protocol, it is not uncommon to bind a web service to SMTP (the protocol underlying e-mail) for some applications.

-- The operation element describes what the web service can do. It is like a method or function in a traditional programming language. An operation is described in terms of the messages that it sends and receives just as a Java method could be described in terms of the parameters it takes and the value it returns. The “add” operation in our example shows a request/response message pattern (a request is received by the web service and a response is sent). Operations are not limited to the request/response model. It is possible to send a request to a web service without getting a response back or even for a web service to send output without having received a request. Such messaging models often use the SMTP protocol, which does not rely on the request/response pattern that HTTP does.

-- The portType element describes the web service as a whole by describing the operations that are available. While it is not the top-level element in our example, it does the important work of tying together the operations and messages that define the web service's functionality.

Table 8.1: Web service parts and their corresponding Java parts

| |Class |

| |Method |

| |Method parameter or return value |

| |Data types (e.g., int, double, String, etc.) |

Having NetBeans generate this file automatically from the code is a great benefit. It allows the programmer to concentrate on programming the logic for the web service instead of spending the majority of the time writing XML documents.

The most common transport for web service messages is the HTTP protocol. It is a well-defined protocol that has been around for years and isn't likely to change much in the near future. It is so ubiquitous that even PDAs and cell phones are using it now. In addition to its widespread adoption, it has another property that makes it useful for web services. HTTP is a response-request protocol. That is, when you send a request, you expect a response. When you type an address in your web browser and nothing comes back, you naturally assume something is wrong. This is somewhat analogous to the way we expect methods in programs to behave. Even if we don't know what the method's internal code looks like, we expect that if we call the method, it will return. In a sense we are making a request to the method and expecting a response (a return value).

8.3 SOAP

When some client application wants to use a web service it must create a port, or stub, for the methods that are implemented in the web service. When methods are called on the port, the application wraps up the method call in a SOAP request and sends it off to the server. SOAP is a protocol or standard for wrapping up these types of requests in XML to help facilitate communication. The server receives the request, executes the method with the parameters sent by the client, and then sends the return value in a SOAP response back to the client. Here is a sample SOAP request / response generated by the method call: port.add(3, 2):

SOAP Request:

3

2

SOAP Response:

5

As you can see from the sample, the request contains the method name (add) as an element in the tag. The parameters are passed as elements contained within the element. The elements within the body element are defined by the web service's WSDL (since not every web service will use elements named “addend1” or “addend2”). The response contains the return value wrapped in the “return” tags. Once the response has been received by the client the return value is parsed and returned to the calling code as if it were a local method. We could write a program to generate and parse these SOAP requests and responses, but luckily we don't have to. Using NetBeans to create a web service in Java saves a great deal of time because neither the web service nor the client code has to parse the XML in the messages. That will all be handled by the API.

8.4 Your First Web Service

To get started with web services, we will create a simple “Hello World” web service that prints out a friendly message.

[pic]Open the NetBeans IDE.

Create a new project by choosing New → Project from the File menu to open the New Project Wizard dialog. In the dialog, choose Web from the category list on the left and choose Web Application from the Project list on the right. Click the Next button to continue.

Enter a name for the web project and click Next to continue.

Accept the defaults on the next dialog box and click Finish to create the project.

Right-click on the project node and choose New → Web Service from the context menu.

Name your web service HelloService and assign a package name. Click Finish to create the web service.

A new node named Web Services appears under the web project and HelloService.java appears in the Editor pane. The Editor pane has a design view (the default view) and a source view. Click the source button at the top of the Editor pane to view the code.

[pic]

Click the Design button at the top of the Editor pane to switch back to the Design view.

[pic]

Click the Add Operation button in the upper left portion of the Design view.

[pic]

In the Add Operation wizard, change the name to sayHello and click OK to create the operation.

Click on the Source button at the top of the Editor pane to switch to the source code.

Edit the sayHello method and replace the default return statement to return the String “Hello! Welcome to the wonderful world of Web Services!”

Click the Run button to start GlassFish. Additionally, you may need to choose Clean and Build Main Project from the Build menu or use the keyboard shortcut SHIFT + F11 to deploy the project to the web container.

[pic]

Expand the Web Services node in the project and right-click the HelloService web service. Choose Test Web Service from the context menu to test the web service you just created.

[pic]

Your web browser should automatically open to the web service tester. If it does not, open your favorite web browser and point it to .

Click the sayHello button to view the results of your web service.

[pic]

8.5 Accessing Web Services

Now that we know what a web service is, what it is used for, and how it behaves, let's see what one actually looks like:

package com.datavikings.converter;

import javax.jws.WebMethod;

import javax.jws.WebService;

@WebService

public class Converter {

@WebMethod(operationName = "poundsToKilos")

public double poundsToKilos(@WebParam(name = "pounds") double pounds) {

return pounds / 2.2;

}

@WebMethod(operationName = "kilosToPounds")

public double kilosToPounds(@WebParam(name = "kilos") double kilos) {

return kilos * 2.2;

}

}

As you can see from the sample code, the @WebService annotation is used to signal to the container that this is a web service. The publicly accessible methods are decorated with the @WebMethod annotation. The @WebMethod annotation may take a parameter called operationName, which maps the method to a web service operation defined in the WSDL document. The parameters may additionally be dressed up with the @WebParam annotation that takes a name parameter, which would create a customized mapping of the parameter to a WSDL message part. The method signatures are automatically generated by NetBeans when creating a web service and will take care of putting the appropriate annotations in place as well.

NetBeans makes accessing a web service just as easy as creating one. Here is a simple example of a web service client:

package com.datavikings.converterclient;

public class WebServiceClient {

public static void main(String[] args) {

try {

com.datavikings.converter.ConverterService service = new com.datavikings.converter.ConverterService();

com.datavikings.converter.Converter port = service.getConverterPort();

double pounds = 180;

double result = port.poundsToKilos(pounds);

System.out.println(pounds + " pounds = " + result + " kilos");

}

catch (Exception e) {

e.printStackTrace();

}

}

}

The service is instantiated by creating a new object of the type defined by the web service. Remember earlier when we drew an analogy between a web service and a class? Now the analogy isn't just an analogy. The web service “object” reference can be used to create a port. The port is what will be used locally to call the web service operations. You can think of the port as a kind of remote control. When you push a button on your television remote the operation happens remotely as if you had pushed the same button on the television itself. The port is the remote control for the web service.

8.6 Web Services, Session Beans, and State

Web services can be created as part of a web application or an enterprise application. In fact, if you have business logic in a session bean already, you can turn it into a web service with very little work. When creating a new web service in NetBeans, the New Web Service wizard will ask if you want to create a new web service from scratch or from an existing session bean. If you point the wizard to an existing session bean it can automatically create the web service. The reason the conversion is so simple is that, aside from the annotations and some XML, session beans and web services are essentially just regular vanilla Java objects. A session bean can hide its implementation details behind a Java interface and the web service hides its implementation details behind the WSDL file. Once those details are worked out (generating the interface for session beans or the WSDL for web services) the same class can be used for both.

So we can see that web services and session beans can fill the same role, that of providing business logic, but they do so in different ways. The session beans do so as part of the overall Java Enterprise platform and web services as a language-agnostic service that can be integrated into a stand-alone application. Although stateful session beans may keep track of a client's state between invocations, HTTP and SMTP are at their core stateless protocols.

When the HTTP protocol was designed it was intended to be a stateless protocol, that is to say that each request was seen by the protocol as a new conversation. There was no mechanism for associating one request with another. As the Internet grew and changed, methods were developed to allow the client and server to associate related requests. This functionality is essential to e-commerce because without it, there would be no way for websites to remember the contents of a virtual shopping cart between requests. This is most often done by means of cookies, small key/value pairs that are passed along in the HTTP request. A session ID is normally sent with each request so that a server that supports sessions can look up information that is relevant to the current request or prior requests.

Imagine waiting for a table at a crowded restaurant. The hostess tells you that there is an hour wait, so you give your name and wait for an hour. When you go back to ask how much longer you must wait, you give your name again so the hostess can check the list and see your position on the waiting list. If you didn't give your name, she might think you weren't on the list and make you wait another hour (after all, it's busy and she can't remember every face that comes in).

Obviously, the stateful session bean has the advantage when it comes to maintaining state information about a client. Although there are some advanced methods for maintaining state in web services, they are limited to the HTTP protocol. This means that any web services that maintain state cannot be bound to other protocols such as SMTP. The particular techniques for implementing such stateful web services are beyond the scope of this text.

8.7 RESTful Web Services

REST stands for Representation State Transfer. It is a term coined by Roy Fielding in his doctoral dissertation. Essentially REST is an architectural style for distributed systems. The classic example of a REST system is the World Wide Web. The client begins by viewing a page, which is a representation of some information. The representation that the client receives places the client in a particular state. The client is given a set of URLs in the document that make other resources (or representations of other resources) available. Each URL presented to the client represents a resource, which could in turn provide more URLs to allow the client to drill down deeper into the resource or move to resources that are related to the current resource. By following these links, the client's state changes and the representations that are referenced by the hyperlinks are transferred to the client.

Web services may also be built around this concept. Instead of using SOAP as a message format, the RESTful way of doing things uses the HTTP protocol directly to transmit information. Messages that are intended to receive information from the web service use the GET command from the HTTP protocol. Similarly, messages that are intended to provide the web service with some information from the client to update a resource would use a PUT command, and instructions to delete something would be issues from the client as DELETE commands. The PUT and DELETE commands are not often used, but are part of the HTTP protocol specification. Data sent to the web service is placed in the body of a PUT request, but does not have to conform to the SOAP standard. It is up to the web service and the client to understand the format of the messages, whether they are XML or another technology such as JSON.

The four basic HTTP methods map neatly onto the four basic operations for a database system:

• GET – Read

• POST – Create

• PUT – Update

• DELETE – Delete

It is often convenient to think of this mapping, but it also highlights an important and often overlooked rule of web development. GET requests should be idempotent. We discussed this in chapter one, but it bears repeating here. The GET request retrieves a representation of a resource. It should never alter the resource it is requesting. To update a resource, use the PUT method. To create a new resource, use the POST method. A GET request should be safe for the resource, leaving it in the same state it was before the request and able to be sent multiple times with no side effects.

A resource in a RESTful system could be anything. In the classic example of the World Wide Web, HTML documents are resources, as are the images that may be referenced in the documents. A resource should be identifiable by a unique URL. If you have ever used a web application that does not identify each screen with a unique URL, you will immediately see the advantage of addressing resources this way. Imagine you are filing your taxes. You spend the better part of 45 minutes entering numbers into web forms and clicking the Next button on each page only to realize that you left your last tax form on your desk at work. But you can't simply bookmark the application, because each page was submitted to the same generic URL via POST. If you try to go back to the page after bookmarking it, you will have to start all over. Rather than require a sequence of specific inputs in a particular order to retrieve a resource, each resource in a RESTful system has its own URL.

Imagine that you are designing a web service for a travel agency to allow agents to create, view, and update travel itineraries via a web service. Each resource involved in the travel plan (such as airline flights) is exposed under a specific URL. Retrieving via HTTP would return a list of all available flights. Each of the flights in the list is in turn represented by a URL that is an extension or refinement of the /resources/flights/ path. To choose flight 815, for example, the URL corresponding to that resource might be . If further refinement is available the web service may allow a client to drill down to seat resources under flight 815 to see the available seats on the flight. If other resources are involved with the flight resource (such as destinations), the URLs that correspond to those resources would also be present, allowing the client to jump to the related resource.

As you can see from the listing below, the RESTful web service request is much simpler than its SOAP counterpart. There is no bulky XML to parse – the entire semantics of the resource being accessed are in the URL.

Sample RESTful Web Service request:

Request: GET

Sample RESTful Web Service response:

United Airlines

New York Newark Intl Arpt (EWR)

2008-06-16T22:30:00-04:00

Confirmed

Oakland (OAK)

2008-06-16T13:00:00-04:00

68

1

United Airlines 71

128

The RESTful web service reply does contain XML in our example. The advantage of XML here is that the data describes itself very simply. In the above example a flight resources was requested, specifically, flight 1. The flight element in the response contains several pieces of information such as the airline, airport, and time of departure. It also contains a reference to a trip, which is represented by another URL. The client that requested the flight resource now has, by virtue of the tripRef element, a URL to follow to get information about the related trip. Not all resources can be represented by XML, however. Recall that in the World Wide Web, images are resources as well, with their own representation. Today many different types of resources are represented on the Internet. Images, videos, music, documents, and even executable programs are all represented as resources out in the wilds of the Web, each with their own specific representation. The important thing is that the client can understand the representation. After all, what good is access to a resource if you can't understand it? For this reason XML is a popular choice for representing resources that do not already have a standardized representation format.

Because a REST system is session-less, RESTful web services do not maintain state between calls. Each URL should uniquely identify a resource and should contain all information necessary to locate a specific resource, making the need for session tracking unnecessary. The URLs do not actually need to exist as part of a server's file system (as you would expect from a web server serving up static pages), but they must be unique so that the web service can use the URL to identify the resource that is being requested. In general, web services built around REST are not described in terms of what they can do as much as what they can offer. That is, the emphasis is not as much on implementing business logic as it is exposing resources to the client.

This is one of the reasons that state is not emphasized in REST systems – the resources that are being represented are not business methods that need to keep track of the client's state. Instead, they are things that have their own state that the client can view or update. To make an analogy with the English language, RESTful web services are nouns (things that can be represented and shared), whereas JAX-WS web services are verbs (actions that are performed). Put another way, JAX-WS web services expose methods that can be executed, whereas RESTful web services expose data elements that can be accessed. In this way RESTful web services complement JAX-WS web services just as session beans complement entity classes in Java Enterprise applications. For a stateful JAX-WS web service method like a hit counter for a website, it is important to uniquely identify the client and also to save information about the previous calls that the client made (otherwise, the hit counter would be inaccurate, either displaying the total number of hits from all clients or displaying just 1 hit because it cannot remember the ones that came before). For a RESTful web service that represents a database, the state of the client is mostly irrelevant. The database itself keeps track of its own state and the web service offers a representation to whoever asks for it, regardless of whether or not they have previously seen the information. The state of the resource is what is important rather than the client.

As a matter of fact, the session/entity class analogy is more than a simple metaphor. Just as JAX-WS web services can be easily created from existing session beans, RESTful web services can be created from entity classes in a similar fashion, exposing the underlying database as a resource. Lab 3 will show how to create a RESTful web service from a simple database.

8.8 Practice Labs

8.8.1 Lab 1: Current Time Web Service

[pic]Open NetBeans by double-clicking the NetBeans icon.

Go to File → New Project to start the New Project wizard.

In the New Project wizard, choose Web in the category list on the left and Web Application from the project list on the right and click Next.

At the next prompt, enter WSLab as the project name.

At the next prompt, accept the defaults for the project, making sure that GlassFish is set as the server and click Finish.

When the newly created project opens, right-click on the top-level node WSLab and choose New → Web Service from the context menu to start the New Web Service wizard.

In the New Web Service wizard menu, enter Time as the web service name, provide a package name for the web service, and make sure that the Create Web Service from Scratch option is selected.

Expand the WSLab node and the Web Services subnode will reveal the newly created web service named Time. Double-click the web service to open it in the Editor window in Design mode, which displays a summary of the operations and some Quality of Service options.

[pic]

Click Source at the top of the Editor pane to view the source code for the web service.

[pic]

Right-click on the Time web service and choose Add Operation from the context menu to start the Add Operation wizard.

[pic]

In the Add Operation wizard, set the name to getTime and keep the return type as java.lang.String (the default). Click OK to add the operation to the web service.

The source code for the newly created operation appears in the class file for the web service Time.java.

In the Time.java file, locate the getTime() method and replace the automatically generated return statement with the following code:

return new Date().toString();

The function should now look like this:

[pic]

A red underline will appear under the word Date() in the code listing. Click on the lightbulb icon at the right edge of the Editor window (it will appear to the right of the line of code in question) and choose Add Import for java.util.Date from the context menu to import the Date class from the java.util package.

[pic]

Click the run icon in the toolbar to run the web application. This will automatically start GlassFish and deploy the application. It will also open a web browser to the application's default Hello World page, which you may close.

[pic]

Right-click the Time web service in the Project pane and choose Test from the context menu. This will open a web browser that will display a Servlet designed to allow you to test the web service.

[pic]

On the web service tester page, click the getTime button to make the Servlet invoke the getTime() method in the web service. The next page will display the return value and the SOAP request and response.

8.8.2 Lab 2: Current Time Web Service Client

[pic]Open NetBeans by double-clicking the NetBeans icon.

Go to File → New Project to start the New Project wizard.

[pic]

In the New Project wizard, choose Java in the category list on the left and Java Application from the project list on the right and click Next.

At the next prompt, enter WSClient as the name of the application and click Finish.

When the newly created project opens, right-click on the top-level node WSClient and choose New → Web Service Client from the context menu to start the New Web Service Client wizard.

[pic]

The New Web Service Client wizard asks where the web service is located. You can specify a project, a local file, or a URL that points to a WSDL file.

Choose the Project option and click the Browse button to browse. In the browse window, expand the WSLab project (from Lab 1) and choose the Time web service. Click OK.

[pic]

The box next to the project option in the New Web Service Client dialog is now populated with the URL of the WSDL file that describes the Time service in the WSLab project. Click Finish to add the web service client.

Open Main.java in the editor pane (it should have opened automatically when the project was created). Right-click inside the main() method and choose Insert Code → Call Web Service Operation from the context menu.

[pic]

[pic]

In the Select Operation to Invoke dialog box, expand the nodes until you see the getTime operation and click OK.

[pic]

The code to access the getTime operation will be automatically inserted at the cursor position in the Main.java file. The resulting Main class should look like this:

public class Main {

/**

* @param args the command line arguments

*/

public static void main(String[] args) {

// TODO code application logic here

String time = getTime();

try {

// Call Web Service Operation

com.datavikings.webservice.TimeService service = new com.datavikings.webservice.TimeService();

com.datavikings.webservice.Time port = service.getTimePort();

// TODO process result here

java.lang.String result = port.getTime();

System.out.println("Result = "+result);

} catch (Exception ex) {

// TODO handle custom exceptions here

}

}

}

Click the run icon in the toolbar to run the application.

[pic]

The client's output will show up in the Output pane of the NetBeans IDE at the bottom of the window.

8.8.3 Lab 3: RESTful Web Service

[pic]Open NetBeans by double-clicking the NetBeans icon.

Go to File → New Project to start the New Project wizard.

[pic]

In the New Project wizard, choose Web in the category list on the left and Web Application from the project list on the right and click Next.

[pic]

At the next prompt, enter RESTLab as the project name.

At the next prompt, accept the defaults for the project, making sure that GlassFish is set as the server and click Finish.

When the newly created project opens, right-click on the top-level node RESTLab and choose New → Other from the context menu to start the New File wizard.

[pic]

In the New File wizard, choose Persistence from the category list on the left and choose Entity Classes from Database from the file type list on the right and click Next.

[pic]

At the next dialog, choose New Data Source from the drop-down menu.

[pic]

In the Create Data Source dialog box, enter jdbc/travel as the JNDI name and choose the TRAVEL database from the Database Connection drop-down list and click OK.

[pic]

The list of Available Tables on the left will show several tables. Highlight the Flight table and click the Add > button to move it and all of the tables it references to the Selected Tables list on the right. Click Next.

On the next screen, click the Create Persistence Unit button to create a persistence unit for this project. Accept the default values and click OK.

[pic]

Enter lab.restful in the package name field and click Finish to create the entity classes.

[pic]

Right-click on the top-level node in the project again and choose New → Other from the menu to open the New File wizard.

[pic]

Select Web Services from the category list on the left and choose RESTful Web Service from Entity Classes on the right. Click Next.

[pic]

Click the Add All >> button to move all of the available entity classes from the Available Entity Classes list to the Selected Entity Classes list and click Next.

[pic]

Click Finish on the next dialog to accept the default package names and create the web service.

[pic]

Test the newly-created RESTful web service by right-clicking on the top-level node in the project and selecting Test RESTful Web Services from the context menu.

[pic]

NetBeans will start GlassFish and open your default browser to a page that will allow you to test the web service. On the right side of the page you will see the table resources in the Travel database. Click on flights in the list and a menu will appear on the right. Choose GET (application/xml) from the drop-down menu and click the Test button to view the first 10 records of the flights table in the database.

[pic]

8.9 Summary

In this chapter we discussed web services, a powerful, platform-independent tool for enabling communication between applications. Web services use existing standard technologies to make method calls over a commonly used application protocol such as HTTP or SMTP. The web service itself is described in a WSDL file, which is an XML document that contains definitions for the bindings, messages, and types used in the web service communication. Web services play much the same role as session beans, providing business logic to an application. When used with the HTTP protocol a web service can maintain state between calls by leveraging sessions in the HTTP protocol. When HTTP sessions are used, both the client and the web service must take steps to enable use of the session management feature.

Web services based on the REST architectural style do not save state between requests and do not use SOAP as a message format. RESTful web services expose representations of resources that clients may request. A RESTful web service may expose a resource for Create, Read, Update, and Delete (CRUD) operations.

8.10 Chapter Review

What is a web service?

a. An application that people use to access the Internet.

b. A service that applications may access through common standard protocols.

c. A method for applications to access the network.

d. A service that companies use to provide access to the Internet.

What is one advantage of using standard protocols to access web services?

a. Commonly used protocols like HTTP are not likely to be blocked by firewalls.

b. HTTP and SMTP protocols were designed as tunneling protocols.

c. Commonly used protocols like WSDL are easy to implement.

d. The SOAP protocol guarantees delivery of application messages.

Name two common application protocols used for communication with web services.

a. WSDL

b. SMTP

c. HTTP

d. HTML

What is the purpose of a WSDL document?

a. To enable XML support in a web application.

b. To tunnel the data sent to a web service.

c. To encapsulate the data sent to a web service.

d. To describe a web service's capabilities.

Which of the following are not main tags used in a WSDL document (choose two)?

a. types

b. message

c. operations

d. return

How are session beans and JAX-WS web services similar?

a. Both require a Java client.

b. Both encapsulate business logic.

c. They use the same communication protocols.

d. There are no similarities between the two.

How are session beans and JAX-WS web services different?

a. Web services cannot be created from a POJO (Plain Old Java object).

b. Web services use standard Internet protocols such as HTTP or SMTP for communication.

c. Web services cannot be accessed remotely.

d. Web services do not encapsulate business logic.

When is it advantageous to use web services instead of session beans?

a. When the client platform or development environment is unknown or may vary.

b. When the client does not have Internet access.

c. When the client and business logic reside on the same JVM instance.

d. After normal business hours.

What does REST stand for?

a. Representation of Electronic State Transmission

b. Resource State Transfer

c. Representation State Transfer

d. Rotten Eggs Smell Terrible

Name a commonly used REST system.

a. E-mail

b. The World Wide Web

c. Databases

d. Session Beans

True or False: RESTful web services maintain state between requests from the same client.

What is the name of the message protocol that JAX-WS web services use?

a. SOAP

b. WSDL

c. HTML

d. REST

RESTful web services do not use SOAP. How does a RESTful web service know the difference between a request to view a resource and a request to update a resource?

a. The HTTP status code returned from the web service.

b. A command embedded in the HTTP POST body.

c. The HTTP command used to access the resource.

d. Different URLs correspond to different actions.

Which type of web service lends itself well to sharing resources such as databases?

a. RESTful

b. JAX-WS

c. SOAP

d. XML

Which type of web service lends itself well to implementing business logic?

a. RESTful

b. JAX-WS

c. SOAP

d. XML

Answers to Chapter Review Questions

B

A

B & C

D

D

B

B

A

C

B

False

A

C

A

B

8.11 Exercises

Web services can also be added to the web module of an enterprise application. Implement exercise 2 from Chapter 6: Session Beans as a web service.

Write a hit counter web service that stores the number of times the getCount() method has been executed. Write Two Servlets, ServletA and ServletB, that both display getCount(). Test the web service using the Servlets. Are the counts accurate? Why or why not?

* Modify the web service in exercise 2 so that the hit counter will be accurate for each client. There is more than one way to accomplish this (hint: use entities to persist the number of hits for a client to a database).

* denotes a challenging exercise

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download