Understanding Web Services- XML, WSDL, SOAP and UDDI. Preface

Transcription

1

2 Preface I first ecoutered XML as a itegratio techology i early 1998 durig a visit to KPN Telecom i the Netherlads. The compay was askig for proposals to help it develop a eterprise itegratio architecture based o the hub ad spoke model, usig XML as the caoical message format that would tie together the compay's thousads of systems ad hudreds of programmig laguages. My employer at the time, Compaq (Digital), did ot wi the project, but the cotroversial idea of usig XML i a data-idepedet itegratio layer stuck with me. Now Web services are fulfillig that promise for everyoe. I joied IONA i the fall of 1999 ad amog other thigs soo bega chairig the Object Maagemet Group submitter's team draftig the XML Value specificatio, mappig XML to CORBA. I early 2000, I got ivolved i the ew effort Microsoft was leadig to defie a distributed computig protocol for the Iteret: SOAP. Previous attempts to promote the CORBA protocol had failed by the, ad the W3C's ow attempt, HTTP-NG, had also falle flat. But the idea of serializig XML over HTTP seemed to hold promise for a solutio. IONA formally joied the SOAP effort i March 2000, before IBM joied ad put the effort o the map. I worked with Adrew Layma, David Turer, Joh Motgomery, ad others at Microsoft to brig IONA ito the picture as a SOAP supporter ad, i fact, as the first J2EE vedor to support SOAP. IONA demostrated Web services iteroperability at several Microsoft evets durig that year. The Microsoft preseter would itroduce its SOAP Toolkit ad demostrate iteroperability with a COM server. The the IONA preseter was called o to describe how the same SOAP iterface could iteroperate with a Java server. After that, I orgaized IONA's iitial participatio at W3C, supported the establishmet of the XML Protocols Workig Group, helped write the group charter, ad bega represetig IONA at the XML Protocols Workig Group, ad more recetly, at the Web Services Architecture Workig Group. IONA has supported the submissio of SOAP to W3C, WSDL, SOAP with Attachmets, ad XKMS. Oe thig led to aother, ad I evetually took o the resposibility of deliverig IONA's implemetatio of Web services itegratio techologies. I October 2000, I repres eted IONA at the UDDI kick-off meetig. It was the that I realized the potetial for Web services techologies for applicatio itegratio iside the firewall. Why ot use SOAP, UDDI, ad WSDL for iteral projects? The you could use the same approach for itegratio, regardless of whether it's iside the compay or across the Iteret. David Vaskevitch preseted at the UDDI coferece, ad this remided me of the 1995 chapter i The Future of Software that I coauthored for Digital Equipmet Corporatio. David was author of the Microsoft chapter i that same book. I the Digital chapter, "The Key to the Highway," Peter Cokli ad I compared the potetial power of software stadards to the impact of stadards o the automobile. Stadardized parts eabled mass productio, which revolutioized the idustry ad society. Today, software remais essetially a craft busiess, as automobiles were at the start of the twetieth cetury. Havig widely adopted stadards has remaied elusive despite may attempts. We may be at the crossroads; Web services may fially do the trick. I hope this book helps you uderstad what Web services are all about. If it serves as a decet itroductio to the mai ideas, cocepts, ad techologies, it will have doe its job ad fid its place i the Web services commuity. Page 1

3 Ackowledgmets First of all, thaks to David Chappell for givig me the opportuity to cotribute to his ew series. David helped shape the orgaizatio, cotet, ad overall approach of the book, which I greatly appreciated. The.NET iformatio i this book is draw primarily from David's book, which he was kid eough to share with me i advace of publicatio. Secod, I'd like to thak Steve Vioski, who provided the most thorough ad helpful review of the etire mauscript, commetig with equal emphasis o small details ad big ideas. Qu (Joaa) Liag was tremedously helpful i providig ad correctig examples i Chapter 2. Be Berhard ad Daiel Kulp helped with examples for Chapters 3 ad 4. Pyouguk Cho provided a helpful, last-miute review of Chapter 5. Sea Baker, Vimal Kasal, Miloslav Nic, Jamie Osbore, Tom Sulliva, ad Sajiva Weerawaraa reviewed the etire mauscript or large portios of it, offerig may helpful commets ad suggestios. Other people provided helpful reviews of specific portios of the mauscript o which they have expertise: Klaus-Dieter Naujok, ebxml; Igor Balabie, security; ad Karste Jauszewski, UDDI. I'd also like to thak the represetatives of the vedors whose resposes to the survey o Web services implemetatios are preseted i Chapter 8, icludig: Christia Greier ad Terry Dwyer of BEA; Arai O'Toole ad Hugh Grat of Cape Clear; Joseph McGoell ad Mark Little of HP; Sajiva Weerawaraa ad Heather Kreger of IBM; Rebecca Dias ad Alex Roedlig of IONA; Philip DesAutels ad Joh Motgomery of Microsoft; Kuassi Mesah ad Jeff Mischkisky of Oracle; Peter Kacades, Kare Shipe, ad Peter Walker of Su Microsystems; ad Miloslav Nic ad A Thomas-Maes of Systiet. Although they provided the origial iformatio ad reviewed the text, ay remaiig errors are solely my resposibility. May thaks to the Addiso-Wesley editorial ad productio staff, who made the preparatio ad fiishig of the mauscript a truly professioal, high-quality edeavor: Mary O'Brie, Alicia Carey, Marily Rash, Jacquely Doucette, ad Evely Pyle. Fially, I would really, really like to thak my wife, Jae, ad kids, Erica ad Alex yes, really for bearig with me ad for uderstadig the time away. Itroductio Web services are chagig the way we thik about distributed software systems, but there's a limit to what they ca do. This book describes the core eablig techologies WSDL, SOAP, ad UDDI ad idetifies where Web services begi ad ed ad where existig techologies take over. This book describes the cocepts behid the basic Web services techologies, ad it also icludes chapters o ebxml, additioal Web services techologies, ad product implemetatios. The book is iteded for IT professioals who are iterested i uderstadig Web services, how they work, ad what they are good for. About Web Services Web services provide a layer of abstractio above existig software systems, such as applicatio servers, CORBA,.NET servers, messagig, ad packaged applicatios. Web services work at a level of abstractio similar to the Iteret ad are capable of bridgig ay operatig system, hardware platform, or programmig laguage, just as the Web is. Page 2

