Tài liệu Java Testing and Design- P6 pptx

Web Service Scalability Techniques 229

parameters, and data types used to make a SOAP request and receive a

response. WSDL is machine parsable and enables development tools and

application servers to generate program source code.

SOAP provides better extensibility and reduces brittleness over XML￾RPC by introducing the many extra layers of the SOAP stack described in

Figure 7–2. However, with greater flexibility comes a greater possibility of

incompatibility and scalability problems.

Web Service Scalability Techniques

SOAP and WSDL-based Web services use a multistep process to complete a

transaction. Many techniques and system architectures attempt to improve

Web service scalability and performance. Understanding these techniques is

important to validate the results in a test.

The Web service request often begins with business logic of your applica￾tion learning the method and parameter to call from a WSDL document. As

an example, here is part of the WSDL for a publicly available Web service

that returns the current weather for a U.S. postal zip code.

<message name = "getTempRequest">

<part name = "zipcode" type = "xsd:string"/>

</message>

<message name = "getTempResponse">

<part name = "return" type = "xsd:float"/>

</message>

The weather service requires you to call the getTempRequest method by

passing in a zipcode value as a string and receiving the temperature as a float￾ing-point value in the response.

Since the WSDL rarely changes, many developers embed the WSDL def￾inition into their code to avoid the overhead of getting the WSDL every time.

While this will improve performance, it also works against solving brittleness

and becomes a maintenance headache when the WSDL eventually changes.

The better way to avoid maintenance problems is to cache the WSDL in the

centralized database and then periodically check the timestamp/version

number of the WSDL to see if a newer one is available.

Another way for software developers to try to improve performance is to

turn XML validation off. For systems that do no use validation, test suites

PH069-Cohen.book Page 229 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

230 Chapter 7 Tuning SOAP and XML Web Services

should use light validation of the response results. For example, this WSDL

defines the schema for the response:

<element name="zipcode" type="int"/>

<element name="temperature" type="float"/>

<element name="remarks" type="string"/>

The result of a call to this service looks like this:

<zipcode>95008</zipcode>

<temperature>65 F</temperature>

<remarks>Storm warning</remarks>

This response should throw an exception because the temperature value is

not a float type. It is actually a string. Validating the response in an intelligent

test agent will normally be much faster than depending on the DTD or XML

Schema code to validate the SOAP response.

Parameter types in SOAP present a possible scalability problem too. SOAP

defines simple data types: String, Int, Float, and NegativeInteger. The simple

data type such as a String appears in WSDL using XML Schema like this:

<message name = "getTempRequest">

<part name = "zipcode" type = "xsd:string"/>

</message>

As we will see later in this chapter, the SOAP request and response may

include non-trivial new data types. For example, imagine the temperature

Web service also retrieved maps. The schema for the call may look like this:

<message name = "getTempRequest">

<part name = "zipcode" type = "xsd:string"/>

</message>

<message name = "getTempResponse">

<part name = "return" type = "xsd:float"/>

<part name = "map" type = "xsd:http://www.pushtotest.com/

wsdl/mapformat"/>

</message>

While reading the response, a validating XML parser will contact the

pushtotest.com host to get the XML Schema definition for the mapformat.

The overhead of this request can cause scalability problems when the validat￾ing parser does not cache the schema definitions.

PH069-Cohen.book Page 230 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Web Service Interoperability Problems 231

A general performance rule is to stay with the simple SOAP data types

unless there is a compelling need to use another data type. Each new data type

introduces a serializer to convert from the XML value into the local program￾ming language (Java, C, C++, and Visual Basic) value and back again. The seri￾alizer may cause performance problems or just be buggy. For example, the

Apache and Microsoft SOAP implementations both include a BigDecimal data

type. However, prior to Java 1.3 and .Net 1.2 the two are not compatible.

While SOAP was designed to work within existing Web application envi￾ronments, the protocol may introduce firewall and routing problems. Unlike

the normal Web server using HTTP, SOAP messages using HTTP as a trans￾port are the equivalent of HTTP Form Submits. The calls move much more

data than the average HTTP GET or POST. This is bound to impact network

performance. Special testing of the firewall and routing equipment should be

undertaken. For example, it is prudent to check your firewall’s security policy

to make certain it does not monitor SOAP requests as Web traffic. If it does

you may find the firewall shunting away traffic that looks like a Denial of Ser￾vice (DOS) attack.

The early Web services are very straightforward: you make a SOAP call

and get a response. More advanced SOAP applications make a series of get

and response calls until a transaction is finished. Transactional SOAP calls

need to identify sessions and cache the state of the sessions. Caching mecha￾nisms for SOAP transactions are potential problem spots for scalability.

