Xml programming bible phần 8 ppt

As a testament and/or aresponse to this, Microsoft, IBM, and a few smaller players have released UDDISDKs, which make developing Web Service front-ends to UDDI registries moreaccessible

Figure 25-2: An example of a WSDL editor

Because WSDL is good old XML (can “old” be associated with XML yet?), you canalso create your own WSDL editor It could be fun

Summary

In this chapter, we have dissected a WSDL file We saw how the file is structuredand what information is included therein We discovered what the elements ofWSDL mean and how they are used by the calling application to determine a Webservice’s behaviors and characteristics WSDL is arguably the de facto standard onthe Internet for making known to consuming client applications what a Web servicedoes We also learned about how to dynamically create a Web service proxy class atruntime based on WSDL that is not known at design time Finally, we learned thatthere are some WSDL editors out there and that one can be created from scratch ifdesired

Web services can be used for interaction between

remote systems within a single organization

However, one of the most promising aspects of Web services

is that they can be used business-to-business integration Forexample, one company might expose an invoicing Web servicethat the company’s suppliers use to send their own internalinvoices Similarly, a company might expose a Web service forplacing orders electronically, using special schemas that thecustomers can use internally for their own purchasing pro-cess Now, if one company wanted to purchase goods from avendor using a service of this kind, how would it find it? Let’ssay the company wants to begin ordering office supplies from

a John’s International Office Supplies (an idea waiting to pen) it would need to search for all vendors who sell officesupplies over the Internet and then find ones that sell goodsusing a Web service

hap-To do this, the customer needs a directory, a sort of yellowpages-type directory of all businesses that expose Web ser-vices This directory is called Universal Description, Discovery,and Integration or UDDI UDDI is an industry effort started inSeptember of 2000 by Ariba, IBM, Microsoft, and 33 other com-panies Today, UDDI has over 200 community members

This chapter describes UDDI, the final piece of the WebService puzzle, in greater detail It explains how UDDI linkstogether consumers of Web services with providers and how

it works We also learn who is backing the UDDI effort andwhat UDDI means to the future of Web services We learn howUDDI works and what it means with respect to the technology

of Web services

UDDI Structure

UDDI is a platform-independent framework for describing vices, businesses, and integrating business services Whilethe UDDI project is not part of a regular standards body likethe W3C or the IETF, the structure of UDDI is based on Web

ser-26C H A P T E R

In This Chapter

UDDI architectureUDDI todayInformation modelBusinessesServicesBindingsTmodels

service standards, which means that UDDI registries are theoretically accessiblethrough the same means as all other Web services In short, UDDI is a directory forWeb services, and it is a Web service Currently IBM, Microsoft, SAP, and NTTTelecom host public versions of the UDDI directory, which are kept in sync via aform of replication URLs for registry sites as well as the latest version of the UDDIspecification can be found at http://uddi.org/ Like a typical yellow pagesdirectory, UDDI provides an indexed database of businesses searchable by the type

of business

Finding Web services with UDDI

Each of the four public UDDI Registries (IBM, Microsoft, SAP, and NTT) has its owninterface and UI to access its registry via the Web You typically search using busi-ness taxonomy such as the North American Industry Classification System (NAICS)

or the Standard Industrial Classification (SIC) You could also search by businessname or geographical location Regardless of the interface provided, the UI is noto-riously hard to navigate for Web developers that are used to more user-friendlyHTML search sites However, like WSDL, the main users of the UDDI registries areintended to be Web services rather than developers As a testament and/or aresponse to this, Microsoft, IBM, and a few smaller players have released UDDISDKs, which make developing Web Service front-ends to UDDI registries moreaccessible to anything on the other end of the SDK, be it human or machine.Microsoft SDKs can be downloaded at http://uddi.microsoft.com/, and theIBM UDDI4J can be downloaded as part of the IBM Web Services toolkit fromhttp://alphaworks.ibm.com/tech/webservicestoolkit

These tools, and a few others, can also be used to set up private UDDI servers foruse within an organization or via VPN, for groups that want to have the full benefits

of a complete set of Web Services technologies, but don’t want to share their WebServices with the world on one of the public sites

Going back to our example of office supplies, a company could search UDDI forNAICS code 422120, which corresponds to providers of office supplies and papergoods This search would return a list of such companies that are registered withUDDI At this stage of Web service adoption, it is not uncommon to find no Web ser-vices for categories you search in UDDI This does not mean, however, that no Webservices exist for that category of business It only means that none is registeredusing UDDI In searching, the consumer will need to know which of the office sup-plies vendors exposes Web services that are compatible with the systems usedwithin the company For example, if our company supports a specific purchaseorder process that uses SOAP-based Web services for acquiring office supplies itwould need to know which vendors have a Web service that is compatible

This brings us to the taxonomic conventions of UDDI There are a number of ent types used in the UDDI model to identify a service or collection of services.

differ-These five types are shown in Figure 26-1

Figure 26-1: The types used in the UDDI taxonomy

publisherAssertion

To understand how they work together, let’s look at UDDI from the perspective of

an organization that wants to publish its services in the UDDI registry In this case,

we will imagine a company that has many subdivisions within its organization Therecommended practice for a business of this type that wants to register in a UDDIregistry is for each division to register as a separate businessEntity For exampleMicrosoft may have a separate businessEntity entry for the Windows OS, Officedivisions, and gaming division Thus, rather than provide a single businessEntityentry in the UDDI registry which attempts to describe all the services Microsoftprovides, it makes more sense to have each division submit a separate

businessEntity that the division can support and maintain However, it would beadvantageous if the relationship between the different services offered byMicrosoft’s different businessEntity entries could be made known in UDDI This isdone through what is known as a publisherAssertion structure, which allows busi-nesses to publish relationships between businessEntities To prevent one publisherfrom claiming a relationship to another that is not reciprocated, both publishersmust publish identical assertions for the relationship to become known Theallowed relationships are peer-to-peer A peer-to-peer relationship is one where thetwo businessEntity structures are related as peers, and a parent-child relationship

is hierarchical Next, let’s look at the businessEntity

businessEntity

publisherAssertionbindingTemplate

A businessEntity is simply the provider of a service, a businessService There is not

a lot to the structure of a businessEntity Primarily, it contains:

✦ Name of the provider

✦ Description of the businessEntity

✦ Contact information, such as name, phone, fax, e-mail, and so on

✦ Identifiers: Classifiers for the business using specifications like DUNS, NAICS,

or SIC

As mentioned before, a businessEntity may not necessarily be a separate business

or organization There is nothing in the specification to prevent a large business (orsmall one for that matter) from having divisions register services with UDDI usingseparate businessEntity entries A businessEntity is described using a well-formedXML document and is created by someone who represents the provider of the ser-vice UDDI specifies a schema for structuring the information in the businessEntityentry In short, the businessEntity describes who is providing a businessService

businessService

This data structure is used to describe each offered service in business terms Youhave to specify at least a name and one binding template A single businessServicemay contain more than one binding template, but it must contain at least one.Listing 26-1 shows some of the XML content of a businessService entry

Listing 26-1: A View of Some of the Elements in a

businessService Entry

<businessService serviceKey=” ”>

<name> SymbolService </name>

<description>Description of the service here</description>