4 Ulike existig distributed computig systems, Web services are adapted to the Web. The default etwork protocol is HTTP. Most existig distributed computig techologies iclude the commuicatios protocol as part of their scope. With Web services, the commuicatios protocol is already there, i the far-flug, worldwide Web. New applicatios become possible whe everythig is Web service eabled. Oce the world becomes Web service eabled, all kids of ew busiess paradigms, discussio groups, iteractive forums, ad publishig models will emerge to take advatage of this ew capability. Software ad hardware vedors alike are rushig Web services products to market. The widespread adoptio of the core stadards represets a sigificat breakthrough i the idustry. Applicatios ca truly be built usig a combiatio of compoets from multiple suppliers. Specialists are emergig to provide services i the areas of security, trasactio coordiatio, bill processig, laguage traslatio, documet trasformatio, registries ad repositories, accoutig, reportig, ad specialized calculatio. Applicatios beig built aywhere, aytime, o ay system ca take advatage of prebuilt compoets, speedig time to market ad reducig cost. Meawhile, ebxml, which chartered ad maitais a separate course, cotiues to solve tough problems for corporate tradig parters that are establishig automated supply chai purchasig ad ivoicig systems, large electroic documet trasfers, ad busiess commuities sharig commo goals. The rightful heir to EDI, ebxml is providig a easier-to-use, lower-cost alterative to busiesses automatig their iteractios with other busiesses. With ebxml, a compay's iteral IT systems are coected to the IT systems of its tradig parters, subcotractors, ad busiess collaborators. The value iheret i these systems is therefore greatly icreased, as they become essetially part of oe large IT system, with essetial iformatio flowig freely across corporate boudaries rather tha stuck withi them. Cosiderable overlap exists betwee the core Web services techologies ad ebxml. Covergece betwee the two is based o their commo adoptio of SOAP as the trasport ad o the ability of the respective registries to share data. The ebxml specificatios iclude may qualities-of-service requiremets that are ot yet icluded i Web services, such as message itegrity ad orepudiatio, reliable messagig, busiess process flow, ad protocol egotiatio. Further covergece is possible as the core Web services techologies begi to adopt proposals i these additioal techology areas. Disagreemet remais over the best approach to defiig these additioal techologies i the cotext of Web services. Oce the core stadards are adopted widely, the discussio moves up the stack to tackle quality-of-service issues. Security, trasactios, process flow, ad reliable messagig stadards are eeded, ad some are further alog tha others. The power of XML drives Web services techologies i geeral, whether it's the core stadards, additioal techologies, or ebxml. XML fially solves the problem of data idepedece for programmig laguages, middleware systems, ad database maagemet systems. Previously, data types ad structures were specific to these types of software, ad attempts at commo defiitios, such as CORBA IDL, gaied limited acceptace. XML is well o its way to becomig as well established as its siblig, HTML. The Web services techologies described i this book are all created usig applicatios of XML i oe way or aother. XML is ot oe thig but rather a variety of techologies i itself, coverig istace data as well as typig, structure, ad sematic iformatio associated with data. XML ot oly describes data idepedetly but also cotais useful iformatio for mappig the data ito ad out of ay software system or programmig laguage. Web services provide almost ulimited potetial. Ay program ca be mapped to Web services, ad Web services ca be mapped to ay program. Trasformatio of data to ad from XML is essetial, but XML is flexible eough to accommodate ay data type ad structure ad eve to Page 3

