ECLIPSE WEB TOOLS PLATFORM developing java web applications PHẦN 7 potx

technologies such as CORBA, Java RMI, and DCOM failed to gain significant traction on the Internet. When XML emerged, Microsoft proposed that it could be used as an architecturally neutral way to serialize graphs of objects. SOAP was proposed as the carrier for these serialized object graphs and the serializa- tion algorithm was dubbed SOAP encoding. The fact that XML was used as the serialization syntax was incidental. To use SOAP encoding, you had to have matching client and service implementations that understood the SOAP encod- ing algorithm. The client and the server were assumed to both be implemented in conventional object-oriented programming languages. The flaw in this approach is that exchanging objects is really not what the Web is all about. The Web is highly heterogeneous, and there are many types of clients and ways of processing XML. For example, XML can be processed using DOM, SAX, StAX, XPath, XSLT, and XQuery to name a few. In fact, one of the design principles behind XML is that it should be easily processable by a variety of applications. SOAP encoding clearly violates that principle. A better approach to the design of Web service interfaces is to view Web service operations as document exchanges. After all, business in the real world is transacted by the exchange of documents. For example, I fill out a driver’s license application form and the motor vehicle department sends me my driver’s license. I do not remotely invoke the driver’s license procedure or send the motor vehicle department a serialized driver’s license application form object graph. Documents are very natural, and XML is an excellent way to rep- resent them in information systems. XML Schema is the W3C standard type system for XML documents. But XML is really just a representation of a docu- ment, albeit a very convenient one for many purposes. In general, there may be other useful representations of documents. For example, if I just want to display the document to a human, then HTML or PDF is a better representation. Or if I want a highly interactive AJAX-based Web user interface to display the docu- ment, then perhaps JavaScript Object Notation (JSON) is a good representa- tion. On the other hand, if I want to use the document in a Service-Oriented Architecture (SOA) application, then document/literal SOAP is probably the best representation. REST Web architecture teaches us that the way to design an application is to identify its important concepts, model them as resources, and assign them Uniform Resource Identifiers (URI). Software agents, such as Web browsers or Web appli- cations, then request these resources, specifying their preferred representation formats. The Web server or service responds by transferring the representation of the resource to the agent in the format that most closely satisfies the request. 424 CHAPTER 10 • Web Services The selection of the best representation is referred to as content negotiation. The agent then transitions to its next state based on the content of the received resource, which typically contains hyperlinks to other resources. The hyperlinks are then used for subsequent requests, which cause the agent to transition to a new state. This architectural style is referred to as Representational State Transfer (REST), a term coined in Chapter 5 of the Ph.D. dissertation Architectural Styles and the Design of Network-based Software Architectures [Fielding2000], by Roy Fielding. For example, consider League Planet. Its important concepts include leagues, schedules, games, teams, and locations. Each of these concepts is physically stored in a relational database and is identified by a unique number that acts as its primary key. This gives us a simple way to define URIs. Each row of the main entity tables corresponds to a URI. We create the URI by combining the table name and the primary key value; for example, http://www.leagueplanet.com/resources/game/42 identifies game number 42. There are a few other key ideas in Web architecture. One of the most important is the notion of hyperlinking. The representation of a resource will often contain links to other resources. An agent will typically follow these links to retrieve related information. In the context of Web services, this means that the messages exchanged will often contain references to other Web services. A full description of a Web serv- ice must also describe the interfaces of these references to other Web services. For example, it is not enough to know that the League Planet schedule Web service returns URIs to teams; it is also necessary to know that these URIs are in fact the endpoints of League Planet team Web services. Another key idea in REST is the notion of uniform interface, which means that there is a standard set of verbs or methods that can be used to access any resource. In HTTP, the most common methods are PUT, GET, POST, and DELETE, which roughly correspond to the Create, Retrieve, Update, and Delete (CRUD) operations on databases. In practice, most Web applications just use GET and POST. The proper use of GET has important performance benefits. GET should be used for operations that are safe, which means that they are idempotent and don’t incur any obligations. Idempotence means that the result of performing the operation twice is the same as performing it once. For example, in banking, getting your account balance is idempotent, but withdrawing money from it is not. An obligation could be something like having your account charged for the operation. Safe operations admit certain optimizations such as prefetching and caching. For example, a Web browser could prefetch linked pages and cache the results to improve response time and reduce network traffic. REST 425 Finally, let’s examine content negotiation. This is the mechanism by which an agent can specify the types of resource representation it prefers to receive in response to a request. For example, suppose a Web browser requests an HTML page. Part of the request is an HTTP Accept header that lists the image media types that the Web browser can render, with weightings that indicate its prefer- ences. When the Web application receives the request, it inspects the Accept header and generates a Web page with links to the image media type that best fit the Web browser’s preference. A similar mechanism can be used to specify the desired natural language of the response. Content negotiation applies also to Web services. For example, an AJAX client may prefer a response encoded as JSON as its first choice, then plain XML, and then finally SOAP, since this is the order that minimizes its parsing time. The client includes an Accept header in its requests indicating that it accepts these three media types and then assigns them suitable preferences. In this way, the AJAX client receives the response in the format that is most efficient for it to process if the Web service provides it, but can still function if the Web service pro- vides other acceptable formats. The nice thing about this architecture is that the Web service can be upgraded at a later date to improve performance and the clients will automatically benefit without any modification on their end. For example, suppose League Planet provides REST style Web services initially using plain XML, but then finds after reviewing the server logs that many clients prefer JSON. The service can then be upgraded to also provide JSON, and the existing clients will experience a performance boost without changing a line of their code. REST Style Web Services The REST architectural style is directly applicable to Web services. See Building Web Services the REST Way [Costello2002] by Roger Costello for an excellent description of this approach. Some vendors, such as Amazon, offer both SOAP and REST interfaces. The use of REST for Web services received a mindshare boost when, in the brief article “REST vs. SOAP at Amazon” [O’Reilly2003], Tim O’Reilly reported that Amazon was finding that 85 percent of their Web service usage was via the REST interface. This overwhelming preference for REST versus SOAP is undoubtedly due to the fact that the main use of the Amazon Web service is for providing product links on Web pages. Nevertheless, REST style interfaces are easier to use in this type of application and deserve to be given serious consideration when designing Web services in general. Now let’s briefly examine how well SOAP 1.1 and WSDL 1.1 align with REST principles. For starters, most SOAP 1.1 engines employ a single URL that acts like a router for service requests. The SOAP engine examines the request to 426 CHAPTER 10 • Web Services determine the operation and then invokes the service implementation associated with it. Furthermore, SOAP 1.1 over HTTP always uses POST, so all operations are treated as unsafe. WSDL 1.1 is not much better. In addition to the SOAP 1.1 binding, WSDL 1.1 defines two HTTP bindings, one for GET and another for POST. This means you cannot describe a service that has a combination of safe and unsafe operations. Nor can you always use the correct HTTP method for any given operation since PUT, DELETE, and so forth are not supported. Finally, WSDL 1.1 provides no way to describe messages that refer to other Web services, that is, no support for hyperlinking. So we see that SOAP 1.1 and WSDL 1.1 are somewhat REST-hostile. Nevertheless, these specifications do provide the basis for a large and rich set of additional specifications collectively referred to as WS-*. These include WS- Security, WS-Reliability, and WS-Addressing to name a few. The way to think about WS-* is that it defines a way to flow Web services messages over multi- ple transport hops involving a combination of protocols. For example, an enterprise Web service might receive a request over HTTP and then place it on a message queue. This is the domain of SOA. Although SOA is undoubtedly useful in many contexts, it is overkill in oth- ers. For example, suppose you want to build an AJAX client. You need to get XML data from somewhere. Why not use a Web service? In this situation, you’d like the XML to be very easy to process, so SOAP encoding is ruled out. Document/literal style is much more appropriate. But maybe XML is even too complex here. Perhaps JSON is a better representation. Still, this is program- matic access, and even though you are not using SOAP or even XML, you’d like a well-defined interface you can program to. Fortunately, the combination of SOAP 1.2 and WSDL 2.0 brings the world of Web services into much better alignment with REST architectural principles. SOAP 1.2 supports the use of GET for requests. WSDL 2.0 allows the descrip- tion of safe operations, has a much improved HTTP binding, and includes support for describing messages that refer to other Web services; that is, hyper- linking between Web services can be described. As we enter the so-called Web 2.0 technology era, we could see a unification of WS-* and REST style Web services based on SOAP 1.2 and WSDL 2.0. Overview of Iterations Enough theory. It’s time to write some code. In this chapter you’ll add Web services to the League Planet site in the following iterations: ❍ In Iteration 1 you develop a Web service that retrieves League Planet schedule information using the Top-Down approach. This means you Overview of Iterations 427 create the description of the Web service interface first using the XSD and WSDL editors, and then generate its Java skeleton using the Web service wizard. You fill in the implementation of the Web service by writing Java code that accesses the League Planet business logic tier. Finally, you test the Web service using the Web Services Explorer. ❍ In Iteration 2 you develop a Web service that updates the game scores using the Bottom-Up approach. This means you write Java code that accesses the League Planet business logic tier first, and then use the Web service wizard to deploy the Java code as a Web service and generate its WSDL. ❍ In Iteration 3 you create a Web client that uses the update Web service. You use the Web service wizard to generate a Java client proxy from the WSDL of the Web service and a JSP test client that uses the proxy. ❍ In Iteration 4 you test your Web service for interoperability. You use the TCP/IP monitor and the WS-I test tools to test your Web service for com- patibility with the WS-I profiles. ❍ In Iteration 5 you use your Web services in a Web application that displays schedules and updates game scores. The Web application accesses the Web services using Java client proxies. ❍ In Iteration 6 you use the Web Services Explorer to discover Web services in UDDI and WSIL registries. You also use the Web service wizard to publish WSIL documents that describe your Web services. Iteration 1: Developing Web Services Top-Down Top-Down development means designing the Web service interface first and then developing the implementation code. This approach yields the best interoperabil- ity because the underlying implementation details cannot “bleed through” into the interface. Top-Down development is required if the messages must use exist- ing industry or corporate standard XML document formats. To perform Top- Down development you need to have XSD and WSDL design skills. Luckily, WTP has two great editors that make this task easier. In this iteration, you’ll perform the following tasks: 1. Use the XSD editor to describe the League Planet schedule format. 2. Use the WSDL editor to describe a Web service for querying schedules. 3. Use the Web service wizard to generate a Java skeleton for the service and deploy it to the Axis SOAP engine running on Tomcat. 428 CHAPTER 10 • Web Services 4. Fill in the implementation of the Java skeleton by accessing the League Planet business logic tier. 5. Use the Web Services Explorer to test the schedule query service. XSD XML Schema Description (XSD) is the W3C Recommendation for describing the format or schema of XML documents, and is the preferred schema descrip- tion language for use with Web services. XSD is far more expressive than its predecessor, DTD, and, like many specifications produced by industrial collab- orations, is extremely feature rich. Fortunately, only a small portion of the XSD language is needed in practice to describe typical Web service messages. For an easily digestible overview of XSD, see Chapters 8 and 9 of Essential XML Quick Reference [Skonnard2002] by Aaron Skonnard and Martin Gudgin. The definitive sources of information about XSD are, of course, the W3C specifications themselves. The best way to get started is to read XML Schema Part 0: Primer [XSD10-Part0], which gradually introduces all the major con- cepts and illustrates them using simple examples. The remaining parts, XML Schema Part 1: Structures [XSD10-Part1] and XML Schema Part 2: Datatypes [XSD10-Part2], provide normative definitions of the schema constructs and type system, but are very difficult to read. They are intended for people who need to build software that processes XSD. However, you might need to refer to these specifications in order to understand error messages produced by XSD proces- sors. Be warned, though, this task is not for the faint-hearted. WTP has a powerful XSD editor that includes both a source and a graphical view as well as an outline view and property sheets that greatly simplify the edit- ing task. However, don’t let the power of the XSD editor tempt you into using all the features of XSD when you design your Web service messages. You should keep the design simple to ensure that developers can understand it and that it will be consumable by the widest possible set of Web service toolkits. The initial toolkit support for the more exotic features of XSD was somewhat patchy, but the situation has steadily improved over time. To create the schema for the League Planet schedule, do the following: 1. Create a new dynamic Web project named IceHockeyService to contain the Web service (see Figure 10.1). 2. League Planet has an XML format for schedules. Import IceHockeyService/schedule.xml Iteration 1: Developing Web Services Top-Down 429 430 CHAPTER 10 • Web Services Figure 10.1 New Dynamic Web Project—IceHockeyService Example 10.1 Listing of schedule.xml <?xml version="1.0" encoding="UTF-8"?> <schedule scheduleId="1" xmlns="http://leagueplanet.com/resource/schedule" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://leagueplanet.com/resource/schedule schedule.xsd"> <name>2005-2006 Regular Season</name> <league leagueId="1"> <name>Rosehill Girls Hockey League</name> </league> <games> <game gameId="1"> <dateTime>2006-01-07T19:00:00-05:00</dateTime> <arena locationId="1"> <name>Hillview High School</name> <timeZone>Canada/Eastern</timeZone> </arena> <visitor teamId="1"> <name>Ladybugs</name> </visitor> for an example instance document (see Example 10.1). Your goal is to describe this format using XSD. <home teamId="2"> <name>Vixens</name> </home> <score> <visitor>3</visitor> <home>7</home> </score> </game> . . . <game gameId="7"> <dateTime>2006-01-22T19:30:00-05:00</dateTime> <arena locationId="2"> <name>Maple Community Centre</name> <timeZone>Canada/Eastern</timeZone> </arena> <visitor teamId="3"> <name>Snowflakes</name> </visitor> <home teamId="2"> <name>Vixens</name> </home> <score> <visitor>2</visitor> <home>6</home> </score> </game> </games> </schedule> Note that in this format, the XML attributes are given names like scheduleId and gameId instead of id, which is the name of the corresponding property in the Java model. The reason is that the XML attribute id is often used to represent a unique identifier for elements within an XML document, which is not the case here. We therefore use different names to avoid confusion. Also note that this XML format differs from the format you used earlier (see Example 7.9 in Chapter 7). Here you have refined the format to take advantage of the XSD type system. The date and time information is represented using the standard XSD date format instead of a pair of textual strings. The score infor- mation is represented using a pair of XSD integers instead of combined into a textual string. By using built-in XSD types, you are letting the XML parsers and validators do more work for you. You are also giving more precise information about the format of schedules to users of your Web service. 3. Create a new XML Schema file named schedule.xsd in IceHockeyService ( see Figure 10.2). Iteration 1: Developing Web Services Top-Down 431 432 CHAPTER 10 • Web Services Figure 10.2 New XML Schema File—schedule.xsd 4. In general, there are many equivalent ways to describe a given format using XSD. For Web services, it’s a good practice to describe formats in a way that works well with XML data binding toolkits such as JAX-RPC and JAX-WS. Define complex types for the content model of each element. The XSD editor lets you edit in the source tab, the graphical tab, the out- line view, and the property view. Try to develop schedule.xsd yourself. Import IceHockeyService/schedule.xsd before proceeding (see Example 10.2). Example 10.2 Listing of schedule.xsd <?xml version="1.0" encoding="UTF-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://leagueplanet.com/resource/schedule" xmlns:tns="http://leagueplanet.com/resource/schedule" elementFormDefault="qualified"> <element name="schedule" type="tns:ScheduleType" /> <complexType name="ScheduleContent"> <sequence> <element name="schedule" type="tns:ScheduleType" /> </sequence> </complexType> <complexType name="ScheduleType"> <sequence> <element name="name" type="string" /> <element name="league" type="tns:LeagueResourceType" /> <element name="games" type="tns:GamesType" /> </sequence> <attribute name="scheduleId" type="long" /> </complexType> <complexType name="LeagueResourceType"> <sequence> <element name="name" type="string" /> </sequence> <attribute name="leagueId" type="long" /> </complexType> <complexType name="LocationResourceType"> <sequence> <element name="name" type="string" /> <element name="timeZone" type="string" /> </sequence> <attribute name="locationId" type="long" /> </complexType> <complexType name="TeamResourceType"> <sequence> <element name="name" type="string" /> </sequence> <attribute name="teamId" type="long" /> </complexType> <complexType name="GamesType"> <sequence> <element name="game" type="tns:GameType" minOccurs="0" maxOccurs="unbounded" /> </sequence> </complexType> <complexType name="GameType"> <sequence> <element name="dateTime" type="dateTime" /> <element name="arena" type="tns:LocationResourceType" /> <element name="visitor" type="tns:TeamResourceType" /> <element name="home" type="tns:TeamResourceType" /> <element name="score" type="tns:ScoreType" /> </sequence> <attribute name="gameId" type="long" /> </complexType> Iteration 1: Developing Web Services Top-Down 433 [...]... Iteration 1: Developing Web Services Top-Down Figure 10.8 WSDL Editor Graph Tab—query.wsdl Figure 10.9 WSDL Editor Outline View—query.wsdl 439 440 CHAPTER 10 • Web Services Deploying Web Services WTP provides a Web service wizard to simplify the task of deploying Web services In the Top-Down approach, the WSDL document is used to define a Java server skeleton that implements the Web service The Java server... about the Web service Ant tasks The Web service wizard: 1 installed the Axis SOAP engine in your dynamic Web project, 2 generated the Java bean skeleton for your service, and lots of Java XML data binding classes in the src folder, 3 copied query.wsdl to WebContent/wsdl/QuerySOAPPort.wsdl and set its endpoint address to your Web application (it also copied schedule.xsd), Iteration 1: Developing Web Services... anywhere else on the Web The Web Services Explorer is itself a Web application It runs in the embedded servlet container that Eclipse uses for displaying Help The Web Services Explorer uses servlets and JSPs to generate its user interface, like any other Java Web application, but it is also integrated with Eclipse and can access the contents of your workspace Do the following to test your Web service: 1... location.getId()); } } Testing with the Web Services Explorer At this point the Web service is ready to test, and you will test it using the Web Services Explorer The Web Services Explorer lets you test Web services without writing or generating any code The Web Services Explorer accomplishes this by dynamically interpreting the WSDL for the Web service You can test Web services that are deployed on your... IceHockeyService/WebContent/wsdl/QuerySOAPPort.wsdl and execute the command Web Services ᭤ Test with Web Services Explorer The Web Services Explorer will start and open a new Web browser in the editor area (see Figure 10.21) View QuerySOAPPort.wsdl in the Web Services Explorer The Web Services Explorer user interface consists of three panes named Navigation, Action, 452 CHAPTER 10 • Web Services and... Web Services Explorer You’re now ready to design another Web service in iteration 2 using the Bottom-Up approach Iteration 2: Developing Web Services Bottom-Up The Bottom-Up approach to Web service development begins with creation of a Java service class The methods of the class define the operations of the Web service Iteration 2: Developing Web Services Bottom-Up 455 The argument lists and return... Iteration 1: Developing Web Services Top-Down Example 10.5 Listing of Query .java /** * Query .java * * This class implements the query Web service * * @author Arthur Ryman */ package com.leagueplanet; import import import import import java. util.Arrays; java. util.Comparator; java. util.Iterator; java. util.Set; java. util.Vector; import import import import import import import import import import import... until the server starts, and then click Next The Web service is now deployed Finally, the wizard lets you publish the WSDL to UDDI (see Figure 10.16) Just click Finish Figure 10.14 Web Service Skeleton Java Bean Configuration Figure 10.15 Web Service Wizard—Server startup page 443 444 CHAPTER 10 • Web Services Figure 10.16 Web Service Publication Steps the Web Service Wizard Performed You probably noticed... installed Tomcat and added it to WTP Select query.wsdl and execute the command Web Services ᭤ Generate Java bean skeleton This command launches the Web service wizard (see Figure 10.10) Pull the Web service slider up to the Start service position Figure 10.10 Web Service Wizard—Top-Down Development Iteration 1: Developing Web Services Top-Down 441 2 Since you selected query.wsdl when you started the... Iteration 1: Developing Web Services Top-Down 445 4 created the Axis deployment descriptor WebContent /WEB- INF/ server-config.wsdd, 5 created a couple of handy Axis files to deploy and undeploy your Web service in a subfolder of WebContent /WEB- INF, and 6 started Tomcat to make your Web service available To verify that the Web service is actually deployed and running, do the following: 1 Use the Project Explorer . the Web service by writing Java code that accesses the League Planet business logic tier. Finally, you test the Web service using the Web Services Explorer. ❍ In Iteration 2 you develop a Web. its WSDL. ❍ In Iteration 3 you create a Web client that uses the update Web service. You use the Web service wizard to generate a Java client proxy from the WSDL of the Web service and a JSP test client. services in a Web application that displays schedules and updates game scores. The Web application accesses the Web services using Java client proxies. ❍ In Iteration 6 you use the Web Services