<bindingTemplates>

<bindingTemplate>

<accessPointurlType=”http”>

As you can see here, the core of the businessService entry is the binding template.

A binding templates structure serves as a container for one or more binding plate structures A binding template structure describes how to get access to a ser-vice They contain what are known as access points, which are usually just URLs

tem-Valid values for an accessPoint element are:

tModels

Each business registered with UDDI lists all its services and gives each of these vices a type This service type has a unique identifier (GUID-style number) andcomes from a group of well-known service types that are registered with UDDI

ser-These service types are called tModels (technology models) Let’s recall that thetwo primary goals of UDDI are to:

✦ Make it possible to describe a Web service, and make that description ingful for searches

mean-✦ Provide a way to make these descriptions useful enough so consumers caninteract with a service without needing to know its inner workings

This being so, we need a way to tag the service so others can easily know its iors, the standards with which it is compliant, and so forth All of the other types

behav-we have seen up to this point (publisherAssertion and so on) relate to who owns,publishes, describes, and maintains the Web service A tModel is concerned withthe service itself A tModel makes it possible to describe compliance with a specifi-cation, concept, standard, or a collectively shared design The first goal is met byusing tModel as a namespace or categorization, while the second goal is met by itsusage as a tag that is technically recognizable

Each tModel has a name, description, and the unique identifier This unique identifier is a UUID and is called the tModelKey For example, the tModelKeyuuid:d819efe0-4471-11d6-9b35-000c0e00acdd identifies the tModel called uddi-org:http, which has the description “An HTTP or Web browser-based Web service.”

By having a pool of well-known service types, UDDI makes it possible to find outhow to do electronic business with a company This is the primary advantage UDDIhas compared to other Web-based business directories

As part of the registration process, registrants can use an existing tModel or theycan create their own It might make sense for an organization or a group of organi-zations to develop their own tModels to classify a service they all offer (competi-tively even), but that would make it easier for potential consumers of the service tofind the group of vendors who offer a certain type of service For example, packagedelivery companies (UPS, FedEx, Airborne Express, USPS, and so on) may decide toagree upon a mutual standard tModel for package tracking This tModel wouldbehave in the same way for all shippers, the same method names with the sameparameters

tModels store information that includes:

✦ The name of the model

✦ The publisher of the model

✦ The categories that describe the service type

✦ Pointers to related technical specifications, interface definitions, message mats, message protocols, security protocols, and other details that wouldhelp a potential consumer of the service be able to use it

for-Listing 26-2 shows an example of a tModel fully exposed Notice how it uses the reference to a WSDL document as an identifier for what the service does (seeChapter 25 for more on WSDL)

Listing 26-2: An Example of a tModel

<tModelauthorizedName=” ” operator=” ”

More information on UDDI and links to public servers and tModels can be found

at http://uddi.org/

As of this writing, the current public servers include:

✦ uddi.microsoft.com – Microsoft’s UDDI Business Registry Node

✦ uddi.ibm.com – IBM’s UDDI Business Registry Node

✦ uddi.sap.com – SAP’s UDDI Business Registry Node

✦ www.ntt.com/uddi – NTT Com’s UDDI Business Registry Node

UDDI APIs

To ensure most platforms can access UDDI’s services, the UDDI directory exposes abunch of APIs in the form of a SOAP-based Web service There are currently twomain nodes that expose the UDDI Web service: http://uddi.microsoft.com/inquireand http://www-3.ibm.com/services/uddi/inquiryapi The API is con-cerned with registering and discovering Web services

You can download the API specification from the following link: http://www.uddi

org/pubs/ProgrammersAPI-V1.01-Open-20010327_2.pdf

The APIs are accessed only through SOAP messages with the appropriate body tent For example, to search for a company called XYZ Industries you would sendthe XML in the body of a SOAP message as shown in Listing 26-3

con-Note Note

Listing 26-3: Finding a Business Using UDDI

<find_business generic=”1.0” xmlns=”urn:uddi-org:api”>

an API, is not concerned with it is actually accessed Any vendor can create classlibraries that call the API to interact with UDDI Listing 26-4 shows how theresponse is received from the previous inquiry using the tModel in Listing 26-3.Notice how the request and the response are all in SOAP, the bedrock dependency

of anything related to UDDI

Listing 26-4: The SOAP Response from a UDDI Request

<?xml version=”1.0” encoding=”utf-8”?>

<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”

Because the UDDI is really just a collection of SOAP calls through a Web service, wemust use classes that wrap the Web service and provide calls You can write yourown classes to do so if you wish While there may be some compelling reasons fordoing so out there in the universe, chances are that the reasons are not ones youwill stumble upon very easily It is probably a better idea to use some that havealready been created for you Microsoft and IBM are the most prominent leaders inthe UDDI realm, and both have provided SDKs to interact with UDDI via SOAP.

The Microsoft UDDI SDK

Microsoft has created classes that work directly with the UDDI APIs forsending/receiving SOAP messages These classes are well documented and comewith samples You can download the Microsoft UDDI SDK from http://msdn

microsoft.com/UDDI The links change every now and then, but you can pokearound a little and find the SDK pretty easily When you download the SDK, you willsee that there are both COM-based and NET-based components that let you searchthe UDDI registry as well as publish to it

To show you how to use the UDDI SDK, let’s take a look at the SDK sample Themain form of the sample is shown in Figure 26-2 Submitting the information in thesearch form will bring back a result from Microsoft’s UDDI registry

Figure 26-2: The main form of Microsoft’s

UDDI SDK sample with a search result

Now, let’s see how the code works that makes the request in Listing 26-5 You willquickly notice how simple things are compared to the full SOAP requests we haveseen elsewhere Here, a class, FindBusiness, is used to go get businesses that matchthe search criteria All of the plumbing and complexity is hidden.

Listing 26-5: Searching Using the Microsoft UDDI Classes

searchResults.BeginUpdate();

FindBusiness fb = new FindBusiness();