5 create ew oes, if ecessary. Whe all programs ad software systems are fially Web service eabled, the world of distributed computig will be very differet from what it is today. About This Book To provide a backgroud ad sufficiet detail for practical uderstadig ad use of these techologies, this book is orgaized ito chapters o the mai topics of iterest. Chapter 1, Itroducig Web Services This chapter highlights the most importat aspects of Web services ad what they ca be used for, as well as cotais a detailed overview of the etire book. Iformatio is provided about the followig: XML (Extesible Markup Laguage), the family of related specificatios o which all Web services techologies are built WSDL (Web Services Descriptio Laguage), providig the fudametal ad most importat abstractio of Web services, the iterface exposed to other Web services ad through which Web services are mapped to uderlyig programs ad software systems SOAP (Simple Object Access Protocol), providig commuicatios capability for Web services iterfaces to talk to oe aother over the Iteret ad other etworks UDDI (uiversal descriptio, discovery, ad itegratio), providig registry ad repository services for storig ad retrievig Web services iterfaces ebxml (electroic busiess XML), a architecture ad set of specificatios desiged to automate busiess process iteractio amog tradig parters Additioal techologies, goig beyod the core Web services stadards to meet requiremets for security, reliable messagig, trasactio processig, ad busiess process flow so that more complex ad critical busiess applicatios ca use them Vedor implemetatios, providig a variety of implemetatios usually aliged with existig products but i some cases etirely ew products for flexible ad extesible Web services Chapter 2, Describig Iformatio: XML The Extesible Markup Laguage (XML), like the Hypertext Markup Laguage, shares a commo acestry i the Stadard Geeralized Markup Laguage (SGML). Oe of the characteristics of SGML was the separatio of format ad cotet. Whether a documet was produced for A4 or i letter format, for example, the format was described idepedetly of the cotet of the documet. The same documet could therefore be output i multiple formats without chagig the cotet. This priciple of markup laguages is applied to Web services through the separatio of the documet istace, which cotais the data, ad the schema, which describes the data structures ad types, icludig sematic iformatio useful for mappig the documet to multiple programmig laguages ad software systems. XML represets a large umber of specificatios, may of which are more pertiet to documet processig tha to iformatio processig. This chapter describes the XML specificatios ad techologies most importat to Web services, which i geeral ca be said to go "beyod markup" to provide facilities for structurig ad serializig data. This chapter icludes oly those XML techologies relevat to Web services ad explais how ad what they are. Chapter 3, Describig Web Services: WSDL The Web Services Descriptio Laguage (WSDL) provides the mechaism through which Web services defiitios are exposed to the world ad to which Web services implemeters eed to coform whe sedig SOAP messages. WSDL describes the data types ad structures for the Page 4

6 Web services, explais how to map the data types ad structures ito the messages that are exchaged, ad icludes iformatio that ties the messages to uderlyig implemetatios. WSDL is defied so that its parts ca be developed separately ad combied to create a comprehesive WSDL file. The data types ad structures ca be shared amog multiple messages, as ca the defiitio of the services exposed withi the iterface. WSDL lists the iterfaces ad, withi a iterface, associates each service with a uderlyig implemetatio. I order to achieve commuicatio for Web services, WSDL maps them oto commuicatio protocols ad trasports. Both parties i a Web services iteractio share a commo WSDL file. The seder uses the WSDL file to geerate the message i the appropriate format ad to use the appropriate commuicatio protocol. The receiver uses the WSDL file to uderstad how to receive ad parse the message ad how to map it oto the uderlyig object or program. Chapter 4, Accessig Web Services: SOAP Oce a iterface is defied for them, Web services eed a way to commuicate with oe aother ad to exchage messages. The Simple Object Access Protocol (SOAP) defies a commo format for XML messages over HTTP ad other trasports. SOAP is desiged to be a simple mechaism that ca be exteded to ecompass additioal features, fuctioalities, ad techologies. This chapter describes the parts of SOAP ad the purpose of each. SOAP is a oe-way asychroous messagig techology that ca be adapted ad used i a variety of message-passig iteractio styles: remote procedure call (RPC) orieted, documet orieted, ad publish ad subscribe, amog others. If aythig defies the miimum criterio for a Web service, it must be adherece to SOAP. SOAP messagig capability is fudametal to Web services. SOAP is defied at a very high level of abstractio ad ca be mapped to ay umber of uderlyig software systems, icludig applicatio servers,.net servers, middleware systems, database maagemet systems, ad packaged applicatios. The chapter describes the required ad optioal parts of SOAP, explais how SOAP messages are processed, ad discusses the role of itermediaries i SOAP message processig. Backgroud iformatio o the specificatio is provided, as are examples of the major SOAP parts. A explaatio of SOAP with Attachmets is also icluded. Chapter 5, Fidig Web Services: UDDI Registry The iitiative for uiversal descriptio, discovery, ad iteroperability (UDDI) produces specificatios ad a active implemetatio of a repository for Web services descriptios. The UDDI registry ca be searched usig various categorizatio criteria to obtai cotact iformatio for busiesses offerig services of iterest. UDDI provides a publicly accessible meas to store ad retrieve iformatio about Web services iterfaces ad implemetatios. This chapter describes the UDDI data formats ad the SOAP APIs used to store ad retrieve iformatio from UDDI. This chapter also provides backgroud o the UDDI orgaizatio that sposors the physical registry ad the process by which UDDI specificatios ad techologies are movig toward adoptio. The Web eeds somethig like UDDI to provide a clearighouse for Web services iformatio so that publishers ad cosumers ca fid each other. Oly the ca the true value of Web services be realized: whe Web services cosumers ca easily ad quickly locate ad begi accessig Web services implemetatios aywhere i the world. Page 5