Web Service Interoperability Problems

Stepping onto the new Web services island, one might think your problems

are behind you. Then the reality of Web services sets in. Dozens of platform

providers, independent software vendors, and utility software developers have

implemented SOAP and WSDL in their products. Many times developers

have had to interpret the meaning in parts of the specifications. Interpretation

allows interoperability problems to seep into SOAP-based Web services.

Web service interoperability goals are to provide seamless and automatic

connections from one software application to another. SOAP, WSDL, and

UDDI protocols define a self-describing way to discover and call a method in

a software application, regardless of location or platform. Data is marshaled

into XML request and response documents and moved between software

packages using HTTP or message-based protocols. Interoperability prob￾PH069-Cohen.book Page 231 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

232 Chapter 7 Tuning SOAP and XML Web Services

lems, such as platform-specific differences in BigDecimal, creep-in at the

discovery, definition, and request/response mechanisms.

Discovery

In the dreamy world of Web Service Utopia, every software application is

coded with a self-discovery and self-categorization method. Software that

lacks a needed function looks into a UDDI-based registry of services and

automatically makes a contract with a found Web service to handle the task.

WSDL and SOAP enable communication once a Web service function is

found. The problem then is to categorize what the function does so it may be

found. UDDI defines TModels that are taxonomies to describe the location,

path, and character of the function.

UDDI enables businesses to host online registries of available Web ser￾vices. On the public Internet, Microsoft, HP, and IBM offer UDDI registries

to businesses. A business uses the UDDI TModel system to categorize the

hosted Web service. And therein lies the problem: UDDI allows multiple

taxonomy and expects self-policing for mistaken entries in the registry. For

example, suppose a Web service that prints and sends invoices lists itself in a

UDDI registry using an SIC code but does not list geographic information.

Using such a Web service from the other side of the planet would work; how￾ever, it may be easier to lick the stamp yourself.

In time UDDI will be well used and understood by the traditional taxon￾omy providers, including LCSH (Library of Congress Subject Heading),

FAST (Faceted LCSH), DDC (Dewey Decimal Classification), and LCC

(Library of Congress Classification). Until the taxonomy experts add their

practical knowledge of developing and maintaining public directory struc￾tures in UDDI, you should plan for interoperability problems.

On the other hand, private UDDI directories are already viable. Enter￾prises have spent billions of dollars renovating their supply-side systems.

With these renovations comes standardization of product definitions and

business processes. These processes can be easily moved into a UDDI regis￾try and accessed from UDDI-enabled Web services.

Definition

Web services uses WSDL to define how to make a request to a SOAP-based

method. WSDL assumes cooperation from companies that define custom

data types. Such cooperation is put to the test by collaborative organizations

that are establishing interoperability test suites. SOAPBuilders is a loose affil￾PH069-Cohen.book Page 232 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Web Service Interoperability Problems 233

iation of Web service vendors whose goal is to proof interoperability. SOAP￾Builders also publishes an interoperability test suite for checking SOAP

implementations that is available at http://www.xmethods.com/ilab/ and http://

www.whitemesa.com/interop.htm. The test suites emerging today begin with

the WSDL definition of a SOAP interface. They test the contents of the

request and response documents for valid data.

This has put renewed energy behind WSDL efforts. New technologies,

such as Cape Clear CapeStudio and BEA WebLogic Workshop, automati￾cally develop WSDL documents for SOAP-based Web services. Tools like

these eliminate poorly constructed WSDL that appears when developers

hand code WSDL documents. Plus, Java itself is getting much better at han￾dling WSDL in the Java Web Services Developer Package. Details are at

http://java.sun.com/webservices/.

<?xml version="1.0" ?>

<definitions name="PushToTestService" targetNamespace

="http://www.pushtotest.com/pushtotestservice.wsdl">

<message name="testRequest">

<part name="userName" type="xsd:string" />

<part name="authenticationToken" type="xsd:string" />

<part name="goodUnitl" type="xsd:Date" />

</message>

...

WSDL documents have been known to cause interoperability problems.

For example, consider the above snippet of WSDL for a software test Web

service. The WSDL defines how to send a testRequest command; however,

the <definitions> element fails to define the name space. The correct <defi￾nitions> element should look like this:

<definitions xmlns:s="http://www.w3.org/2001/XMLSchema"

xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"

xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"

xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:s0="http://tempuri.org/" targetNamespace="http://tem￾puri.org/" xmlns="http://schemas.xmlsoap.org/wsdl/">

The developer likely thought the Web service would default to the stan￾dard W3 SOAP name space. While this may work for primitive data types like

String, there are known interoperability problems with Date data types that

PH069-Cohen.book Page 233 Monday, March 15, 2004 9:00 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.