fb.Names.Add(name.Text ;try

{//

// Perform search//

BusinessList bl = fb.Send();

searchResults.Nodes.Clear();

foreach(BusinessInfo bi in bl.BusinessInfos){

searchResults.Nodes.Add(new TreeNode(bi.Name));

}}

Summary

Leveraging UDDI means that businesses can publish their Web services and findother Web services that they need UDDI is a nonproprietary standard that usesXML, SOAP, and HTTP to make the registry maintainable and accessible on the Web

In this chapter, we learned about the different data types that UDDI uses to let nesses register their Web services and to find other Web services Whether forcommercial or internal uses, you can program directly against the UDDI API Thiswould take place in the form of SOAP requests and responses However, other com-panies are already providing nice class libraries that leverage UDDI behind thescenes and that let you focus on developer productivity rather than the plumbing

busi-of UDDI

Microsoft Web Services

If you have read the other chapters in this book about Web

services, then you have often seen Microsoft mentioned asone of the biggest champions of the Web services paradigm

The fact is that Microsoft has been promoting Web servicesand remote component-based interaction using independentstandards from the very start It is worth noting that somehave expressed a measure of surprise that Microsoft has been

so enthusiastic about a technology that is platform-agnosticand based on standards that Microsoft does not own or con-trol the way it does COM or the way Sun controls Java APIs

Microsoft NET technologies are a huge reason why Microsoft

is so excited about Web services, a subject that is handledmore specifically in Chapter 29

This chapter will help readers understand Microsoft’s ogy toolkit for creating and consuming Web services using itsCOM-based technologies Without question, Microsoft’s pri-mary focus for Web services development is with NET

technol-However, Microsoft recognizes that not all companies can orwill migrate to NET at the drop of a hat Adoption cycles forsome organizations can take years On the other hand, organi-zations who have a large body of COM-based applications donot want the Web services train to pass them by Therefore,there must be a non-.NET way for Windows applications totake advantage of Web services technologies

The primary COM-based vehicle for Web services is contained

in the MS SOAP Toolkit This chapter will describe howMicrosoft has implemented its strategy in technologies that

do not fall directly within the NET initiative We will look atversion 3.0 of the MS SOAP Toolkit, a COM-based collection ofcode and documentation for working with SOAP in COM-based applications We will also explore the Office XP WebServices toolkit, a clever Addin that lets Office applicationsconsume Web services in productivity applications, all using

MS SOAP under the hood

WSMLThe Office XP WebServices Toolkit

The Microsoft SOAP Toolkit

Most of the focus with respect to Web services in the Microsoft world is on related technologies However, there are still myriad applications that are written inCOM-based code, and most of these will be around for years to come As exciting asthe NET initiative is, it is important that non-.NET Windows applications need to beable to connect to Web services Recall that in order for an application to communi-cate using SOAP (the protocol that specifies how requests and responses are struc-tured and passed between the client and the Web service) it must have the ability

.NET-to understand XML and communicate over some transport pro.NET-tocol (normallyHTTP) Because XML is used to package messages between the client and Web ser-vice, both parties in the relationship must package the messages in XML using acertain structure, and some mechanism must be able to both do the packaging andprocess packages that are received The Microsoft SOAP Toolkit has these ingredi-ents so that COM applications can both expose and consume Web services

What’s in the SDK

The MS SOAP Toolkit is an SDK you can download from the Microsoft Website as afree download After downloading and installing, you will see four main directories.They are:

✦ Binaries: Contains the executables and other files that are used by some of

the utilities for use with COM-based SOAP

✦ Documentation: Contains a pretty nice chm file chock-full of overview and

detailed information about how to program with the SDK

✦ Inc: Contains a single include file you can use if you are programming with the

SDK in C++

✦ Lib: A C++ inline file containing definitions of inline functions, as well as

tem-plate function definitions

As discussed in Chapter 24, SOAP is an XML-based standard for describing objectsthat are used to make calls and responses in Web Services over HTTP In the end,SOAP is just the grammar for describing remote component calls Fortunately, XML

is syntactical language for such descriptions When a client makes a call to a Webservice, the request must be structured in a specific way While an ambitious devel-oper could create a custom component to assemble the request in the correct hier-archy with the correct XML syntax so that the call is intelligible to the remotecomponent, it would be much more convenient to have one that everyone using thesame development platform can share MS SOAP is that ready-to-use library forpackaging up SOAP requests and responses for COM-based applications The MSSOAP Toolkit has everything that a COM developer needs to get up and runningwith Web services on Windows

Not surprisingly, the MS SOAP 3.0 relies heavily on MSXML 4.0 Earlier releases ofthe Toolkit used earlier XML parser versions, but, if you do not have legacy applica-tions that require previous MS SOAP versions, it is recommended that you uninstallthe older version and go ahead with a clean installation of version 3.0 You mustalso have Microsoft Internet Explorer 5.01 or greater installed whether you are run-ning MS SOAP on the client or server From a server perspective, you need IIS 5.0 orgreater if you are running Windows 2000, Windows XP, or Windows NET Server Ifyou are still running Windows NT 4.0, you will need IIS 4.0 or greater You will needIIS installed because (forgive the declaration of the obvious here, but it does per-haps merit emphasis) Web services are, after all, Web applications Therefore, theremust be some service to listen for Web requests and then send back the responses.

From a client perspective, you need Microsoft(r) Windows(r) XP, MicrosoftWindows 2000 SP1 or greater, Microsoft Windows NT(r) 4.0 SP6, Microsoft Windows

98, or Windows ME

Overview of the MS SOAP component library

As one might expect, when writing client-side code with MS SOAP 3.0 things aremuch simpler than when writing server-side code However, in either case the samelibrary is in play The MSSOAP30.DLL contains a primary set of components forsending and receiving SOAP messages The classes defined therein include:

✦ SoapClient30: If you are ever going to do any client-side programming with MSSOAP 3.0, you will probably use this class more than any other It is actually afairly intelligible class with methods for initializing the SOAP request, sending

it and then processing the response that is sent from the server

✦ SoapServer30: As you might think, there is a server-side counterpart for theclient-side one SoapServer30 is that server-side class It has methods for pro-cessing an incoming SOAP request and then returning a SOAP response

✦ SoapReader30: While it is true that SOAP requests and responses are made inXML, if you are working with, say, an instance of SoapClient30, you are notworking directly with an explicit instance of the DOM when working with theSOAP messages If you want to go a level lower and work with the XMLdirectly when reading SOAP messages, you can use the SoapReader30 class

This is a useful class when you are working with messages at a lower level forcustomization purposes

✦ FileAttachment30: Lets you send a file as an attachment to a Web service

✦ ByteArrayAttachment30: Lets you send a byte array as an attachment to aWeb service

✦ SteamAttachment30: Lets you read a stream and send it as an attachment to aWeb service

✦ StringAttachment30: Lets you send a simple string as an attachment to a Webservice You may wonder why to use this rather than sending a string as aparameter to a Web service method The reason is that parameters to meth-ods should really not be large data loads that will be used by the method

itself It is better to use method arguments to specify things that define how a method should execute, not large data payloads that contain what the method

✦ HttpConnector30, SoapConnectorFactory30, SoapTypeMapperFactory: If you

do not like the behavior of the built-in connector that binds your SOAPobjects to HTTP, you can customize how MS SOAP creates, sends, receives,and processes your SOAP messages If you are doing custom security or otheradvanced operations, these classes are particularly useful

Server-Side Programming with MS SOAP

Recall that one of the main drivers behind Web services generally is to make aremote component accessible over HTTP so that applications can interact withoutneeding to share their bits one with another To the client, the remote componentshould still look and act like a local component When you create the remote com-ponent, you are not obligated to do anything special to make it available via a Webservice Listing 27-1 shows the code for a simple component with a single methodthat accepts a key for quote and then returns the quote text from database Noticehow there is nothing Web service related in this code It is just good old-fashionedCOM code

Listing 27-1: COM Code for a Component That Will Be

Exposed as a Web Service

Public Function GetQuote(ByVal QuoteKey As String) As StringDim CN As ADODB.Connection

Dim RS As ADODB.RecordsetSet CN = New ADODB.ConnectionSet RS = New ADODB.Recordset

CN.ConnectionString = “Data Source=C:\quotes.mdb;” _

& “Provider=Microsoft.Jet.OLEDB.4.0;”

CN.OpenRS.Open “SELECT Quote FROM QuoteTable WHERE QuoteKey=’” _

& QuoteKey & “‘“, CN, adModeRead

If RS.State = adStateOpen ThenGetQuote = RS.Fields(0).ValueElse

GetQuote = “Quote not found”

End IfElseGetQuote = “No criteria provided”

End IfEnd Function

Once this component is compiled, it has all of the functionality it needs to beexposed on a Website as a Web service Now, in order for a client to connect to thecomponent remotely, there must be an intermediary to translate requests andresponses as SOAP messages because there is no SOAP information in this customcomponent The intermediary must also know which custom code DLL to load thatwill do the actual processing of the data contained in the SOAP request and pro-duce response data that can be sent via SOAP to the client That intermediation iswhat the MS SOAP Toolkit is all about When you install the Toolkit, an ISAPI DLL isinstalled on the server that allows IIS to receive SOAP requests and then route therequest to the appropriate processing code

Let’s take a step back and revisit the installation of the Toolkit for just a moment

When you complete the installation, there are some other files installed that wehave not yet looked at One of these files is the SOAPIS30.DLL This is the handlerthat will receive requests that are routed from IIS This DLL then is the ISAPI lis-tener or handler for SOAP There is a registry key that has settings you can adjust inorder to modify the behavior of the ISAPI listener This key is found at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSOAP\30\SOAPISAP Figure 27-1shows how these keys look in the registry

Figure 27-1: Keys pertaining to the ISAPI handler for MS

SOAP 3.0

The keys and their purpose are:

✦ Isapi: This value is the physical path for the ISAPI DLL used by IIS

✦ MaxPostSize: This value is the maximum size of any SOAP message that theISAPI handler can manage The default is 100KB, and it is a good idea to keep

it as low as your applications can accommodate so that hackers are not able

to cause DOS attacks against your Web server

✦ NoNagling: This value has to do with response times using TCP/IP, and itsvalue should normally be 0

✦ NumThreads: This value sets the maximum number of threads the ISAPI dler can manage The default is for the value to be two times the number ofCPUs plus one If messages are stacking up, you can increase the number ofthreads, but keep in mind that this can impact other server resources

han-✦ ObjCachedPerThread: Caching is a popular technique for improving mance in Web applications This value sets the maximum number of files thatcan be cached for a single message thread When a call is first received, theISAPI handler caches the WSDL and WSML files for the SOAP service in ques-tion As requests for other services are received, they are also cached Thisvalue should be equal to the number of services you are running on yourserver via the MS SOAP Toolkit

perfor-Now, just because you have installed the MS SOAP Toolkit does not mean that theISAPI filter is automatically going to be invoked when a SOAP request comes in.There is actually one more step you need to take in order to tell the ISAPI listenerwhich Web sites where it should be enabled This is done using a special script that

is also found in the Toolkit, SOAPVDIR.CMD By running this command, you tively map a virtual directory in IIS to the ISAPI handler This makes it possible tothus link the SOAP requests and responses directly to the ISAPI listener withoutusing ASP Web pages to field the request and hand it off to SOAP

effec-In some situations, it is needful to be able to switch between version 3.0 of thehandler and earlier versions If this is so, you can indeed change which binary isused in the mapping between IIS and the SOAP requests/responses The registrykey HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSOAP\30\SOAPISAP is whereyou can change this mapping

Now that we have reviewed what pieces are installed on the Web server when MSSOAP is installed, let’s return to our server-side code shown in Listing 27-1 Thiscode is compiled in a DLL, which is in turn registered on the Web server The firstthing that needs to be done is to create the equivalent type library information forthe component(s) in the DLL This type library information is the WSDL file

Gratefully, the Toolkit has a tool for creating this WSDL for you It is called theWSDL Generator and is executed by running wsdlgen3.exe This executable is found

in the MSSOAP\Binaries directory where you have installed the Toolkit and worksonly on Microsoft Windows(r) XP, Microsoft Windows(r) 2000, or Microsoft(r)Windows NT(r) 4.0 When you run the WSDL Generator, just click Next to get past

Note

the introductory screen and click Next again to bypass the Specify Configurationscreen This will bring you to a screen like the one shown in Figure 27-2.

Figure 27-2: Specifying the source DLL for

generating WSDL

Here you need to provide a name for the Web service Keep in mind that the nameyou specify here will be the name for the WSDL and WSML files What the WSML filemeans will be explained in a moment After specifying this information, click Next,and you see the screen shown in Figure 27-3

Figure 27-3: Exposing services and methods for a

given component

Here you need to specify which service(s) will be exposed If you check a serviceand one or more of its methods, these will be represented in the resulting WSDLand WSML files so that SOAP clients can make calls to them Implicit in the design

of the WSDL Generator tool is that you can have more than one Web service in asingle component or in the components of a single DLL It is a good idea to attempt

to aggregate Web service functionality in a single DLL if it makes sense in your ness and if you plan on maintaining the Web services as a group

busi-After you have told the WSDL Generator what methods you want to expose in theWeb service, you need to map the SOAP requests and responses to a specific Website This is done in the following screen, shown in Figure 27-4 Here, you need tospecify a valid Web site address on a machine where the MS SOAP Toolkit has beeninstalled It should go without saying that this is also the server where your DLL isinstalled Make sure you also specify on this screen that you are using an ISAPI lis-tener and not an ASP listener

Figure 27-4: Mapping your custom SOAP service

to a Web site that users or developers can address

With this information specified you can click Next and move to a screen as shown

in Figure 27-5 Here you will see a number of text boxes where you can specify a

namespace for use within your Web service The URIs here are not necessarily the

same as the URI for the Web site that users will reference to gain access to yourWeb service These URIs are namespaces for use within the XML WSDL file andshould correspond to namespaces you use within your organization

Figure 27-5: Specifying namespace URIs for your

Web service

After setting your namespaces, you need to tell the WSDL Generator where to placeyour configuration files This location does not have to be the same as where theWeb site directory is stored, but it should be in a location where client applicationscan get access to it in some way If do not want to make the WSDL file accessibledirectly to client applications from the server, you still need to get the WSDL file toclient workstations in some way, a technique we will discuss in greater detail when

we discuss building client applications that use MS SOAP This is done via a screen

as shown in Figure 27-6

Figure 27-6: Specifying file locations for the output

of the WSDL Generator

With these things done, you have done all that is needful to make a COM objectavailable as a Web service But, something else remains to be explained You see,neither the WSDL nor the SOAP standard has any specifications that deal with map-ping SOAP requests directly to COM objects In other words, with just the WSDL file

on the server, IIS will know that a given SOAP request should be handled by a Website and passed to the appropriate ISAPI handler On the other hand, the ISAPI DLLdoes not know that the request for a method really is targeting a method in a COMDLL Hence, we need another file to do that job for us That file is Web ServicesMeta Language (WSML) file on the server WSML has nothing whatever to do withthe Web services standards such as WSDL, SOAP, or UDDI A WSML file containsinformation that maps the methods of service to specific methods in the COMobject The WSML file is responsible for acknowledging which COM object to load

to make it possible for a SOAP request to be handled

The WSML for the Web service created in this chapter is shown here in Listing 27-2

Listing 27-2: WSML for the QuotesService Web Service

So, as you can see the WSML file is vital for making COM components directlyaccessible through SOAP on the Web

Client-Side Programming with MS SOAP

With the server-side pieces installed, it is now possible to access the Web servicefrom a client application Clients can be non-Windows clients, COM-based clients, ASPapplications, NET applications, and Windows forms applications of varying sorts

The field is quite large Here, we will focus on building COM-based clients First, wewill make an extraordinarily simple client application, a console application

To do this, we will create a simple VBScript file that will invoke the method of ourWeb service and report its results in a message box The text of the VBScript file isshown in Listing 27-3

Listing 27-3: A Simple Console Application to Call an MS

SOAP-Based Web Service

Option ExplicitDim soapClient3set soapclient3 = CreateObject(“MSSOAP.SoapClient30”)

On Error Resume NextCall SoapClient3.mssoapinit(“QuotesService1.wsdl”, _

“QuotesService1”, “QuotesSoapPort”)

if err <> 0 thenwscript.echo “initialization failed “ + err.descriptionend if

wscript.echo SoapClient3.GetQuote(“HNEY-4TTL6B”)

if err <> 0 thenwscript.echo err.descriptionwscript.echo “faultcode=” + SoapClient3.faultcodewscript.echo “faultstring=” + SoapClient3.faultstringwscript.echo “faultactor=” + SoapClient3.faultactorwscript.echo “detail=” + SoapClient3.detail

end if

The key to this file is really where the SOAP client is initialized, the mssoapinitmethod call This call requires that we pass the path to the WSDL file for the Webservice The second parameter is the name of the service Recall that we specifiedthis when we generated the WSDL file using the WSDL Generator tool The lastparameter passed is the name of the SOAP port we are going to call A port is thetarget of a SOAP request, and this maps to a method in the component See Chapter

24 for more on SOAP After that, we use the instance of the SOAPClient30 object,here in a variable called SoapClient3, to call the method and retrieve a quote

What is remarkable about this code is that it is so simple The client is almostalways on a remote workstation, which means that this code is making a methodcall to a remote server, and it is done in a way that both shields the complexityfrom the user or developer while also making it possible to modify the underlyingpieces of the conversation if the need should arise.

Admittedly, this console application is neither very attractive nor is it realistic for atypical, true business solution What we want to do now is make it possible to callthis same service from a more sophisticated client You can create a Windows appli-cation using Visual Basic 6 or the NET Framework if you wish; the latter technique

is dealt with in a different chapter One possible client for the Web service is anoffice productivity application You can create a Web service client using really anyCOM-enabled application, and pretty much any version of Microsoft Office or otherapplications like WordPerfect would also do However, Microsoft Office XP hasadded a tool to make it even easier to create a Web service client for MicrosoftOffice

Office XP Web Services Toolkit

The Office XP Web Services Toolkit (version 2.0 as of this writing) is a free load from Microsoft’s Website The main thrust of the toolkit is to install a specialAddin in Office so that you can easily call Web services in your VBA code There areother things that accompany the Addin such as whitepapers and some samples.Let’s use the Web services toolkit in an Office application, in this case a VBA appli-cation in Microsoft Word To get to the point of creating the VBA project, you need

down-to open Word and go down-to Tools | Macro | Visual Basic Edidown-tor down-to open up the edidown-tor.Once in the editor, you can go to Tools | Web Service Reference to open up the dia-log box shown in Figure 27-7

The main purpose of this dialog box is to get a reference to a WSDL file Based onthe contents of that WSDL file, the toolkit will create a wrapper class for you thatwill expose the same methods as the actual Web service on the remote server.The wrapper class’ methods will have the same signature as those on the remoteservice; they will just be accessible as if on a local DLL rather than a remotecomponent

If you know where the WSDL is located, you can begin referencing it in the dialogbox by clicking the Web Service URL radio button and typing the URL to the WSDL

in the text box provided If you need to find a service, you can use the UDDIbrowser that is also part of the dialog box For more information on UDDI andbrowsing UDDI directories, see Chapter 26

Figure 27-7: Creating a Web Services Reference using the Office XP

Web Services Toolkit 2.0

As you can see in Figure 27-7, we are referencing the Web service created earlier inthis chapter What is important to know here is that Microsoft Word applicationthat is being used here is actually on a separate computer on the network After ref-erencing the WSDL file, you click on Search, and the toolkit will load the WSDL file,

if it can find it If a WSDL file cannot be found in the location your specify, then thedialog will inform you of that fact

Notice how the QuotesService1 service is listed, and the GetQuote method is alsoshown If the service had multiple methods, you would see those here It is impor-tant to know that the Office XP Web Services Toolkit is not restricted to referencingWeb services created using the MS SOAP Toolkit The only MS SOAP dependencythat exists here is that the SOAPClient30 class be defined on the client machine

That way the client machine can package up the requests to be sent to the Web vice and parse responses that are returned The client can access NET or COMWeb services in addition to ones not running on Windows at all

ser-After you have selected the Web service you want to use, just click Add to make itpart of your project This creates the wrapper class for you Figure 27-8 shows howthis class is located in the VBA project

Figure 27-8: The resulting wrapper

class in a VBA project after referencing

a Web service

Let’s take a quick peek at what is inside the wrapper class First, the class containssome information that tells the SOAP client object where to go to make the call, asshown in Listing 27-4

Listing 27-4: Declarations in the Wrapper Class for a

Web Service

Private sc_QuotesService1 As SoapClient30Private Const c_WSDL_URL As String = _

“http://dpower30/xmlweb/quotesservice1.wsdl”

Private Const c_SERVICE As String = “QuotesService1”

Private Const c_PORT As String = “QuotesSoapPort”

Private Const c_SERVICE_NAMESPACE As String = _http://tempuri.org/QuotesService1/wsdl/

This code has some of the same bits of information we saw in our less-sophisticatedexample in Listing 27-3 In fact, upon close inspection of the class, you will find thatthere is little difference between what it contains and what is in the types of thingsspelled out in Listing 27-3 The essentials are nearly identical However, the beauty

of the wrapper class is that you can use it in your code as if it were just a locallyinstalled component

Here, in Figure 27-9, you see a simple user interface created to call the Web serviceand receive a response The code behind it, in Listing 27-5, is extraordinarily simple.

This is the benefit of the Web Services Toolkit The complexity of calling and usingthe service is hidden, although if you wish to edit it you still can

Figure 27-9: The Microsoft Office user

interface for using a Web service

Listing 27-5: Code for Calling a Web Service within the

Office Project

Private Sub cmdOK_Click()Dim qs As clsws_QuotesService1Set qs = New clsws_QuotesService1txtQuote.Text = qs.wsm_GetQuote(txtKey.Text)End Sub

While the code needed to make SOAP calls through the MS SOAP client is not bly difficult, the Office XP Web Services Toolkit does make it less of a developer-centric task than one that is approachable to even power-users

terri-Utilities in the MS SOAP Toolkit

Now that we have had a chance to really get into the MS SOAP SDK and create somesample applications, it is useful to take a broader look the utilities that are provided

in the Toolkit These include:

Starting the utility is easy enough Just double-click the executable or run it fromthe Start menu in Windows However, you need to do a couple of things to make itpossible for the utility to intercept SOAP traffic as it is sent to and from IIS To dothis, the utility must listen in on a specific TCP port The client that wishes to usethe Web service must then reference that port when sending requests to the Webservice The Trace Utility then passes along the message to the Web service on itsoriginal port number (usually 80) so that the Web service is none the wiser Theresponse is then routed back to the Trace Utility, which then in turns sends theinformation back to the client that made the original request The client does notknow that there is a listener involved, nor does the Web service All the clientknows is that instead of making requests to port 80, it will make them to a different

port To make that possible, you will need to modify the client’s copy of the WSDL

and add the special port number to a specific section in the WSDL file This is done

in the <port> element of the client-side WSDL Listing 27-6 shows that section of thefile with the subsequent modification

Listing 27-6: Changing the Client-Side WSDL So That

Messages Can Be Intercepted by the Trace Utility

<service name=’QuotesService1’ >

<port name=’QuotesSoapPort’

binding=’wsdlns:QuotesSoapBinding’ >

Now that the client-side WSDL is modified, we need to start up the Trace Utility andget it to intercept all requests made to the port we have added, 8080 Which portyou choose is up to you, but it is probably not a good idea to use other well-knownports, like 21 or 443 Usually 8080 will work for you without any hassles.

With the Trace Utility running, go to the File | New | Formatted Trace menu, andyou will see a dialog box like the one shown in Figure 27-10 This dialog box simplytells the Trace Utility which port to listen on and which port to which it shouldsend traffic as it receives it

Figure 27-10: Enabling the Trace

Utility to listen in on a specified port number

With these things enabled, running the same client application in VBScript duces results as shown in Figure 27-11 Here you can see the SOAP messages intheir entirety These, of course, are somewhat simple because the Web service isnot terribly complex As you add more information such as SOAP headers and secu-rity information to your Web service, your SOAP messages may be more verbose Inaddition to seeing the XML representation of the messages, you can also look at theSOAP headers and look at the encoded representations of the messages

pro-The Trace Utility can be helpful in creating and troubleshooting Web services, andyou should become familiar with its operations to save yourself time and agony asyou create and deploy Web services

Figure 27-11: The results of a SOAP request and response using the Trace Utility

Summary

In this chapter, we have explored the features of the MS SOAP Toolkit SDK Whilemuch of the interest in Web services is around Java and NET, COM developers(there are millions of them) need not be left behind In fact, in some respects, COMdevelopers have helped fuel the interest in Web services all along, precisely the rea-son why the SOAP Toolkit is now on version 3.0 The toolkit contains utilities andother DLLs to make it possible for COM-based technologies to send and receiveSOAP messages One of the key features is the installation of an ISAPI handler onthe target server so that IIS can receive SOAP messages and route them directly toCOM DLLs that are exposed as Web services Clients can use a set of client objects

to connect to Web services and treat them as if there were local components Wealso saw how to build client applications including using the Office XP Web ServicesToolkit, a clever Addin that turns applications like Microsoft Excel into full Web ser-vice consumers Finally, we saw how to use the Trace Utility to get a good look atthe SOAP requests and responses passed to and from a Web service

J2EE Web Services

The Java 2 Platform, Enterprise Edition (J2EE), is a

Java-based component model that simplifies enterprise JavaApplication development and deployment The J2EE platform

is accessible though J2EE application servers, such as IBMWebSphere Application Server, BEA WebLogic, Sun ONE, andApache Tomcat J2EE classes and methods manage infrastruc-tures and provide supports for Java, XML, and Web serviceapplications The J2EE platform is also the foundation tech-nology of Sun’s Open Network Environment (ONE) platformand Web services strategy

However, core J2EE classes, methods, and properties have absolutely nothing to do with XML or Web services

Fortunately for J2EE developers, J2EE classes do containrobust and flexible support for text, and Web services arebased on XML, and XML is text (Web services are based onvery complicated XML text , but it’s still text) Web servicecode is based on manipulating this text, and converting thetext to other platform formats

There are several architectural options that can be used toefficiently develop and deploy Web services in J2EE In thischapter we’ll introduce an example of a basic J2EE WebService architecture We’ll use the example to describe some

of the advantages of working with Web services in J2EE I’llalso introduce you to vendor platforms that support the archi-tecture In Chapter 32 we’ll discuss the details of the toolsavailable for developing Web services

Web Services: NET or J2EE?

It’s hard not to discuss Web service architecture without discussing both NET and J2EE Both platforms are big sup-porters of Web services Often, both platforms are compared

28C H A P T E R

In This Chapter

The differencebetween NET andJ2EE Web servicesSmart clientsPortalsJ2EE Web ServiceArchitectureJ2EE Web servicebuilding blocksVendor support forJ2EE Web services

and contrasted as opposite Web service camps, but that’s not the way that it has to

be at an enterprise level In fact, many organizations to which I have provided XMLand Web service architectural services have plans to deploy both platforms J2EE’smulti-platform base makes it a natural choice for enterprise applications Also,many vendors, such as SUN, IBM, and Oracle, provide robust interfaces to theirrelational data stores via J2EE/JDBC, XML and Web service interfaces Microsoftand many other software vendors provide NET interfaces to their enterprise prod-ucts, and NET’s Web service client implementation provides a compelling platformfor smart Web service clients

Yeah, blah, blah, blah, Brian: Which one do I pick?

Of course, the enterprise-level scenario we’ve described doesn’t help if you’re ning to start a Web services project and have to start with something Usually, thatsomething means picking a platform, at least as a starting point How should youmake that decision?

plan-In most cases, the software and hardware products that a company has chosen towork with and the skill sets that the company has available for a project shoulddetermine a solution platform Because Web services use industry-standard for-mats for communication, it’s not imperative to stick with one platform or the other

as the scope of a project or solution grows But before you start a project, you ally must have to pick one This is what makes Web service architecture interesting!The consolation is that Web service architecture can often accommodate imperfectplatform decisions For example, if you start a project with Oracle XML DB as a Webservice data repository, then for some reason decide to switch the data to SQLserver or DB2, the change from one RDBMS platform to another should not be diffi-cult within a well-designed multi-tier Web service architecture Before Web services,this change would probably require a rewrite of the client, the access method to thedata, and the application server that accesses the data

usu-When selecting a Web services platform, what you already have to work withshould be a big factor Existing platforms and development tools, existing developerskill sets, and existing investment in software and hardware are important factors indetermining future direction Because Web services are supported by most majorsoftware vendors and development tools these days, the deciding factor oftencomes down to the OS platform that the Web service solution will run on J2EE has

an advantage in multi-platform applications, while NET has a clear advantage inWindows server environments

Don’t overlook smart clients!

Windows has something that J2EE does not, and may never have — a smart Webservices client Smart clients are applications that function at the application or OSlevel of client hardware, and are easily integrated with other parts of the client

hardware and software to provide rich, configurable functionality to the user Thisfunctionality is usually automated and requires little or no custom development.

Because they require no developer assistance, smart clients are often overlookedwhen designing and building Web service applications, in favor of server-basedWeb browser solutions As Web service clients, Web browsersare great for basicdisplay of data However, one of the key features of Web services is the ability toaccess data over the Web from any client, not just a Web browser This means thatyou can add Web services to a column of a spreadsheet or integrate Web servicesinto a calendar application on your desktop or a smart wireless phone The smartclient can be easily integrated with other applications at the client level, making iteasy to build robust, customizable client applications that access data via Web ser-vices For example, a Web browser is handy for booking a flight online However,once you book a flight, how do you get the flight data into your calendar or yourPDA? This is usually a cut and paste procedure, or the task of a third-party tool thatcan read the flight data and knows how to insert the data in your client application

But what if you could just add an airline’s or hotel’s reservation system directly intoyour calendar? You could select dates, make reservations, and store itinerary datafrom your calendar as if the airline’s reservation system was part of your calendarapplication This is the promise of Web service smart clients

.NET and MS Office have already added very impressive Web service client ties into many Windows client applications This functionality increases with eachnew version of Windows and Office Another potential Web service client competi-tor is Lotus Notes, which integrates e-mail, calendaring, applications, an integratedapplication development environment, and much more into their very impressiveNotes client application At the moment, Notes has an advantage over other smartclients in terms of client application security and multi-platform server support,but MS Office and NET applications have the advantage of providing robust andeasy client access to Web services

capabili-About portals

J2EE’s answer to smart clients is the portal Applications that use J2EE Web vices commonly use a Web browser as the client, which accesses data from aserver The server is usually a mid-tier J2EE server, which has access to otherservers to retrieve and process data This model usually referred to as a “thinclient” architecture I question the thin part, as modern browsers are actually quitecomplex clients — but in this case thin can describe the workload, not just the foot-print of the client In thin client architecture, the client, usually a Web browser doeslittle or no work Almost all of the processing is done on a middle-tier J2EE applica-tion server The browser’s job is to send requests to a J2EE server, and wait for anHTML page response The J2EE server usually sends requests to one or more otherservers for data and then processes the HTML page that is sent back to the

ser-browser

A portal provides a common interface to multiple applications The portal acts as acentral point of contact for various applications that serve data on multiple plat-forms, and is usually customizable by the user User configuration information isusually stored on a centralized portal server, so that the user can interact with theircustomized environment on any machine that can access the portal server Portalsare currently a very popular segment of J2EE development, because they are well-suited to a multi-tier J2EE application architecture

Having a large number of users connect to a centralized portal server presents ability issues that multi-tier J2EE architectures are designed to address .NET doeshave portal capability integrated as part of its framework as well, but the jury isstill out when it comes to enterprise-level Web service scalability on a Windows-only platform

scal-Web services can be an important part of J2EE portal architectures They act as theglue that holds together the communication infrastructure between the tiers.Instead of having to adapt data formats and platform protocols to communicatewith each other, Web-service-enabled data providers can connect to each other viathe Web service “lingua franca” of SOAP Portals and Web services extend the func-tionality of the thin-client model by providing more interactivity between a thinclient and a J2EE application server Instead of a smart client that interacts withserver data, the portal aggregates and processes data, and serves the data to athin Web services client Portal servers take on the role of the smart client in thisscenario

Portal servers have two advantages over a smart client in Web service tures The first advantage is that the portal is always on In the case of a smartclient such as a PDA, smart wireless phone, or laptop, there are times when pro-cessing will be limited because the client is not accessible The second advantage isthat user configuration is stored on a centralized server Theoretically, this meansthat any client that can access the portal server is automatically configured to auser’s centrally stored settings These advantages have to be weighed, however,with the rich and flexible display and application integration options that smartclients offer I predict that as Web services evolve, “thin” Web service clients willstart to look more and more like smart Web service clients, as features are added toprocess data at the client level This has happened with Web browsers and HTTPservers, and I expect the same evolution for Web service clients and servers Eventoday, portals and smart clients can interact There’s no law stating that Web ser-vice portals can only serve HTML pages to browser clients Portals can also sendand receive SOAP to interact with a smart Web service client

architec-J2EE Web Service Architecture

While it is true that there is an exception to every rule, exceptions tend to be moreplentiful in the fast-evolving Web services world That’s why we tend to use wordslike “usually” and commonly” a lot when describing Web service architectures Withthat warning in mind, let’s run through the basic building blocks of a J2EE Web ser-vices architecture

Multi-tier J2EE Web service client architectures start with a thin client, which isusually a browser, but could be any hardware or software device Other commonsoftware clients are another Web service, a proxy class in VB, Java, C++, or anyother language, or a smart client that generates SOAP envelopes

Instead of clients and servers, W3C documentation refers to service requestors andservice providers This is to account for the fact that Web services can have manylayers, and that in some cases a “client” may be another Web service on anotherserver

Requestors connect to a server that processes requests Requests and responsesbetween the requestor and the provider are usually, over HTTP W3C-standard callsand responses can be sent and received using SMTP as well, but this is not verycommon

The messages that are sent between the requestor and the provider are contained

in SOAP envelopes The SOAP envelope can contain anything, but usually containsXML There are two basic ways that SOAP envelope contents can be formatted,remote procedure call (RPC) and anything else The most common method is RPC

In SOAP envelopes, the XML contents of the envelope follow a basic call andresponse protocol between the requestor and the provider The requestor makes acall and waits for a response The provider receives the call and makes a response

If the SOAP envelope is not formatted as RPC, the call-and-response mechanism, ifthere is any, has to be described as part of the envelope contents

SOAP is covered in more detail in Chapters 23 and 24

A Web Service Requestor sees a Web Service provider as a single entity However, asingle Web service provider is usually made up of multiple layers

A portal is an optional first layer for J2EE Web services The portal can be part of a

J2EE application server environment, or a separate portal server Portals act as asmart client proxy to manage information and tasks on behalf of a user In a J2EEWeb service architecture, the portal interacts with the J2EE application server to

Cross-Reference

Note

process Web services (For more information on portals, and how they can be ful for Web Service architectures, see the “About portals” section earlier in thischapter.)

use-If a portal server is not implemented, the first layer in a J2EE Web service is a J2EE

application server, such as IBM’s WebSphere Application Server, BEA WebLogic, Sun

ONE server, or Apache Tomcat

If SOAP envelope contents are formatted as RPC, the J2EE application server uses

an RPC Router and a deployment descriptor to process the functionality associated

with the Web service Deployment descriptors are used to make the link betweenWeb service requests and responses and an application Deployment descriptorsare XML documents that are stored on the J2EE application server The RPC routeruses these deployment descriptors to find classes and methods associated with theWeb service The J2EE application server controls the calls and responses to otherentities that make up the Web service Processing could include calling anotherWeb service, calling a Java class, or retrieving data from a data repository such as aRDBMS When the appropriate responses have been received, the J2EE applicationserver builds a SOAP response envelope and sends it back to the requestor Figure28-1 shows a typical J2EE application server architecture

Figure 28-1: A typical J2EE Web services architecture

Now that you have an overview of what a J2EE Web service looks like, let’s drilldown a little deeper into the workings of a J2EE application server Specifically,let’s look at how associated applications make up a Web service Once again, I’llstart with a browser as a Web service requestor

UDDI/WSDL

Web Service

J2EE Application Server (WebSphere, WebLogic, Tomcat, Sun One, etc.)

External Applications

Web Service

Post

W

SDL Prot oco

J2EE Portal

RPC Router Deployment Descriptor Deployment Descriptors

A Web service requestor can optionally access a UDDI server entry J2EE UDDI tionality is usually implemented using IBM’s UDDI4J or Sun’s JAXR The UDDI entrypoints to the latest version of a WDSL file If the requestor already has an instance

func-of the WSDL file located, they can skip this step

JAXR includes a registry server as part of the implementation classes

The WSDL document contains information about a Web service J2EE proxy classescan be used as a requestor interface Proxy classes are designed to read the WSDLfile at a predefined location on a J2EE server WSDL files are registered on the J2EEapplication server A well-written proxy class is designed to adapt calls andresponses to the Web service according to WSDL values

WSDL is covered in more detail in Chapters 23 and 25

When a Web service requestor makes a call to a Web service provider using a SOAP envelope formatted as RPC, the request is routed to a transport-independentSOAP RPC router The RPC Router is usually based on the org.apache.soap

server.RPCRouterclass, which is a member of the Apache AXIS packages TheRPC Router listens for HTTP POSTs that are sent to a URL on the J2EE applicationserver SOAP envelopes are retrieved from the POST The RPC Router builds anRPC call object from the SOAP envelope contents, and checks the validity of theobject and makes the call If the call requires a response, the RPC Router waits for

a response, and generates a SOAP response envelope from the response object

Creating a SOAP envelope from a call or response object is known as marshaling

a SOAP envelope Breaking down a SOAP call into another object is called

The unmarshaled RPC call is directed to its destination by a deployment descriptor

Deployment descriptors are XML documents that reside on the J2EE applicationserver, and describe a SOAP action SOAP actions are mapped to applications

Those applications can be a simple class on the J2EE server, another Web service, aRDBMS query, or virtually anything else that can accept an RPC call

The Apache AXIS packages contain classes that accept a Java class as input andgenerate a WSDL document AXIS can also generate a client proxy class for thesource J2EE class Proxy classes can act as a client-side interface between Javaapplications, servlets, or applets AXIS can also generate a deployment descriptor

at the same time it generates the WSDL and the proxy class

Figure 28-2 shows the structure of a Typical J2EE application server that is ured for Web services, with all of the components we’ve described in this section ofthe chapter

config-Tip Note

Cross-Reference

Tip

Figure 28-2: Structure of a typical J2EE Application Server,

configured for Web services

Software Support for J2EE Web Services

J2EE Web services are built on a platform of Web service standards They are alsobuilt on a set of components that adhere to those standards Multi-tier J2EE Webservices start with a thin client, usually a Web browser In between the browser andthe data that is being accessed, there are one or more tiers that provide data for-matting and processing Software for developing and deploying multi-tier J2EE Webservices is based on java developer community effort Most of these efforts center

on projects at the Apache Software Foundation Most J2EE Web service softwareproviders use the latest version of the Apache software foundation’s AXIS as thecore of their offerings AXIS stands for “Apache eXtensible Interaction System,” and

is a J2EE reference implementation of the latest W3C recommendations for SOAPand WSDL AXIS code can be implemented on the client side as proxy classes and

on the server side as routers and implementation classes We’ll get into the tecture in more detail later in this chapter For now it’s just important to know thatAXIS code is used in most J2EE implementations where SOAP and WSDL functional-ity is needed

archi-Web Service Requestor

J2EE Server

UDDI Discovery (Optional) (UDDI4J, JAXR)

WSDL Page (AXIS)

Action (Class or Method) Enterprise

Data RPC Router

Deployment Descriptor

Apache Offerings

The Apache Software Foundation is a non-profit consortium that provides tional, legal, and financial support for Apache open-source software projects, all ofwhich can be seen at http://www.apache.org/ The goal of all of the ApacheWeb service projects is to provide high-quality standards-based XML solutions thatare developed in an open and cooperative fashion Apache project participants are

organiza-in a unique position to provide feedback to W3C Web service workorganiza-ing groupsregarding implementation issues, based on real-life implementation attempts Allimplementation code is available in Java Server code is based on J2EE Some projects produce other code in other languages as well For a full list of Apache projects, go to http://apache.org/

Apache AXIS

Apache Software Foundation code is weaved in to most commercial and mercial J2EE development tools for handling XML and Web services For example,IBM and Sun both have features built in to their J2EE development UIs that generate

non-com-a WSDL file from non-com-a Jnon-com-avnon-com-a clnon-com-ass, non-com-and vice versnon-com-a These tools non-com-are bnon-com-ased on AXIS codethat has been integrated into the product AXIS also provides RPC Router function-ality and classes to handle SOAP envelopes on J2Ee servers and in developer UI testenvironments

Web Services Invocation Framework (WSIF)

The Web Services Invocation Framework (WSIF) is a Java API for invoking Web services without directly accessing a SOAP API, such as AXIS It provides the samekind of functionality that JAXP does for Web parsing A WSIF interface can be used

on any WDSL-compatible Web service, regardless of the original SOAP or WSDL version or implementation Additional information can be found at http://ws

apache.org/wsif

Web Services Inspection Language (WSIL)

The Web Services Inspection Language is a standardized way to find out about published WSDL without a USDDI server implementation WSIL also provides rulesfor how inspection-related information can be revealed by a site WS-Inspectiondocuments point to WSDL and other forms of Web service descriptors The WSILspecification can be reviewed at http://cvs.apache.org/viewcvs.cgi/

*checkout*/xml-axis-wsil/java/docs/wsinspection.html

XML security

Apache has implemented Java reference implementations of the XML-SignatureSyntax and Processing Recommendation, and the XML Encryption Syntax andProcessing By the time this book is in print, they probably will have finished theXML Key Management recommendation implementation in Java as well

We cover Web service security in more detail in Chapter 37

Jakarta Tomcat

Tomcat is the official J2EE Reference Implementation for Java Servlet and JavaServerPages technologies Tomcat is a J2EE application server that also supports SOAP andWSDL implementations via AXIS classes This includes an RPC Router, which is based

on the AXIS rpcrouter class Additional information about Tomcat can be found athttp://jakarta.apache.org/tomcat/index.html

IBM Offerings

Aside from integrating Apache and other Web service tools as part of theWebSphere Studio Application Developer, IBM also provides the WebSphereApplication Server (WAS) WAS is an integral part of J2EE Web Service architectures

on IBM platforms AlphaWorks is also an important place for learning about andusing cutting-edge technologies

WebSphere Application Server

IBM’s WebSphere Application Server (WAS) is IBM’s offering in the J2EE applicationserver marketplace WAS provides the glue that holds a J2EE Web Service architec-ture together Support for multi-platforms, including IBM mainframe hardware,ensures scalability More information can be found at http://www.ibm.com/websphere

WebSphere Portal Server

As we mentioned earlier in this chapter, portals are the J2EE version of a WebService smart client IBM WebSphere Portal is a platform more than it is an applica-tion or server It seamlessly integrates with WebSphere Application Server, whichseamlessly integrates with just about anything else — :you just have to write most

of the seams yourself The WebSphere Portal Collaboration Center integrates IBM’sLotus Domino for collaborative applications Features include integrated instantmessaging, team workspaces and online meetings More information can be found

at http://www.ibm.com/websphere

Cross-Reference