7 Chapter 6, A Alterative Approach: ebxml The electroic busiess XML (ebxml) iitiative was started aroud the same time that the Web services commuity bega to grow. For the first several moths, ebxml was a etirely separate ad parallel effort. May of the goals of ebxml are commo to Web services, ad may of the techologies overlap i cocept. I geeral, however, ebxml is focused more at the idustrial or eterprise computig level, addressig as the top goal the issue of busiess process defiitio. This chapter explais the backgroud, goals, ad origi of ebxml ad covers the ebxml architecture i detail. Idividual specificatios are described ad placed ito their proper cotext withi the overall architecture. The ebxml architecture icludes may of the same thigs as the core Web services techologies but goes beyod them i defiig quality-of-service requiremets for reliable messagig, security, ad tradig-parter egotiatio. Begiig as a replacemet for EDI, ebxml seeks to avoid some of the problems with EDI implemetatios ad acceptace, especially i smaller busiesses. Chapter 7, Web Services Architecture: Additioal Techologies After the core Web services techologies are implemeted ad adopted, a whole rage of additioal techologies is eeded to eable Web services to address complex ad critical applicatio requiremets. Busiesses will eed to secure their Web services agaist uauthorized use, to guaratee that their SOAP messages arrive at their iteded destiatios ad are processed reliably, ad to defie ad execute automated busiess process flows accordig to a stadard mechaism. This chapter describes these ad other techologies i the cotext of the vedor ad idustry iitiatives i which they are likely to progress toward adoptio. I some cases, competig proposals vie for adoptio, ad the leadig cadidates are discussed. The chapter also icludes descriptios of two techologies o which may Web services cocepts are based: RosettaNet ad XML-RPC. Chapter 8, Implemetig Web Services Web services specificatios ad techologies are ot meaigful or particularly useful without implemetatios i software vedor products. This chapter summarizes the major architectural approaches to Web services implemetatio, describes the major developmet commuities of.net ad J2EE, ad presets iformatio supplied by BEA Systems, Cape Clear, IBM, IONA, Microsoft, Hewlett-Packard, Oracle, Su Microsystems, ad Systiet o their curret product offerigs ad views of the future. Some vedors ted to view Web services implemetatios primarily withi the cotext of their existig products, as additioal cliets or adapters ito ad out of the existig applicatio servers, database maagemet systems, ad middleware systems. Other vedors seek to mie the value of the Web services layer itself, where multiple, disparate software system domais are put ito relatioship ad itegrated. Other vedors offer products i multiple categories, icludig some aimed purely at providig a implemetatio of Web services stadards as well as some aimed at exposig Web services iterfaces to existig products. Although vedors ted to agree o the adoptio ad wide spread implemetatio of the core stadards, very little, if ay, agreemet exists at the ext level; that is, what should come ext. Security, trasactios, process flow, ad reliable messagig are all part of various vedors' plas but i somewhat differig orders ad levels of importace. Page 6

8 Chapter 1. Itroducig Web Services Like the effect of rail trasportatio o atioal ecoomic systems, Web services are fudametally chagig the rules of Web commerce. They coect programs to each other across distat poits o the global map, trasportig large amouts of data more efficietly ad cheaply tha ever before. The result is faster, better, ad more productive commuicatio for busiesses ad cosumers alike. Web services are chagig everythig The Web started out supportig huma iteractios with textual data ad graphics. People use the Iteret daily to look up stock quotes, buy cosumer goods, ad read the latest ews. This level of iteractio is fie for may purposes. But the essetially text-based Web does ot support software iteractios very well, especially trasfers of large amouts of data. A more efficiet method is eeded that allows applicatios to iteract directly with oe aother, automatically executig istructios that would otherwise have to be etered maually through a browser. Idividuals ad compaies doig bus iess over the Web eed a way to publish liks to their applicatios ad data, i much the same way that they publish liks to their Web pages. Iteretbased applicatios eed to be able to fid, access, ad automatically iteract with other Iteretbased applicatios. Web services improve Iteret use by eablig program-to-program commuicatio. Through the widespread adoptio of Web services, applicatios at various Iteret locatios ca be directly itegrated ad itercoected as if they were part of a sigle, large IT (iformatio techology) system. The curret Web does ot support software-orieted iteractios very well The Basics of Web Services Web services are Extesible Markup Laguage (XML) applicatios mapped to programs, objects, or databases or to comprehesive busiess fuctios. Usig a XML documet created i the form of a message, a program seds a request to a Web service across the etwork, ad, optioall, receives a reply, also i the form of a XML documet. Web services stadards defie the format of the message, specify the iterface to which a message is set, describe covetios for mappig the cotets of the message ito ad out of the programs implemetig the service, ad defie mechaisms to publish ad to discover Web services iterfaces. Web services trasform XML documets ito ad out of IT systems This techology ca be used i may ways. Web services ca ru o desktop ad hadheld cliets to access such Iteret applicatios as reservatios systems ad order-trackig systems. Web services ca also be used for busiess-to-busiess (B2B) itegratio, coectig applicatios ru by various orgaizatios i the same supply chai. Web services ca also solve the broader problem of eterprise applicatio itegratio (EAI), coectig multiple applicatios from a sigle orgaizatio to multiple other applicatios both iside ad outside the firewall. I all these cases, the techologies of Web services provide the stadard glue coectig diverse pieces of software. Web services ca be used i may applicatios Page 7

9 As illustrated i Figure 1-1, Web services wrap, presetig to the etwork a stadard way of iterfacig with back-ed software systems, such as database maagemet systems,.net, J2EE (Java2 Platform, Eterprise Editio), or CORBA (commo object request broker architecture), objects, adapters to eterprise resource plaig (ERP) packages, itegratio brokers, ad others. Web services iterfaces receive a stadard XML message from the etworkig eviromet, trasform the XML data ito a format uderstood by a particular back-ed software system, ad, optioally, retur a reply message. The uderlyig software implemetatios of Web services ca be created by usig ay programmig laguage, operatig system, or middleware system. Figure 1-1. Web services iterface with back-ed systems. Web services combie the executio characteristics of programmatic applicatios with the abstractio characteristics of the Iteret. Today's Iteret techologies succeed i part because they are defied at a sufficietly high level of abstractio to eable compatibility with ay operatig system, hardware, or software. The Web services-based Iteret ifrastructure exploits this abstractio level ad icludes sematic iformatio associated with data. That is, Web services defie ot oly the data but also how to process the data ad map it ito ad out of uderlyig software applicatios. Web services combie programmig ad Web cocepts A Simple Example: Searchig for Iformatio Today, most services are ivoked over the Web by iputtig data ito HyperText Markup Laguage (HTML) forms ad sedig the data to the service, embedded withi a uiform resource locator (URL) strig: h This example illustrates how simple Web iteractios, such as a search, a stock purchase, or a request for drivig directios, are accessed over the Web by embeddig parameters ad keywords Page 8

10 i a URL. I this example, eterig a simple search request for Skate boots ito the Google search egie results i the URL show. The search keyword represets the service beig requested over the Web, whereas the Skate+boots keywords represet the search strig etered ito the HTML form displayed by the Google Web site. The Google search service the passes the request to a series of other search egies, which retur lists of URLs to pages with text matchig the search keywords Skate+boots. This iefficiet way of searchig the Web depeds etirely o matchig the give text strigs to cataloged HTML pages. XML provides a great may advatages for trasmittig data across the Iteret. Now the precedig request ca be cotaied i a XML documet istead: <SOAP-ENV:Body> <s:searchrequest xmls:s=" <p1>skate</p1> <p2>boots</p2> <p3>size 7.5</p3> </s:searchrequest> </SOAP-ENV:Body> XML is a better way to sed data Sedig the request withi a XML documet has may advatages, such as improved data typig ad structure, greater flexibility, ad extesibility. XML ca represet structured ad typed data the size field ca be typed as a decimal strig or as a floatig poit, for example ad ca cotai a larger amout of iformatio tha is possible withi a URL strig. Web services use XML documets This example is show i the form of a Simple Object Access Protocol (SOAP) message, a stadard form of XML messagig ad oe of the major eablig techologies i the Web services foudatio (see Chapter 4). I SOAP messages, the ame of the service request ad the iput parameters take the form of XML elemets. The example also illustrates the use of XML amespaces (xmls:), aother critical elemet of Web services (see Chapter 2). Because XML documets support data typig, complex structures, ad the associatio of XML schemas, moder Web services techology provides sigificat advatages over existig URL ad HTML capabilities for accessig software applicatios. The Next Geeratio of the Web The ext geeratio of the Web will be based o software-orieted iteractios Web services are aimed at puttig the vast global etwork of the Web, established for huma iteractio, to a etirely ew purpose. Software-orieted iteractios will automatically perform operatios that previously required maual itervetio, such as Searchig for ad buyig goods ad services at the best price Coordiatig travel tickets ad restaurat tables for a give date Page 9

11 Streamliig busiess procuremet, ivoicig, ad shippig operatios The ext geeratio of the Web will use software-orieted services to iteroperate directly with applicatios built usig ay combiatio of objects, programs, ad databases. But Web services are ot oly about iterfaces to objects, programs, middleware, ad databases for access over the Iteret. By combiig a series of Web services ito a larger iteractio, Web services also provide the meas to perform ew types of iteractios. Suppose, for istace, that you live i Sa Fracisco ad wish to reserve a table at your favorite Paris restaurat ad the make the ecessary travel arragemets to be there at the agreed time. Today, you would have to call the restaurat directly to get the reservatio, takig ito accout the 9-hour time differece ad the laguage differece, ad the call a travel aget to fid a compatible flight ad a hotel. But usig Web services, you could schedule the dier with your persoal digital assistat (PDA) caledar ad click o a butto to automatically reserve a table at a coveiet time. Oce the reservatio was made, the Web service could kick off other services that would book a cheap flight ad reserve a room at a earby four-star hotel. Web services eable ew types of iteractios Figure 1-2 shows how Web services ca iteract with a PDA coected to a wireless Web services processor to book a reservatio at a favorite restaurat, usig the restaurat's Web service. [1] The Web services processor accepts requests from the caledar fuctio of the PDA ad discovers Web services related to exteded caledar fuctios, such as reservig a restaurat table. After successfully reservig a table, the Web services processor cotacts Web services for hotel ad flight reservatios to complete the requested schedulig actio. [1] Throughout the book, the diamod-o-a-stick covetio is used to represet a Web services iterface. Figure 1-2. Applicatios ca use Web services to book a restaurat table ad make hotel ad flight reservatios. Page 10

12 Web services are also very useful for discoverig ad iteractig with Iteret sites that provide olie order etry systems, such as the oe for the Skateboots Compay's tredy skateboots a boot with a retractable ice skate built i like the oes that Batma ad Robi used i the movie Batma ad Robi. Sportig goods retailers iterested i stockig the boots, this year's hot ew item, ca use Web services to place advace bulk orders i batch, to check the status of a order, or to place i-seaso restockig orders ad be immediately otified of back orders, if the maufacturer is out of stock. Web services buildig blocks provide stadard compoets of the applicatio for the Skateboots Compay, which is't large eough to host its ow etire applicatio ifrastructure. Web services hostig compaies provide security services to esure that Skateboots accepts orders oly from approved retailers ad to provide credit validatio services for approvig bulk advace orders. Still other compaies help Skateboots by providig electroic fuds collectio ad accoutig services. Web services discover ad iteract with oe aother The etire Skateboots order etry system is exposed to the Iteret as a Web service, but behid the top-level Web service are a umber of other Web services workig together to provide the ecessary fuctioality. Figure 1-3 illustrates how Web services ca chage the way busiess applicatios are built ad used. The retailer iterested i stockig skateboots iputs a request to its local ivetory maagemet service, which is exposed to the shop computers as a Web service. The local ivetory service the cotacts the maufacturer's Web service over the Iteret ad seds the order for the correct umber of skateboots, based o available shelf space ad the most popular sizes. Figure 1-3. The Skateboots order etry service comprises several other Web services. Page 11

13 The Skateboots Compay's order etry system comprises multiple Web services, icludig a custom-built part that deals with the uique aspects of its product ad several commodity parts that take care of stadard fuctios, such as autheticatig the user, credit authorizatio, ad accoutig ad billig, all hosted by other compaies that specialize i providig such services over the Iteret. Creatig busiess applicatios usig Web services etails puttig ito proper relatioship a umber of other Web services, which ca be implemeted by usig ay combiatio of programmig laguage, operatig system, or packaged software, iside or outside the firewall. (This is also the way i which Web services solve the difficult EAI problem.) I establishig the proper relatioship, or flow, of related Web services, it also automates the correspodig busiess processes ad procedures. Through the widespread adoptio of Web services, the Iteret is becomig more efficiet, especially for busiess iteractios. I the ext geeratio of the Web, Web services buildig blocks will eable automatic Iteret iteractios, combiig direct access to software applicatios ad busiess documets, bypassig familiar text-based Web pages to access softwarebased data directly. Furthermore, fudametal Web services buildig blocks are very likely to be hosted ad published by a variety of compaies focusig o a specific fuctioal compoet, such as autheticatio, trasactioal coordiatio, or accoutig ad billig. This chage to direct applicatio-to-applicatio iteractio over the Web lies at the heart of Web services, what they mea, ad how they work. Web services create greater commercial efficiecies Toward a Commo Uderstadig Web services techology exists at a sufficietly high level of abstractio to support multiple simultaeous defiitios, which are sometimes cotradictory. At the simplest level, Web services ca be thought of as Iteret-orieted, text-based itegratio adapters. Ay data ca be mapped ito ad out of ASCII text, ad this type of mappig has log bee the lowest commo deomiator for graphical display systems ad database maagemet systems. If all else fails, the sayig goes, map the data to text. Text-based systems also are behid the success of the World Wide Web, o which the additioal abstractio of Web services is based. Ay computer or operatig system is capable of supportig HTML ad Web servers, ad browsers, ad whe they dowload files, they do't care or eve kow what type of back-ed systems they're iteractig with. The same is true for Web services, which ofte leads to a lot of cofusio whe developers of traditioal, or established, computig eviromets try to uderstad Web services techology i referece to a sigle type of distributed software system, such as CORBA, J2EE, or.net. Because Web services are much more abstract more like adapters tha they are like iterfaces it will be some time before the idustry settles o truly commo defiitios ad covetios for them. Iteractig with Web Services The level of abstractio at which Web services operate ecompasses such iteractio styles as RPC (remote procedure call) emulatio, asychroous messagig, oe-way messagig, broadcast, Page 12

14 ad publish/subscribe. Most major database maagemet systems, such as Oracle, SQL Server, ad DB2, support XML parsig ad trasformatio services, allowig direct iteractio betwee Web services ad database maagemet systems. Middleware vedors typically also provide a mappig of Web services to their software systems, such as applicatio servers ad itegratio brokers. To the user, therefore, iteractios with Web services ca appear as batch or olie iteractios, supportig sychroous or asychroous commuicatios patters, ad as user iterfaces writte usig Java programs, VB (Visual Basic) programs, office applicatios, browsers, or thick cliets to database maagemet systems, to ame a few, ad ca map dow to ay type of uderlyig software system. Web services support multiple messagig paradigms Web services stadards ad techologies geerally ecompass two major types of applicatio iteractio patters: Remote procedure call (olie) Documet orieted (batch) Web services ecompass RPC ad documet-orieted iteractios These two types of iteractios are described i the followig subsectios. RPC-Orieted Iteractios I RPC-orieted iteractios, the Web services request takes the form of a method or a procedure call with associated iput ad output parameters. I cotrast to the documet-orieted iteractio, the RPC-orieted iteractio seds a documet formatted specifically to be mapped to a sigle logical [2] program or database, as show i Figure 1-4. Because the "real-time" or i-seaso order for skateboots depeds o available ivetory, for example, the program accesses the database to check the available supply of the ordered item. If everythig is OK, the program returs a XML documet to the distributor i the request/respose format to idicate that the order has bee accepted ad will be shipped. If supply is't available, the retur message idicates a back order or rejects the order etirely. I cotrast to the documet-orieted iteractio style, the request ad the reply are modeled as sychroous messages. That is, the applicatio sedig the message waits for a respose. [2] A sigle logical program ca, of course, comprise multiple subprograms. Figure 1-4. This Web service supports a iteractive order request/respose. Page 13

15 RPC-orieted iteractios are good for brief data exchages Documet-Orieted Iteractios I the documet-orieted iteractio style, the Web service request takes the form of a complete XML documet that is iteded to be processed whole. For example, a Web service that submits a complete purchase order, such as a preseaso order for skateboots, would submit the etire bulk order to the maufacturer at oce, as show i Figure 1-5. This is like submittig a message to a queue for asychroous processig. The maufacturer would typically sed a or other form of ackowledgmet to the retailer to idicate that the order was received ad would be processed accordig to a predefied flow of executio. The flow might iclude such steps as checkig the database for previous orders from the same retailer to esure that it is ot exceedig its credit limit or agreed capacity or schedulig a ship date for the order. I a real process flow, of course, may more steps are likely before the order is shipped ad the ivoice set out, but the example shows oly the fial step: sedig the XML ivoice to the distributor for paymet after the order has bee shipped ad received. Figure 1-5. This Web service processes a complete purchase order. Page 14

16 The documet-orieted style is good for bulk data exchages Documet-orieted iteractios ofte assume that the parties to a Web services coversatio have agreed to share a commo busiess documet, such as a purchase order, a ship bill, or a ivoice. These parties are ofte idetified as tradig parters, or collaboratig parters. Tradig parters also typically agree o a commo process flow, or iteractio patter, for exchagig the shared documet, such as requirig a ackowledgmet o receipt of a purchase order, returig specific status iformatio i reply to a order query, or sedig a alert whe a order has bee shipped. Durig the executio of the busiess process, a complete documet might be exchaged. If the documet is already held i commo, fragmets of iformatio required to fill i specific sectios of the shared documet, such as purchase price or promised delivery date, might be exchaged. Tradig-parter agreemets determie required iteractios I the Skateboots Compay example, preseaso bulk orders are hadled by usig purchase orders submitted i batches accordig to predefied terms ad coditios that help the maufacturer pla capacity. Durig the seaso, immediate restockig orders are hadled by more iteractive services that deped o fillig orders from available ivetory ad that ca immediately idetify back orders. Thus Skateboots.com provides Web services supportig both major types of iteractio. Page 15

17 The two styles map well to sychroous/asychroous messagig paradigms The Techology of Web Services Programs that iteract with oe aother over the Web must be able to fid oe aother, discover iformatio allowig them to itercoect, figure out what the expected iteractio patters are a simple request/reply or more complicated process flow? ad egotiate such qualities of service as security, reliable messagig, ad trasactioal compositio. Some of these qualities of service are covered i existig techologies ad proposed stadards, but others are ot. I geeral, the Web services commuity is workig to meet all these requiremets, but it's a evolutioary process, much like the Web itself has bee. Web services ifrastructure ad stadards are beig desiged ad developed from the groud up to be extesible, such as XML ad HTML before them, so that whatever is itroduced i the short term ca cotiue to be used as ew stadards ad techologies emerge. Stadards defie how Web services are described, discovered, ad commuicate with oe aother The New Silver Bullet? Web services are sometimes portrayed as "silver-bullet" solutios to cotemporary computig problems, fillig the role previously played by the origial Web, relatioal databases, fourth-geeratio laguages, ad artificial itelligece. Ufortuately, Web services by themselves ca't solve much. Web services are a ew layer aother way of doig thigs but are ot a fudametal chage that replaces the eed for existig computig ifrastructure. This ew layer of techology performs a ew fuctio a ew way of workig but, most importatly, provides a itegratio mechaism defied at a higher level of abstractio. Web services are importat because they are capable of bridgig techology domais, ot because they replace ay existig techology. You could say that ewer laguages, such as Visual Basic, C#, C/C++ ad Java replace older laguages, such as COBOL ad FORTRAN, although a lot of programs i those laguages are still aroud, as are Web-services mappigs for them. Web services, like Web servers, are complemetary to, ot i coflict with, existig applicatios, programs, ad databases. Applicatio developmet cotiues to require Java, VB, ad C#. All that's ew is a way of trasformig data i ad out of programs ad applicatios, usig stadard XML data formats ad protocols to reach a ew level of iteroperability ad itegratio. Developers may have to take Web services ito accout whe desigig ad developig ew programs ad databases, but those programs ad databases will still be required behid Web services wrappers. Web services are ot executable thigs i ad of themselves; they rely o executable programs writte usig programmig laguages ad scripts. Web services defie a powerful layer of abstractio that ca be used to accomplish program-to-program iteractio, usig existig Web ifrastructure, but they are othig without a supportig ifrastructure. Web services require several related XML-based techologies to trasport ad to trasform data ito ad out of programs ad databases. Web services require the use of several related XML-based techologies Page 16

18 XML (Extesible Markup Laguage), the basic foudatio o which Web services are built provides a laguage for defiig data ad how to process it. XML represets a family of related specificatios published ad maitaied by the World Wide Web Cosortium (W3C) ad others. WSDL (Web Services Descriptio Laguage), a XML-based techology, defies Web services iterfaces, data ad message types, iteractio patters, ad protocol mappigs. SOAP (Simple Object Access Protocol), a collectio of XML-based techologies, defies a evelope for Web services commuicatio mappable to HTTP ad other trasports ad provides a serializatio format for trasmittig XML documets over a etwork ad a covetio for represetig RPC iteractios. UDDI (Uiversal Descriptio, Discovery, ad Itegratio), a Web services registry ad discovery mechaism, is used for storig ad categorizig busiess iformatio ad for retrievig poiters to Web services iterfaces. Usage Example The basic Web services stadards are used together. Oce the WSDL is obtaied from the UDDI or other locatio, a SOAP message is geerated for trasmissio to the remote site. Web services stadards are typically used together As show i Figure 1-6, a program submittig a documet to a Web service address uses a XML schema of a specific type, such as WSDL, to trasform data from its iput source a structured file i this example ad to produce a XML documet istace i the format cosistet with what the target Web service expects, as described i the same WSDL file. The WSDL file is used to defie both the iput ad the output data trasformatios. Figure 1-6. Web services use XML documets ad trasform them ito ad out of programs. Page 17

19 The sedig computer's SOAP processor trasforms the data from its ative format ito the predefied XML schema data types cotaied i the WSDL file for text, floatig poit, ad others, usig mappig tables. The mappig tables associate ative data types with correspodig XML schema data types. (Stadard mappigs are widely available for Java, Visual Basic, CORBA, ad other commoly used type systems. May XML mappig tools are available for defiig custom or special mappigs.) The receivig computer's SOAP processor performs the trasformatio i reverse, mappig from the XML schema data types to the correspodig ative data types. The URL, i widespread use o the Web, poits to a TCP (Trasmissio Cotrol Protocol) address cotaiig a Web resource. Web services schemas are a form of Web resource, cotaied i files accessible over the Iteret ad exposed to the Web usig the same mechaism as for dowloadig HTML files. The major differece betwee HTML file dowloadig ad accessig Web services resources is that Web services use XML rather tha HTML documets ad rely o associated techologies, such as schemas, trasformatio, ad validatio, to support remote commuicatio betwee applicatios. But the way i which Web services schemas are published ad dowloaded is the same: a HTTP operatio o a give URL. Web service descriptio files are typically posted usig URLs Whe it receives a documet, a Web service implemetatio must first parse the XML message ad validate the data, perform ay relevat quality-of-service checkig, such as eforcig security policies or tradig-parter agreemets, ad execute ay busiess process flow associated with the documet. The Web service at the fictioal skateboots.com Web site is located i the skateboots.com/order folder, which is what the URL poits to. [3] [3] A more geeric term, the Uiform Resource Idicator (URI), ofte appears i Web services specificatios i place of the URL. A URI is a categorical sytax term that icludes the Uiform Resource Locator (URL) ad the Uiform Resource Name Page 18

20 (URN). A URN is a ame that does ot referece a physical resource. I practice, there is little differece betwee URI ad URL. Web services use XML schemas to validate messages The Web services available at this Iteret address are idetified withi a public WDSL file that ca be dowloaded to the sedig computer ad used to geerate the message. The Skateboots Compay also posted a listig i the public UDDI directory, poitig to the same WSDL file, for customers who might discover the compay through the UDDI service. I geeral, ayoe wishig to iteract with the Web services that place or track orders for the Skateboots Compay over the Web must fid a way to obtai ad to use that particular WSDL file to geerate the message. Programs at the skateboots.com address provide a HTTP listeer associated with the Web services i order to recogize the XML messages set i the defied format. The programs iclude XML parsers ad trasformers ad map the data i the SOAP message ito the formats required by the Skateboots Compay order etry system. These techologies are eough to build, deploy, ad publish basic Web services. I fact, eve basic SOAP is eough. Other techologies are cotiually beig added to the expadig Web servic es framework as they emerge. These fudametal techologies are eough to support use of the Iteret for basic busiess commuicatio ad to bridge disparate IT domais, however; ad this form of Web iteractio is beig adopted very quickly. Web services techologies are evolvig from a basic framework Over time, as stadards for registry, discovery, ad quality of service mature, the visio of a ad hoc, dyamic busiess Web will start to take hold, ad Web services will begi to operate more like the curret Web, allowig compaies to fid ad to trade with oe aother purely by usig Iteret-style commuicatios. I the meatime, the basic Web services techologies ad stadards covered i this book are sufficiet for may solutios, such as itegratig disparate software domais J2EE ad.net, for example coectig to packaged applicatios, such as SAP ad PeopleSoft, ad submittig documets to predefied busiess process flows. XML: The Foudatio I the cotext of Web services, XML is used ot oly as the message format but also as the way i which the services are defied. Therefore, it is importat to kow a little bit about XML itself, especially withi the cotext of how it is used to defie ad to implemet Web services. XML is used for multiple purposes Reivetig the Wheel Some people say that Web services are reivetig the wheel because they share may characteristics with other distributed computig architectures, such as CORBA or Page 19

21 DCOM. Web services do share cosiderable commo groud with these ad other distributed computig architectures ad implemetatios, but there's also a good reaso for ivetig a ew architecture. The Web is established, ad to take advatage of this tremedous global etwork, the cocepts of distributed computig eed to be adapted. First, the Web is basically discoected; that is, coectios are trasiet ad temporary. Distributed computig services, such as security ad trasactios, traditioally deped o a trasport-level coectio ad have to be redesiged to provide equivalet fuctioality for the discoected Web. Secod, the Web assumes that parties ca coect without prior kowledge of oe aother, by followig URL liks ad observig a few basic rules. For Web services, this meas that ay cliet ca access Web services published by ayoe else, as log as the iformatio about the service the schema is available ad uderstadable ad XML processors are capable of geeratig messages coformig to the schema. Traditioal distributed computig techologies assume a much more tightly coupled relatioship betwee cliet ad server ad therefore caot iheretly take advatage of the existig World Wide Web. Because Web services adopt the publishig model of the Web, it's possible to wrap ad to publish a specific ed poit, or busiess operatio, usig a Web services iterface defiitio, without requirig a specific type of cliet for that ed poit. The paradigm shift that cliets ca develop ad itegrate later has may advatages i solvig the problem of eterprise itegratio. Purposes of XML XML was developed to overcome limitatios of HTML, especially to better support dyamic cotet creatio ad maagemet. HTML is fie for defiig ad maitaiig static cotet, but as the Web evolves toward a software-eabled platform, i which data has associated meaig, cotet eeds to be geerated ad digested dyamically. Usig XML, you ca defie ay umber of elemets that associate meaig with data; that is, you describe the data ad what to do with it by usig oe or more elemets created for the purpose. For example: <Compay> <CompayName regio="us"> Skateboots Maufacturig </CompayName> <address> <lie> 200 High Street </lie> <lie> Sprigfield, MA </lie> <Coutry> USA </Coutry> </address> <phoe> </phoe> </Compay> XML allows ay umber of elemets to be defied Page 20