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

22 I this example, XML allows you to defie ot oly elemets that describe the data but also structures that group related data. It's easy to imagie a search for elemets that match certai criteria, such as <Coutry> ad <phoe> for a give compay, or for all <Compay> elemets ad to retur a list of those etities idetifyig themselves as compaies o the Web. Furthermore, as metioed earlier, XML allows associated schemas to validate the data separately ad to describe other attributes ad qualities of the data, somethig completely impossible usig HTML. Of course, sigificat problems result from the great flexibility of XML. Because XML allows you to defie your ow elemets, it's very difficult to esure that everyoe uses the same elemets i the same way to mea the same thig. That's where the eed for mutually agreed o, cosistet cotet models comes i. XML schemas costrai flexibility Two parties exchagig XML data ca uderstad ad iterpret elemets i the same way oly if they share the same defiitios of what they are. If two parties that share a XML documet also share the same schema, they ca be sure to uderstad the meaig of the same elemet tags i the same way. This is exactly how Web services work. Techologies XML is a family of techologies: a data markup laguage, various cotet models, a likig model, a amespace model, ad various trasformatio mechaisms. The followig are sigificat members of the XML family used as the basis of Web services: XML v1.0: The rules for defiig elemets, attributes, ad tags eclosed withi a documet root elemet, providig a abstract data model ad serializatio format XML schema: XML documets that defie the data types, cotet, structure, ad allowed elemets i a associated XML documet; also used to describe sematic - processig istructios associated with documet elemets XML amespaces: The uiquely qualified ames for XML documet elemets ad applicatios Several members of the XML family are used i Web services The Future of the Web The ivetor of the World Wide Web, Tim Berers-Lee, has said that the ext geeratio of the Web will be about data, ot text; XML is to data what HTML is to text. The ext geeratio of the Web is iteded to address several shortcomigs of the existig Web, otably the difficulty searchig the Web for exact matches o text strigs embedded i Web pages. Because the Web has bee so successful, however, the future of the Web must be accomplished as a extesio, or a evolutio, of the curret Web. It's impossible to replace the etire thig ad start over! Solutios for applicatio-toapplicatio commuicatio must be derived from existig Iteret techologies. If the future of the Web depeds o its ability to support data commuicatios as Page 21

23 effectively ad easily as it supports text commuicatios, Web services eed to be able to refer dyamically to Web ed poits, or addresses (URLs), ad to map data to ad from XML trasparetly. These ed poits, or addresses, provide the services that process the XML data, i much the same way that browsers process HTML text. These addresses also ca be icluded i ay program capable of recogizig a URL ad parsig XML. Thus it will be possible to commuicate from your spreadsheet to a remote source of data or from your moey maagemet program to your bak accout maagemet applicatio, make appoitmets with colleagues for meetigs, ad so o. Microsoft ad others are already developig these kids of stadard services accessible from ay program, ad a large part of Microsoft's.NET strategy is focused o developmet tools for creatig ad stitchig together applicatios that use predefied Web services. But gettig this to happe requires sigificat stadardizatio, comparable to the effort ivolved i stadardizig PC compoets, ad might therefore ot happe for several years. XML Iformatio Set: A cosistet, abstract represetatio of the parts of a XML documet XPoiter: A poiter to a specific part of a documet; XPath, expressios for searchig XML documets; ad XLik, for searchig mulitple XML documets Extesible Stylesheet Laguage Trasformatios (XSLT): Trasformatio for XML documets ito other XML documet formats or for exportig ito o-xml formats DOM (Documet Object Model) ad SAX (Simple API for XML): Programmig libraries ad models for parsig XML documets, either by creatig a etire tree to be traversed or by readig ad respodig to XML elemets oe by oe These techologies ad others are described i further detail i Chapter 2. WSDL: Describig Web Services The Web Services Descriptio Laguage (WSDL) is a XML schema format that defies a extesible framework for describig Web services iterfaces. WSDL was developed primarily by Microsoft ad IBM ad was submitted to W3C by 25 compaies. [4] WSDL is at the heart of the Web services framework, providig a commo way i which to represet the data types passed i messages, the operatios to be performed o the messages, ad the mappig of the messages oto etwork trasports. [4] To date, 25 is the highest umber of compaies to joi ay W3C submissio. A submissio is a specificatio proposed for adoptio by W3C see WSDL is, like the rest of the Web services framework, desiged for use with both procedureorieted ad documet-orieted iteractios. As with the rest of the XML techologies, WSDL is so extesible ad has so may optios that esurig compatibility ad iteroperability across differig implemetatios may be difficult. If the seder ad the receiver of a message ca share ad uderstad the same WSDL file the same way, however, iteroperability ca be esured. WSDL is the XML format that describes what a Web service cosists of WSDL is divided ito three major elemets: Data type defiitios Page 22

24 Abstract operatios Service bidigs WSDL has three major elemets, accordig to level of abstractio Each major elemet ca be specified i a separate XML documet ad imported i various combiatios to create a fial Web services descriptio, or they ca all be defied together i a sigle documet. The data type defiitios determie the structure ad the cotet of the messages. Abstract operatios determie the operatios performed o the message cotet, ad service bidigs determie the etwork trasport that will carry the message to its destiatio. WSDL elemets ca be defied i separate documets Figure 1-7 shows the elemets of WSDL, layered accordig to their levels of abstractio, which are defied idepedetly of the trasport, specifically so that multiple trasports ca be used for the same service. For example, the same service might be accessible via SOAP over HTTP ad SOAP over JMS. Similarly, data type defiitios are placed i a separate sectio so that they ca be used by multiple services. Major WSDL elemets are broke ito subparts. Figure 1-7. WSDL cosists of three major elemets ad seve parts. The defiitio parts iclude data type defiitios, messages, ad abstract operatios, which are similar to iterface defiitios i CORBA or DCOM. Messages ca have multiple parts ad ca be defied for use with the procedure-orieted iteractio style, the documet-orieted iteractio style, or both. Through the abstractio layers, the same messages ca be defied ad used for Page 23

25 multiple port types. Like the other parts of WSDL, messages also iclude extesibility compoets for example, for icludig other message attributes. WSDL iterfaces are like CORBA or DCOM iterfaces WSDL data type defiitios are based o XML schemas, but aother, equivalet or similar type defiitio system ca be substituted. For example, CORBA Iterface Defiitio Laguage (IDL) data types could be used istead of XML schema data types. (If aother type defiitio system is used, however, both parties to a Web services iteractio must be able to uderstad it.) Web service data types are based o XML schemas but are extesible to ay other mechaism The service bidigs map the abstract messages ad operatios oto specific trasports, such as SOAP. The bidig extesibility compoets are used to iclude iformatio specific to SOAP ad other mappigs. Abstract defiitios ca be mapped to a variety of physical trasports. The WSDL specificatio icludes examples of SOAP oe-way mappigs for SMTP (Simple Mail Trasfer Protocol), SOAP RPC mappigs for HTTP, SOAP mappigs to HTTP GET ad POST, ad a mappig example for the MIME (multipurpose Iteret messagig extesios) multipart bidig for SOAP. Abstract messages ad operatios are mapped to specific trasports XML amespaces are used to esure the uiqueess of the XML elemet ames used i each of the three major WSDL elemets. Of course, whe the WSDL elemets are developed separately ad imported ito a sigle complete file, the amespaces used i the separate files must ot overlap. Associated schemas are used to validate both the WSDL file ad the messages ad operatios defied withi the WSDL file. Namespaces esure WSDL elemet ames' uiqueess It's safe to say that WSDL is likely to iclude may extesios, chages, ad additios as Web services mature. Like SOAP, WSDL is desiged as a extesible XML framework that ca easily be adapted to multiple data type mappigs, message type defiitios, operatios, ad trasports. For example, IETF (Iteret Egieerig Task Force) workig groups are proposig a ew protocol stadard Blocks Extesible Exchage Protocol (BEEP) to defie a useful coectioorieted trasport. (HTTP, by cotrast, is iheretly coectioless, makig it difficult to resolve quality-of-service problems at the trasport level.) Compaies iterested i usig Web services for iteral applicatio or itegratio may choose to exted WSDL to map to more traditioal protocols, such as DCOM or IIOP (Iteret Iter-Orb Protocol). SOAP: Accessig Web Services Page 24

26 So far, you have defied the data (XML) ad expressed the abstractio of the service ecessary to support the commuicatio ad processig of the message (WSDL). You ow eed to defie the way i which the message will be set from oe computer to aother ad so be available for processig at the target computer. The SOAP specificatio defies a messagig framework for exchagig formatted XML data across the Iteret. The messagig framework is simple, easy to develop, ad completely eutral with respect to operatig system, programmig laguage, or distributed computig platform. SOAP is iteded to provide a miimum level of trasport o top of which more complicated iteractios ad protocols ca be built. SOAP provides the commuicatio mechaism to coect Web services SOAP is fudametally a oe-way commuicatio model that esures that a coheret message is trasferred from seder to receiver, potetially icludig itermediaries that ca process part of or add to the message uit. The SOAP specificatio cotais covetios for adaptig its oe-way messagig for the request/respose paradigm popular i RPC-style commuicatios ad also defies how to trasmit complete XML documets. SOAP defies a optioal ecodig rule for data types, but the ed poits i a SOAP commuicatio ca decide o their ow ecodig rules through private agreemet. Commuicatio ofte uses literal, or ative XML, ecodig. SOAP is the XML way of defiig what iformatio gets set ad how As show i Figure 1-8, SOAP is desiged to provide a idepedet, abstract commuicatio protocol capable of bridgig, or coectig, two or more busiesses or two or more remote busiess sites. The coected systems ca be built usig ay combiatio of hardware ad software that supports Iteret access to existig systems such as.net ad J2EE. The existig systems typically also represet multiple ifrastructures ad packaged software products. SOAP ad the rest of the XML framework provide the meas for ay two or more busiess sites, marketplaces, or tradig parters to agree o a commo approach for exposig services to the Web. Figure 1-8. SOAP messages coect remote sites. Page 25

27 SOAP has several mai parts: Evelope: Defies the start ad the ed of the message Header: Cotais ay optioal attributes of the message used i processig the message, either at a itermediary poit or at the ultimate ed poit Body: Cotais the XML data comprisig the message beig set Attachmet: Cosists of oe or more documets attached to the mai message (SOAP with Attachmets oly) RPC iteractio: Defies how to model RPC-style iteractios with SOAP Ecodig: Defies how to represet simple ad complex data beig trasmitted i the message SOAP messages cotai a evelope, a header, ad a body Oly the evelope ad the body are required. UDDI: Publishig ad Discoverig Web Services After you have defied the data i the messages (XML), described the services that will receive ad process the message (WSDL), ad idetified the meas of sedig ad receivig the messages (SOAP), you eed a way to publish the service that you offer ad to fid the services that others offer ad that you may wat to use. This is the fuctio that UDDI (uiversal distributio, discovery, ad iteroperability) provides. Iside the Eterprise May compaies are explorig the potetial advatages of usig Web services both Page 26

28 iside ad outside the eterprise. This is aalagous to usig browsers ad Web servers iside the eterprise i iteral etworks. Existig iteral Web ifrastructure ca be put to good use i support of Web services style iteractios. Although ulikely to replace existig distributed computig eviromets, such as COM ad CORBA, Web services ca be a valuable supplemet to existig techologies. Sometimes, all you have is a HTTP or a SMTP coectio. Because they represet a completely eutral format that ca be used to achieve a ew level of iteroperability, Web services ca also be used to bridge across COM, CORBA, EJB, ad message queueig eviromets. Fially, because Web services use existig HTTP ifrastructure, the impact o system admiistrators is miimal compared to itroducig other distributed computig techologies ito a IT departmet. Performace is certaily a issue compared to more traditioal biary-orieted trasports ad protocols, but the potetial beefits outweigh the costs for may applicatios, ad performace issues ted to get solved over time, as they have bee for the origial Web. The UDDI framework defies a data model i XML ad SOAP applicatio programmig iterfaces (APIs) for registerig ad discoverig busiess iformatio, icludig the Web services a busiess publishes. UDDI is produced by a idepedet cosortium of vedors, fouded by Microsoft, IBM, ad Ariba, to develop a Iteret stadard for Web service descriptio registratio ad discovery. Microsoft, IBM, Hewlett-Packard, ad SAP are hostig the iitial deploymet of a public UDDI service, which is coceptually pattered after DNS, the Iteret domai ame service that traslates Iteret host ames ito TCP addresses. I reality, UDDI is much more like a replicated database service accessible over the Iteret. UDDI registers ad publishes Web service defiitios UDDI is similar i cocept to a Yellow Pages directory. Busiesses register their cotact iformatio, icludig such details as phoe ad fax umbers, postal address, ad Web site. Registratio icludes category iformatio for searchig, such as geographical locatio, idustry type code, busiess type, ad so o. Other busiesses ca search the iformatio registered i UDDI to fid suppliers for parts, caterig services, or auctios ad marketplaces. A busiess may also discover iformatio about specific Web services i the registry, typically fidig a URL for a WSDL file that poits to a supplier's Web service. UDDI is a directory of Web services Busiesses use SOAP to register themselves or others with UDDI; the the registry cliets use the query APIs to search registered iformatio to discover a tradig parter. A iitial query may retur several matches from which a sigle etry is chose. Oce a busiess etry is chose, a fial API call is made to obtai the specific cotact iformatio for the busiess. UDDI uses SOAP for registerig ad discoverig iformatio Figure 1-9 shows how a busiess would register Web service iformatio, alog with other, more traditioal cotact iformatio, with the UDDI registry. A busiess first geerates a WSDL file to describe the Web services supported by its SOAP processor (1) ad uses UDDI APIs to register Page 27

29 the iformatio with the repository (2). After a busiess submits its data to the registry, alog with other cotact iformatio, the registry etry cotais a URL that poits to the SOAP server site's WSDL or other XML schema file describig the Web service. Oce aother busiess's SOAP processor queries the registry (3) to obtai the WSDL or other schema (4), the cliet ca geerate the appropriate message (5) to sed to the specified operatio over the idetified protocol (6). Of course, both cliet ad server have to be able to agree o the same protocol i this example, SOAP over HTTP ad share the same uderstadig, or sematic defiitio of the service, which i this example is represeted via WSDL. With the widespread adoptio of these fudametal stadards, however, this commo uderstadig of WSDL seems esured. Figure 1-9. The UDDI repository ca be used to discover a Web service. XML for Busiess Collaboratio: ebxml Several additioal techologies, beyod what's provided i the basic Web services techologies, are required to support true busiess-to-busiess iteractio over the Web. The Electroic Busiess XML (ebxml) cosortium, for example, has defied a comprehesive set of specificatios for a idustrial-stregth usage patter for XML documet exchage amog tradig parters. The ebxml messagig specificatio is based o SOAP with Attachmets ad does ot use WSDL but does add several qualities of service, such as security, guarateed messagig, ad compliace with busiess process iteractio patters. The ebxml spec provides more tha basic Web services techologies The ebxml iitiative, the first phase of which eded i May 2001, was sposored by a iteratioal group established by the Uited Natios Ceter for Trade Facilitatio ad Electroic Busiess (UN/CEFACT) ad OASIS to research, develop, ad promote global stadards for the use of XML to facilitate the exchage of electroic busiess data. [5] The ebxml architecture begis with a busiess process ad iformatio model, maps the model to XML schemas, ad Page 28

30 defies requiremets for applicatios that process the documets ad exchage them amog tradig parters. [5] Although the origial ebxml effort eded i May 2001, work cotiues o specific OASIS (The Orgaizatio for the Advacemet of Structured Iformatio Stadards) ad UN/CEFACT committees to ehace ad further exted the origial ebxml specificatios. The ebxml spec defies XML use for cooperative busiess processes Web Services ad EDI versus ebxml Although electroic data iterchage (EDI) has bee aroud for more tha two decades, it is very complex, has multiple iterpretatios, requires sigificat techical expertise to deploy, ad is based o a tightly coupled, iflexible architecture. Although they ca be deployed o public etworks, EDI applicatios are most ofte used o expesive dedicated etworks ad require a lot of expertise to set up ad ru. By cotrast, ebxml ad Web services hold the promise of realizig the origial goals of EDI, makig it simpler ad easier to exchage electroic documets over the Iteret. However, ebxml ad Web services also will have to mature for several years before they ecompass all EDI's curret fuctioality ad feature set. Although the ebxml cosortium has completed its iitial work, OASIS, UN/CEFACT, ad other orgaizatios cotiue to promote the adoptio of the architecture ad specificatios to a broader audiece, hopig to establish a global e-busiess marketplace through the stadardized exchage of XML documets ad messages, regardless of geographic or political boudaries, ad with the qualities of service that busiesses expect. The ebxml architecture defies Busiess processes ad their associated messages ad cotet A registry ad discovery mechaism for publishig busiess process sequeces with related message exchages Compay profiles Tradig-parter agreemets A uiform message trasport layer mapped to SOAP with multipart MIME attachmets The ebxml architecture exteds basic Web services cocepts Similarly to the way i which UDDI facilitates a search for Web service defiitios, the ebxml architecture allows busiesses to fid oe aother by usig a registry, to defie tradig-parter agreemets, ad to exchage XML messages i support of busiess operatios. The goal is to allow all these activities to be performed automatically, without huma itervetio, over the Iteret. The ebxml architecture has may similarities to SOAP/WSDL/UDDI, ad some level of covergece is already takig place with the adoptio of SOAP i the ebxml trasport specificatio. [6] RosettaNet also aouced its adoptio of the ebxml trasport, as have may other vertical idustry cosortia. [6] See for further iformatio o ebxml's use of SOAP ad other details of the ebxml iitiative. Page 29

31 The ebxml registry allows busiesses to fid ad to collaborate with oe aother The ebxml architecture clearly ceters o documet-orieted iteractios; as ebxml gais acceptace, it may come to defie the paradigm for B2B-orieted Web service iteractios. Compaies that already have bee exchagig iformatio electroically, perhaps usig EDI stadards, will fid may parallels i the goals of ebxml, although ebxml aims at addressig this type of requiremet more broadly ad for the Iteret. The ebxml specificatio focuses o documet-orieted iteractios Compariso of ebxml ad SOAP Iitially, it seemed that the ebxml group was competig with the group of compaies sposorig SOAP, WSDL, ad UDDI. I fact, the ebxml specificatios cover a lot of the same territory as SOAP, WSDL, ad UDDI. You could view the SOAP effort at W3C as a "bottom-up" approach, startig with a defiitio of the way to map XML documets to HTTP messages, ad look at the ebxml effort as a "top-dow" approach, startig with a defiitio of the busiess process as a series of messages mapped to ay trasport. The ebxml group was formed primarily to create busiess process stadards, the areas i which the work of ebxml has the most promise. The areas of trasport, services descriptio, ad registry seem more appropriate to efforts focused more purely o issues of ifrastructure tha of busiess process ad documet iteractio. Oe of the major motivators for ebxml is to produce stadards that serve the same or similar purpose as EDI, icludig support for the emergig idustry-specific XML "vocabularies." It seems appropriate to cosider the ebxml architecture as requiremets o W3C ad other XML-orieted iitiatives as a way of esurig that Web services will be ready for real busiess use, rather tha as a competitive effort to defie core ifrastructure services. Web Services versus Other Techologies Web services are ot as much like traditioal distributed computig techologies such as CORBA, DCOM, ad EJB, as they are like Web servers, HTML, ad HTTP, o which they are based. Web services are fudametally oe-way, asychroous messages mapped oto executable software programs. Web services defie a data format idepedet of programmig laguage, operatig system, etwork trasport, ad data storage mechaism; therefore data has to be mapped ito ad out of the idepedet format. Data typig ad structure are abstracted from uderlyig implemetatios of services. Web services differ from traditioal distributed computig techologies Web services are ofte compared to remote procedure call ivocatios or software compoets. However, Web services are more appropriately compared to eterprise applicatio itegratio adapters. Web services defie a caoical message format, as EAI software systems, such as MQSeries, TIBCO, NEON, Vitria, ad IONA' s Orbix E2A, do ad defie the way i which the Page 30

32 message is directed to a service iterface through which the data is mapped or trasformed oto a uderlyig applicatio. I other words, the itelligece for uderstadig how to map a message ito a software program is ot cotaied withi the iterface itself, as it is i CORBA, J2EE, ad DCOM, all of which are based o RPC cocepts, which tightly couple the service ame to the program beig ivoked. Rather, that itelligece is cotaied withi the XML processor, which cosumes the message ad follows associated istructios o how to parse the message ad map the data ito whatever program implemets the Web service. Web services are more like adapters I additio, Web services do ot require or assume the existece of the same software system o both eds of a commuicatio path. EAI adapters similarly accept a caoical message format ad map the iformatio i the message to a eterprise resource plaig (ERP) or other type of eterprise applicatio. Web services are defied at a similar level of abstractio, which allows the same message type to be mapped to multiple applicatios, icludig, but certaily ot limited to, RPC-based compoets. Web services map to ay software Ulike RPC-orieted middleware, such as CORBA ad DCOM, Web services use uidirectioal, asychroous messagig, which is more aturally mapped to a message queuig system, such as MQSeries or JMS, tha to CORBA or DCOM; although, of course, Web services are also ofte mapped to CORBA-, J2EE-, ad DCOM-based products. Web services support a request/respose paradigm typical of sychroous, RPC-style commuicatios through emulatio; that is, the XML processor rather tha the protocol correlates requests with replies. The HTTP mappig of SOAP, for example, does ot support protocol-level request/reply correlatio. [7] The Web services emulatio of a RPC is easily mapped to such traditioal RPC-based systems as CORBA, EJB, ad DCOM, although qualities of service (e.g., security, trasactios, ad exceptio hadlig), are likely to be very differet from those available i traditioal distributed computig techologies, which are ofte tied closely to the trasport layer, ad are specific to each techology. [7] Various proposals address this issue, icludig HTTPR (reliable HTTP) ad BEEP, a ew sessio-orieted protocol from IETF; see Chapter 7 for further iformatio. Web services are fudametally oe-way, asychroous messagig systems Because iteractios with Web services are accomplished through the programs ad databases to which the Web services are mapped, the user experiece is likely to be very differet from a typical browser-based experiece: Web services are more like traditioal applicatios tha like browsers, although, of course, browsers may be used. (As metioed previously, Web services by themselves are ot executable but istead have to be mapped to a program, a object, a middleware system, or a database maagemet system.) Iteractig with Web services is like iteractig with traditioal applicatios Additioal Techologies Page 31

33 Core Web services techologies, such as SOAP, WSDL, ad UDDI, are useful for bridgig disparate techology domais ad submittig documets to busiess process flows. However, to become useful for more types of applicatios ad to fulfill the complete visio of Web services as eablig the use of applicatio buildig blocks over the Iteret, Web services techologies have to be exteded to ecompass additioal features, fuctios, ad qualities of service. The ogoig work of evolvig Web services toward a more useful techology substrate is very similar to the evolutio of the commo object request broker architecture, udertake by the Object Maagemet Group (OMG) durig the 1990s. The OMG work defied a comprehesive software architecture that guided a ope, collaborative effort that produced a rich set of specificatios for trasactios, asychroous messagig, security, failover, fault tolerace, ad so o. The same type of effort is beig iitiated at W3C for Web services, ad a similar architecture is evolvig. I the world of Web services, the major idustry software vedors have already agreed o the core stadards, which is the true test of stadardizatio. Microsoft, IBM, Su Microsystems, BEA Systems, Oracle, IONA, ad others have agreed o implemetig SOAP, WSDL, ad UDDI, although some differece of opiio remais o the role of the ebxml registry. However, other tha for the fudametal stadards, proposals ofte compete, such as the differece of opiio betwee Microsoft ad IBM o busiess process flow defiitio, that is, XLANG versus WSFL (Web Services Flow Laguage), ad competig proposals for hadlig security cotext. Additioal techol-ogies may or may ot become part of the stadard Additioal techologies are focused primarily i the followig key areas: Security Process flow Trasactios Messagig Some of the most importat additioal techologies for Web services ivolve security techologies. Security is importat to esure the cofidetiality ad itegrity of Web services data. No oe other tha the iteded recipiet of the data should be allowed to examie or to tamper with message cotets. Security also is ecessary to cotrol access to Web services, especially whe multiple Web services are used together, so that oly those for whom they are iteded use them. Security is most importat Proposed stadards exist for autheticatio ad authorizatio (SAML, or Security Authorizatio Markup Laguage) ad for public key maagemet for ecryptio (XKMS, or XML Key Maagemet Specificatio). Of course, fudametal to all Iteret security is Secure Socket Layer (SSL) ad, for HTTP-based protocols, HTTPS (secure HTTP) for basic ecryptio-level security. I additio to HTTPS, firewalls, SAML, XKMS, the use of digital sigatures, ad XML ecryptio, Microsoft has proposed WS-Licese for credetial maagemet ad WS-Security for propagatig security credetials associated with Web service iteractios. Page 32

34 Process flow is critical to automatig busiess process iteractios over the Web ad iside a eterprise. Process flow is also ofte called orchestratio because it defies the relatioship amog a series of iteractios ecessary to accomplish a give purpose, such as completig a purchase order, processig a travel reservatio, or executig a maufacturig pla. A flow is modeled as a sequece of steps defied for a give busiess process. The series of steps creates a aggregatio of fuctios for which a Web service iterface ca be defied. Flows automate busiess process executio I the world of automated busiess operatios, trasactios have log played the part of eforcer, esurig that the executio platforms produced cosistet results from a series of related operatios o data, despite software or hardware failures. These traditioal protocols ad techiques are ot directly applicable to the Web, however, as they are desiged for a tightly coupled eviromet i which it's possible to hold database locks pedig otificatio of the trasactio result ad i which a coectio-orieted protocol is available to detect commuicatio failures automatically. The Busiess Trasactio Protocol (BTP) proposal from OASIS is desiged to resolve this problem for Web services by defiig a loosely coupled protocol that esures that the results of multiple Web service iteractios are correctly propagated ad shared. Trasactios are beig redefied for the Web Messagig protocols execute the commuicatio patters defied for Web service iteractios, such as asychroous oe-way, request/respose, broadcast, ad coversatioal, or peer-to-peer. Additioal Web services techologies also may deped o the messagig layer for certai qualities of service, such as reliable or guarateed delivery, propagatio of security ad trasactio cotexts, ad correctly routig messages alog a defied path that icludes oe or more itermediaries. IBM has proposed reliable HTTP (HTTPR) to address requiremets i this area. Mechaisms for reliable messagig are eeded IBM ad Microsoft have collaborated o the WS-Ispectio proposal for discoverig iformatio about Web services available at a particular message target. Microsoft has also proposed WS- Referral ad WS-Routig to defie a specific message path for a Web service, icludig ay umber of itermediaries, ad how to route messages forward ad backward alog the specified route. The Blocks Extesible Exchage Protocol (BEEP) from IETF defies a coectio-orieted Iteret protocol. A SOAP mappig for BEEP has bee defied, ad i this case, SOAP messages iherit the additioal qualities of service from BEEP for maitaiig sessio cotext at the seder ad the receiver odes. The cotext ca be used to relate multiple messages ito a larger uit of trasfer ad to relate multiple messages as comig from the same source or iteded for the same target. Security ad trasactio cotext ca also be associated with a coectio. BEEP provides a coectio-orieted protocol Page 33

35 Other relevat stadards ad techologies iclude may of those defied by the followig orgaizatios: OASIS, hostig ogoig ebxml ad other related XML proposals, such as BTP ad SAML RosettaNet, ifluecer of Web services cocepts, developed by a group of electroics vedors for B2B busiess process flow iteractio over the Iteret UserLad, developer of XML-RPC, a precursor of SOAP OAGI (Ope Applicatios Group, Ic.), defiig caoical XML documet formats for busiess ad idustry May other techologies ad stadards are relevat to Web services The work of these ad other groups ofte focuses o promotig the adoptio of XML for specific busiess purposes, such as buildig o the base stadards to defie documet formats ad protocols for the electroics, fiacial, health care, ad other idustries. Because Web services are based o XML, the work of almost ay stadards body or cosortium promotig the use of XMLrelated techologies for Iteret busiess is relevat. Some of the other work, such as BTP ad SAML, emerges as cadidate techology for adoptio by W3C withi its Web services architecture activity. The Log Road Ahead Additioal techologies, such as security, trasactios, ad reliable messagig, curretly foud i existig distributed computig eviromets, have to be defied agai for Web services because of the fudametal shift ivolved i the ifrastructure XML ad HTTP o which they ow eed to be built. The World Wide Web Cosortium will udertake the effort to defie Web services architecture, just as OMG defied architecture for CORBA, although this is likely to be a very difficult ad dautig task. The W3C is ot set up to resolve major differeces of opiio amog its members, especially whe those differeces are motivated by commercial iterests. This is the dowfall of may stadards efforts, i fact. Vedor Approaches to Web Services Software vedors, both large ad small, are providig Web services implemetatios as product add-os or as etirely ew products. Web services do ot fudametally chage existig software systems, although they ca chage how software systems are put together. The differeces i implemetatio usually follow the differeces i philosophy, or approach, of the vedors: Are Web services a fudametal eablig techology? Or are they simply etry ad exit poits to ad from existig software systems? I other words, vedors vary i their approach to Web services, depedig o the extet to which they view Web services as impactig existig software system architectures. For example, do Web services ivalidate J2EE, or are they complemetary? The aswers to these ad other similar questios ca be discovered i a vedor's approach. Web services do ot chage the uderlyig software systems The five basic approaches to Web services are to map them Ito ad out of a database maagemet system Page 34

36 Ito ad out of a applicatio server Ito ad out of a itegratio broker Betwee techology domais To architectural software buildig blocks or fuctioal compoets I other words, Web services implemeters fudametally distiguish betwee Web services techologies ad uderlyig software implemetatios. Web services, therefore, are either icidetal aspects of existig software systems or a required part of the ifrastructure. Ca a applicatio server, object request broker, or database maagemet system successfully cotiue to exist without support for Web services? Or ca Web services exist o their ow? Thus the questio is, where does the value lie? With applicatio servers, database maagemet systems, ad itegratio brokers, leavig Web services to be merely a meas of mappig data ito ad out of existig software systems? Or does the value lie with the Web services themselves, as fudametal to a ew category of software systems? Value is either i the uderlyig software or i the Web services layer Vedor implemetatios ted to be divided amog these varyig views of the value of Web services. Not surprisigly, Microsoft has its ow view, whereas Su Microsystems, IBM, BEA Systems, Oracle, ad others are takig a alterative view. To some extet, this divergece of vedor views, or iitiatives, represets a cotiuatio of the Visual Basic/Java developer battle, but Microsoft is takig a very bold ad aggressive stace o Web services, eve breakig curret Visual Basic applicatios to esure that the future versio of VB will support Web services as fudametal eablig techology. The Java commuity is takig a less radical view, extedig Java APIs for Web services rather tha requirig a rewrite to icorporate them. Vedor views vary, ofte alog Java/Visual Basic lies Idustry busiess cosortia, such as ebxml ad OASIS, as well as itegratio broker products from such vedors as IBM, Microsoft, IONA, ad WebMethods, ted to focus o the busiess process, or documet-orieted type of applicatios for Web services. Other vedors' products, such as the Web services toolkits shipped with BEA's WebLogic ad IONA' s J2EE Editio, ted to focus o the RPC style of iteractio. The same XML-based techologies ad stadards ca geerally be used for either, but iitiatives ad products ted to focus o oe or the other because the paradigms are so differet. I geeral, applicatio servers ted to support the RPC style of iteractio, whereas itegratio brokers ted to support the asychroous documet-orieted style of iteractio. Products ted to focus o either the RPC or the asychroous style What Are Web Services Good For? The aswer to this questio may well vary by vedor, depedig o the particular approach to Web services implemetatio. Web services are geerally ot replacemets for ay existig techologies but rather are complemetary, aother tool i the toolbox, Page 35

37 as it were. Web services represet loosely coupled iteractios, which are better suited to itegratig disparate software domais ad bridgig icompatible techologies, rather tha heavy-duty, high-performace applicatios. Web services are also very good for submittig documets to log-ruig busiess process flows, which seem i ay case to be a good way to start with iteractios over the Iteret. Itegratio broker vedors, such as WebMethods, Vitria, SeeBeyod, Software AG, ad Mercator, typically view Web services as a extesio of classic eterprise ad busiess-to-busiess itegratio techologies ad have built adapters for Web services as they would build adapters for ay other techology with which their products have to itegrate. Other vedors, such as IONA, take a more eutral ad ecompassig view of Web services as both eablig techology for extedig existig applicatio server, CORBA, ad COM middleware ad as fudametal to the ext geeratio of eterprise ad busiess itegratio stadards. IONA's Orbix E2A product lie provides ot oly Web services adapters for asychroous, documet-orieted processig ad RPC-orieted Web services iterfaces for CORBA ad J2EE-compliat objects but also fudametal Web services buildig blocks. The IONA busiess process egie, XML coversio ad trasformatio egie, packaged applicatio adapters, ad busiess protocol framework all export Web service iterfaces. The IONA products support a cosistet approach to applicatio itegratio, usig Web services techologies iside ad outside the firewall. Fially, a umber of vedors view Web services as a iterestig ad potetially profitable techology i their ow right ad have developed "pure-play" Web services products. These products, based etirely o Web services techology, typically require use with other techologies ad products. For example, Cape Clear markets a Web services product aimed at bridgig J2EE ad.net. Shika markets a product that presumes that Web servic es are a fudametal desig ceter ad that programs will be developed to map ito them, rather tha vice versa, which is what most other vedors appear to believe. Some vedors focus purely o Web services Summary Web services are quickly becomig sigificat techology i the evolutio of the Web ad distributed computig. Web services leverage the data idepedece of XML to solve eterprise itegratio problems, both iside ad outside the firewall. Web service iterfaces are shells, or wrappers, that map to ay type of software program, middleware system, database maagemet system, or packaged applicatio. New types of applicatios are beig created by usig stadard Web services buildig blocks, thus creatig greater ecoomies of scale i automatig busiess ad cosumer iteractios with the Web ad with each other. Web services techologies are rapidly chagig, ad a log list of additioal features ad fuctioality is required to complete the visio. The basic Web services stadards SOAP, WSDL, ad UDDI are immediately useful for may applicatios, such as publishig iterfaces to automated busiess processes, bridgig disparate software domais, ad coectig wireless cliets to Web fuctios. The ebxml iitiative offers a alterative view of a XML-eabled distributed computig ifrastructure, specifically aimed at coectig busiess process iteractios amog Iteret tradig parters. ebxml represets a form of idustrial-stregth Web services, although ebxml does ot iclude WSDL or UDDI. May vedors view Web services ad ebxml as sigificat aspects to be added to their existig products; other vedors view Web services as sufficiet techology o which to base etire products. Page 36

38 Chapter 2. Describig Iformatio: XML The Extesible Markup Laguage (XML) is the foudatio o which Web services are built. XML provides the descriptio, storage, ad trasmissio format for data exchaged via Web services. XML also is used to create the Web services techologies that exchage the data. Web services are built o XML XML is similar to the Hypertext Markup Laguage (HTML), havig elemets, attributes, ad values. Well-formed XML documets ca be displayed i browsers, although this aspect of XML is ot relevat to Web services. HTML cotais a fiite set of elemets ad attributes, but XML allows ay umber of them to be defied. XML elemets ad attributes idepedetly defie type ad structure iformatio for the data they carry, icludig the capability to model data ad structure specific to a give software domai. (A software domai is a programmig laguage, a middleware system, a packaged applicatio, or a database maagemet system.) XML-aware programs ad tools parse, map, ad trasform geeric XML data types ito ad out of software domai specific types. Trasformig a geeric XML represetatio of data ito a applicatio, or a software domai specific represetatio of data, is a essetial aspect of Web services. XML defies data type ad structure The XML sytax used i Web services techologies specifies how data is geerically represeted, defies how ad with what qualities of service the data is trasmitted, ad details how the services are published ad discovered. Web services implemetatios decode these various bits of XML to iteract with the various applicatios ad software domais udereath the services. XML also defies trasmissio formats ad qualities of service Two broad categories of XML usage i Web services are (1) a data storage represetatio ad format ad (2) a specificatio of the software that maipulates the data. Although it origiated as a text markup laguage for documet processig, XML has become widely used for data formattig ad maipulatio. The XML commuity is therefore somewhat divided betwee those iterested i text formattig ad those iterested i data formattig, with the Web services commuity belogig firmly to the latter category. [1] [1] For a good descriptio of XML's use as a data-formattig laguage, see Essetial XML by Do Box, Aaro Skoard, ad Joh Lam. Much of the XML commuity is focused o data-formattig applicatios A Simple Example Page 37

39 For use i Web services, data ca be either created i XML or coverted to XML from oe or more "ative" or existig formats, such as ASCII or the Java type system. For a simple example, imagie that the Skateboots Compay's busiess aalysts idetified the followig basic data type iformatio required for a customer record i a ASCII file: Customer Number Iteger Customer Name Character Customer Address Character Customer Phoe Numeric Postal Code Character Credit limit Decimal Credit ratig Iteger Web services data ca be coverted ito XML (Obviously, a lot more iformatio would be ecessary for a real busiess.) After collectig the basic requiremets from the customer service departmet as show i the example, the aalysts formatted the data i XML, as follows: <Customer> <CustomerNumber>12345</CustomerNumber> <CustomerName>Joe's Boots</CustomerName> <CustomerAddress>500 High Street</CustomerAddress> <CustomerPhoe> </CustomerPhoe> <PostalCode>12345</PostalCode> <CreditLimit> </CreditLimit> <CreditRatig>5</CreditRatig> </Customer> The aalysts created a Customer elemet cotaiig the data items ad created XML elemet tags descriptive of the eclosed data items. However, the data is ot typed. After represetig the customer data as XML, the Skateboots Compay aalysts created the XML schema to validate the customer iformatio to esure that it would have the correct structure ad data types. Whe receivig customer data from a file, a program, or a database, the data ca be coverted ito XML, usig the iformatio cotaied i the schema. Whe XML documets are set to the compay from distributors, the schema ca validate that the correct customer data ad types have bee icluded i the documet. For example: <xsd:schema xmls:xsd=" <xsd:elemet ame="customer" type="customertype"/> <xsd:complextype ame="customertype"> <xsd:sequece> <xsd:elemet ame="customernumber" type="xsd:iteger"/> <xsd:elemet ame="customername" type="xsd:strig"/> <xsd:elemet ame="customeraddress" type="xsd:strig"/> <xsd:elemet ame="customerphoe" Page 38

40 type="xsd:strig"/> <xsd:elemet ame="postalcode" type="postalcodetype"/> <xsd:elemet ame="creditlimit" type="xsd:decimal"/> <xsd:elemet ame="creditratig" type="xsd:iteger"/> </xsd:sequece> </xsd:complextype> <xsd:simpletype ame="postalcodetype"> <xsd:restrictio base="xsd:strig"> <xsd:patter value="\d{ 5} \d{ 5} -\d{ 4} } "/> </xsd:restrictio> </xsd:simpletype> </xsd:schema> Defie the data ad the the associated schema The example illustrates a schema that defies validatio, data typig, ad documet structure for the customer record. The top declaratio of schema refereces the specific XML schema editio i use i this case, the May 2001 editio, refereced via the amespace This mechaism is used cosistetly by W3C to idetify applicable versios of its recommedatios, or stadards. Referecig this amespace meas that the schema i the example coforms to the May 2001 versio of the XML schema specificatio ad that the XML program hadlig the schema has to uderstad the May 2001 schema versio or geerate a error. Schemas validate the data The sample schema cotais both simple ad complex types ad illustrates the use of a sequece to establish the order of elemets. That is, i ay documet coformig to this schema, the CustomerName elemet must precede the CustomerNumber elemet, ad so o. The CustomerNumber must be a iteger, the CustomerName must be a strig, ad so o. Schemas feature simple ad complex data types The restrictio keyword requires the postal code to be iput as a strig. The PostalCodeType is a example of a data type defied withi the schema, a feature desiged to support the defiitio of special data types whe oe of the stadard defied types will do the job. The SOAP specificatio defies its ow array types, for example. Origial documet markup efforts, such as Ruoff, TeX, ad LaTeX, focused o embeddig commads withi the text to format the text ito paragraphs, bulleted lists, ad headigs ad to specify the place o the page for page umbers, ruig headers ad footers, ad so o. Later, especially with the advet of proportioal-spacig display ad prit techology, the commads Page 39

41 were desiged to be geeric eough so that the rederig ito type, page layouts, ad so o could be chaged dyamically without recodig the origial documet. I other words, a compay could decide to switch from a serif typeface, such as Times Roma, to a sas-serif typeface, such as Helvetica, without chagig the documet markup tags. Similarly, a documet could be formatted for both the U.S. stadard letter size ad the Europea stadard A4 size without recodig the file. [2] I Web services terms, this meas that the schema ca be chaged idepedetly of the istace documet ad the data reformatted accordig to the types ad structure i the chaged schema. [2] For a good overview of XML i the cotext of markup laguages, see Elizabeth Castro's XML for the World Wide Web. Schemas ca be chaged idepedetly of the data Istace ad Schema Because software domais traditioally have defied their ow data types ad structures, applicatio programmers wishig to iteroperate across software domais have had to format data accordig to the requiremets of each specific software domai ad to write programs to covert data from oe domai format to the other. With XML, however, programmers ca use a rich library of XML tools to trasform the data from ative formats to XML ad back agai. XML ca be used as a idepedet data type ad structure mechaism, elimiatig the may-to-may problem of mappig all domai data types ad structures. Programmers have to defie the mappigs oly from the particular domai to XML ad back agai. Schemas help trasform data ito ad out of XML format XML idepedetly stores data values withi descriptive elemet tags i a text-based istace of a documet. (Everythig is a documet i XML.) For example: <CustomerNumber>12345</CustomerNumber> XML provides data idepedece The <CustomerNumber> is the descriptive elemet tag, ad is the data value cotaied withi the elemet. XML elemets are eclosed i agle brackets (< >) ad have a start ad a ed. The ed is marked by a slash (/). Elemets that eclose oly attributes ca be self-edig, for example: <CustomerNumber Format="ay five digits" /> Elemets ca have oe or more attributes associated with the elemet ame, usig a ame/value pair for each attribute. For example: <CompayName CoutryOfOrigi="Irelad" PubliclyTraded ="Yes"> IONA Page 40

42 </CompayName> XML elemets ca have oe or more attributes Oe or more XML schemas, which too are istaces of XML documets, separately defie the types, structure, ad sematic meaig to be applied to the istace data cotaied withi the elemet tags. For example: <xsd:elemet ame="customernumber" type="xsd:iteger"/> The xsd prefix idetifies the elemet as a XML schema elemet with the ame CustomerNumber ad the type xsd:iteger, which is a schema simple type. Simple types ca be ay of the predefied XML schema types such as strig, iteger, double, float, date, ad time or XML specific types Etity, NMToke, ad ID. XML processors validate istace documets by matchig elemet ames declared i the schema with elemets i the istace documet. Elemets that are ot declared i the schema may be rejected as ivalid by the XML processor. As i HTML, however, XML processors ofte will parse ad accept what they ca uderstad ad validate, without ecessarily rejectig documets that cotai udeclared elemets, because a sigle istace documet might have multiple schemas associated with it for differet purposes. XML processors iput the data ad Schema Type ad structure are also associated with the istace documet by matchig the elemet ames i the istace documet to the elemet ames i the associated schema ad applyig the type ad structure iformatio declared i the schema, if ay. The simple data type i this example might map to a it i Java or C++ or to a COMP i COBOL, depedig o the particular software domai i use with the Web service. Matchig elemet ames with their defiitios associates type ad structure Simple types ca also be defied for a specific purpose i a documet. For example: <xsd:simpletype ame="postalcodetype"> <xsd:restrictio base="xsd:strig"> <xsd:patter value="\d{ 5} -\d{ 4} }"/> </xsd:restrictio> </xsd:simpletype> The simple type i this example is PostalCodeType ad is restricted to the XML schema type of xsd:strig with a patter requirig the ie-digit ZIP code format. (This would ot, of course, work for postal codes outside the Uited States.) Page 41

43 XML schema ComplexTypes model elemet cotet; that is, they determie the permissible set of elemets i a documet. ComplexTypes ca iherit from SimpleTypes, ad repeatig compoets ca be defied i Groups. The CustomerType elemet is a example of a complex type that restricts the childre of the Customer elemet to the defied list. Schemas are also ofte called "cotet models" for this reaso. Complex types model elemet cotet Data Type ad Programmig Laguage Traditioally, applicatio typig ad data structurig are cotaied withi a programmig laguage defiitio. The type iformatio refereces locatios i biary memory allocated by the operatig system o behalf of the program whe it executes. A programmig laguage views data through its ow specific set of data types, which are basically abstractios of the biary code used to physically store ad maipulate bits ad bytes. Programmig laguages provide data types cosistet with their desig ceters. COBOL, widely used i traditioal busiess applicatios, is rich i text data types ad processig capabilities. C/C++, widely used for operatig system utilities, is rich i low-level operatios, such as memory allocatio ad array poiters. XML breaks the associatio of data type ad programmig laguage XML represets a major shift i the way applicatios view data, especially commo data shared across multiple types of programs ad applicatios. XML stores all data as text, like the markup laguage it basically is. Programs that access XML map the data ito ad out of the text represetatio usig the associated type iformatio. Because the associated type iformatio is stored idepedetly, multiples are allowed ad ca be chaged idepedetly of the data. XML processors therefore map applicatio data ito ad out of XML, much as browsers map HTML ito a display, except that the target of the mappig for Web services is ot a graphical user iterface but rather a data file or a program. The XML processors match the elemet ames i the schema file to the elemet ames i the data file to apply the type ad structure iformatio. XML processors also have to uderstad special schema elemets that pertai to iterpretig the data, such as how to serialize the data for trasmissio over HTTP or map a SOAP message to a object method. For example, to specify that the SOAP ecodig style is to be used for data serializatio, the followig amespace [3] is icluded i a Web service documet: [3] This is the SOAP v1.1 ecodig amespace. See Chapter 4 for iformatio o the SOAP v1.2 amespaces. ecodigstyle= A XML istace ca be compared to the physical disk storage of data i a database maagemet system, ad the XML schema ca be compared to the SQL data descriptio laguage schema. Schemas i XML, however, have a broader applicatio tha those i SQL, also beig used to cotai istructios for how to maipulate the data ad how to format it for storage. XML schemas are comparable to SQL schemas Page 42

44 It is worth metioig agai i this cotext that XML has o fixed or fiite sytax: Schema elemets ca be defied to fit ay purpose, ot oly to format data. The SOAP specificatio, for example, creates XML schema elemets to defie how a XML processor produces ad cosumes istaces of data coformig to the SOAP schemas. XML processors the have to be created or modified to uderstad the sigificace of these special elemets, but that's what the world of XML ad Web services is all about. Markup Laguages Rule It's iterestig that the future of the Web is evolvig from a markup laguage rather tha from a programmig laguage. I part, this stems from the fact that o sigle operatig system, programmig laguage, middleware system, or database system is ever goig to be able to hadle everythig. The same abstractios that drove the popularity of programmig laguages ad software systems by makig biary data easy to work with i specific sytax structures also costrais them i solvig the problem of geeric iteroperability. The commo set, or itersectio, of data types amog COBOL, C/C++, Java, Visual Basic, C#, ad SQL, for example, is by defiitio less rich ad powerful tha the set of data types supported withi ay give oe of the laguages. The XML cotet model was developed so that a documet ad its appearace could be separated. Now it's beig used to separate data ad its relatioship to software programs. Separatig the defiitio of data ad its relatioship to software programs solves a big problem i the applicatio itegratio space. Traditioal software systems have teded to adopt their ow, uique mechaisms for data formattig, commuicatio, ad storage, as if o other programmig laguages existed, or as if the particular software system had maaged to solve the pereial problem of data abstractio oce ad for all. XML takes the mappig oe step further, so that programs have to map oly their ow specific data formats ito ad out of XML. Mappig everythig ito ad out of text is very ieffeciet i terms of both iteral hardware storage space ad processig speed. However, as we saw with the adoptio of the text-based Web, performace is ofte less of a issue tha raw capability. Ad i this case, because XML provides a solutio to a sigificat, previously uresolved problem of applicatio data itegratio, performace is truly a secodary issue. More o XML Schemas ad DTDs XML schemas were developed to resolve some of the limitatios ad problems with documet type defiitios (DTDs). For example, DTDs ca't describe data types, icludig complex or custom-defied data types, ad DTD defiitios are all global; that is, elemet ames ca't be duplicated, eve withi complex structures, as they ca be i schemas. DTDs are ot used for defiig Web services, so they are ot covered i detail. DTDs were developed to express a cotet model for XML documets, defiig valid elemets, attributes, ad some orderig costraits. Validatio of cotet i documet-orieted iteractios may still ofte be doe usig documet type defiitios, especially whe existig XML documets are trasmitted via Web services. Schemas were developed to improve o ad to replace DTDs Page 43

45 The followig examples illustrate the use of schemas ad DTDs i relatio to a commo istace of a simple purchase order documet. The documet istace is: <PurchaseOrder OrderDate=" "> <Cotact Coutry="US"> <Name>Joe's Sports, Ic.</Name> <Street>5555 High Street</Street> <City>Sprigfield</City> <State>CA</State> <Zip>95555</Zip> </Cotact> <LieItem> <SupplierName>Skateboots</SupplierName> <ProductName>Special Red Color</ProductName> <Quatity>10</Quatity> <UitPrice>150.00</UitPrice> </LieItem> <LieItem> <SupplierName>Skateboots</SupplierName> <ProductName>Cool Blue Boots</ProductName> <Quatity>5</Quatity> <UitPrice>195.00</UitPrice> </LieItem> </PurchaseOrder> Both schemas ad DTDs ca be used to validate istace documets The purchase order show i the example cotais the PurchaseOrder root elemet wellformed XML documets cotai a sigle root elemet withi which the rest of the elemets are eclosed ad several child elemets of PurchaseOrder, icludig Cotact ad LieItem. XML documets are represeted usig a hierarchical structure, i which elemets are ested, as SupplierName is ested withi LieItem. The schema defiitio is: <xsd:schema xmls:xsd="http: // xmls:po="skateboots.com/order" elemetformdefault="qualified" targetnamespace="skateboots.com/order"> <xsd:elemet ame="purchaseorder"> <xsd:complextype> <xsd:sequece> <xsd:elemet ame="cotact" type="po:cotacttype"/> <xsd:elemet ref="po:lieitem" maxoccurs="ubouded"/> </xsd:sequece> <xsd:attribute ame="orderdate" type="xsd:date"/> Page 44

46 </xsd:complextype> </xsd:elemet> <xsd:complextype ame="cotacttype"> <xsd:sequece> <xsd:elemet ame="name" type="xsd:strig"/> <xsd:elemet ame="street" type="xsd:strig"/> <xsd:elemet ame="city" type="xsd:strig"/> <xsd:elemet ame="state" type="xsd:strig"/> <xsd:elemet ame="zip" type="xsd:positiveiteger"/> </xsd:sequece> <xsd:attribute fixed="us" ame="coutry" type="xsd:nmtoken"/> </xsd:complextype> <xsd:elemet ame="lieitem"> <xsd:complextype> <xsd:sequece> <xsd:elemet ame="suppliername" type="xsd:strig"/> <xsd:elemet ame="productname" type="xsd:strig"/> <xsd:elemet ame="quatity" type="xsd:positiveiteger"/> <xsd:elemet ame="uitprice" type="xsd:decimal"/> </xsd:sequece> </xsd:complextype> </xsd:elemet> </xsd:schema> The example cotais the schema that validates the purchase order show i the previous example, esurig the proper data types for the elemets ad that the lie-item elemet has the proper structure. Such a schema esures the documet's coformace to the agreed-o format. Without such agreemet, it would be possible to receive documets that cotaied iformatio that was't recogized or was igored ad therefore could ot be processed correctly. Complex types, such as i this example, defie the ames of elemets permitted to appear i the associated documet ad use attributes to defie additioal costrait iformatio for the elemets. The schema refereces, withi the xsd:schema root elemet, the amespace for the May 2001 versio of the XML schema specificatios: <xsd:schema xmls:xsd=" xmls:po="skateboots.com/order" elemetformdefault="qualified" targetnamespace="skateboots.com/order"> The root elemet also cotais a attribute declarig the amespace for the purchase order documet itself xmls:po="skateboots.com/order" ad specifies that the default format for elemets is to be amespace qualified. Qualified elemet ames are also called QNames Page 45

47 The etire PurchaseOrder elemet is structured as a complex type eclosig sequeces for CotactType ad LieItem. These elemet ames are declared, refereced, ad amespace qualified, usig the po: prefix, withi the top-level elemet, PurchaseOrder. The specific simple types for other elemets are declared with-i their specific sequeces, such as xsd:strig for Name ad xsd:positiveiteger for Zip. The fixed attribute of the CotactType elemet limits, or restricts, the customer iformatio to a sigle coutry type, Uited States. The correspodig DTD is: <!ELEMENT PurchaseOrder (Cotact, LieItem+)> <!ATTLIST PurchaseOrder OrderDate CDATA #IMPLIED> <!ELEMENT Cotact (Name, Street, City, State, Zip)> <!ATTLIST Cotact Coutry CDATA #FIXED "US"> <!ELEMENT Name (#PCDATA)> <!ELEMENT Street (#PCDATA)> <!ELEMENT City (#PCDATA)> <!ELEMENT State (#PCDATA)> <!ELEMENT Zip (#PCDATA)> <!ELEMENT LieItem (SupplierName, ProductName, Quatity, UitPrice)> <!ELEMENT SupplierName (#PCDATA)> <!ELEMENT ProductName (#PCDATA)> <!ELEMENT Quatity (#PCDATA)> <!ELEMENT UitPrice (#PCDATA)> The example cotais a DTD for the same purchase order istace documet show previously. The DTD is a bit easier to defie for use i validatio tha the schema, but schemas provide better flexibility for defiig sematics. The DTD is simpler to uderstad ad use, especially for basic documet validatio. The declaratio of valid elemets for the associated istace documet is very straightforward, usig the!element tag i the DTD. DTDs are easier for validatio but limited for sematics Also, basic structural iformatio, such as the sequece of elemets cotaied withi aother elemet, is very straightforward to defie. For example: <!ELEMENT LieItem (SupplierName, ProductName, Quatity, UitPrice)> Alteratives to Schemas XML schemas are relatively ew ad somewhat uusual amog W3C specificatios i that the W3C iitiated the work from scratch. May other W3C iitiatives, such as XML, SOAP, ad WSDL, were started by small groups of idividuals or compaies seekig to develop a solutio to a particular problem. Later, the members of the group Page 46

48 submitted the material to the W3C for possible adoptio. Schemas, o the other had have take a relatively log time to develop ad are fairly difficult to uderstad, at least i their etirety. May W3C members, icludig some of the origial authors of XML, such as James Clark, feel that the result is much too complex, is difficult to lear ad use, ad did ot meet the origial goals for simplicity. Several alteratives to schemas have bee proposed, ad DTDs remai i widespread use for validatio, despite the fact that schemas are iteded to replace them. For applicatios other tha documet validatio, however, schemas are the laguage of choice, ad that's why Web services techologies are defied usig schemas. This elemet declaratio idicates that SupplierName, ProductName, Quatity, ad UitPrice are required sub-elemets of LieItem. However, o data type iformatio is available for documet type defiitios, amespaces are ot used, ad very limited structure iformatio is available, makig schemas required for most Web services applicatios. [4] As metioed previously, the oe place a DTD is likely to be used is for simple documet validatio, whe a Web service iteractio seds a complete documet such as this purchase order. [4] Schemas are iteded to replace DTDs ad do, i fact, subsume all DTD fuctioality. Processig XML Documets The two most popular programmig APIs for parsig XML are the documet object model (DOM) from W3C [5] ad the Simple API for XML (SAX), which was collaboratively developed ad is maitaied by the members of the XML-DEV mailig list. [6] [5] See [6] See DOM ad SAX APIs allow parsig XML documets The major differece betwee SAX ad DOM is that the DOM API provides a geeric object model to represet the structure of documets ad a stadard set of iterfaces for traversig ad maipulatig them. Although vedors are free to use ay data structures to support the stadard DOM iterfaces, most popular DOM implemetatios work oly i mai memory. The SAX API, o the other had, works by firig callback evets ito the applicatio as the documet is parsed, elemet by elemet. SAX reads through oce; DOM supports multiple traversals The SAX approach uses less memory ad is more efficiet for messagig ad trasformatio, whereas the DOM API allows multiple passes through the documet, usig it more like a imemory database, or a repository that ca be searched multiple times. I other words, if you're parsig the documet oly to do oe thig with it, such as map it to a existig software program or database, SAX is probably more efficiet. But if you're usig the Page 47

49 documet as a cotiuig source of data or as somethig with which to iteract several times, DOM makes more sese. SAX ad DOM implemetatios are freely available for Microsoft ad Java programmig eviromets ad are easily obtaiable for other traditioal or more specialized programmig eviromets. Basic XML hadlig is therefore becomig a commodity. XML parsers are commodities Examples of DOM iterfaces are Node, Elemet, ad Documet. Everythig i the documet object model is cosidered a ode, but some odes are also called documet elemets. For example, the root elemet is called the root elemet ode ad a documet elemet. May more operatios ad iterfaces are available i the complete list of DOM iterfaces. The followig text cotais a few simple examples: DOM APIs assume a hierarchical documet model Node iterface examples: +getparetnode() +getchildnodes() Elemet iterface examples: +getattributens() +setattributens() Documet iterface examples: +createelemet() +createattribute() Sample SAX operatios show i the followig example are from the CotetHadler, XMLReader, ad Attributes iterfaces: CotetHadler iterface examples: +startdocumet() +startelemet() XMLReader iterface examples: +getproperty() +setproperty() Attributes iterface examples: +getvalue() +gettype() SAX APIs read through the documet ad process evets Both SAX ad DOM iterfaces ca be mixed i a sigle program. Together, they provide XML processors with the capability to process documets liearly with greater efficiecy ad as a hierarchical iformatio resource for multiple passes. Page 48

50 Namespaces Oce you have multiple XML documets, you eed a way to scope elemet ames withi each respective documet. Namespaces provide that mechaism ad are also used for other purposes. Namespaces scope, or qualify, elemet ames XML amespaces create uique prefixes for elemets i separate documets or applicatios that are used together. Namespaces are also sometimes used as uique keywords that idicate specific processig sematics to be iterpreted whe the documets are processed. Namespaces are used primarily to avoid problems that might be caused if the same elemet ame appears i multiple related documets or documet fragmets. This is a sigificat issue for Web services, as they ofte ivolve hadlig multiple related documets at the same time. For example, a basic Web services iteractio has at least four related documets: The istace documet message carryig the data The SOAP evelope schema defiig the message format The WSDL istace documet describig the iterface The WSDL schema validatig the iterface defiitio Namespaces avoid amig clashes whe multiple documets are processed Depedig o the use of other optioal techologies, there ca easily be may more documets, each distiguished usig its ow amespace. Some amespaces will be give to you, but others you will have to make up. Namespaces are usually modeled as uiform resource idicators (URIs) [7] i the familiar format of the Web. For example: [7] URIs iclude uiform resource locators (URLs), which poit to files ad other Web resources, ad uiform resource ames (URNs), which are simply ames ad do't poit to aythig. I practice, however, URIs ca be cosidered equivalet to URLs. xmls:mys=" Web services techologies typically iclude amespaces This example assigs the prefix mys shorthad for "my amespace" to a amespace derived from the xmlbus.com URI. By usig a amespace prefix, each elemet ame cosists of ot oly the local ame defied withi the documet itself but also the amespace URI. The full elemet ame icludes the amespace URI, whatever it is, whe amespaces are used. Prefixes are used to shorte the amespace URI whe it eeds to be refereced withi the documet. URIs are recommeded but ot required for use i amespaces. URIs are likely to be uique because they typically iclude host ames that are registered with DNS. However, XML parsers Page 49

51 do ot validate the amespace URIs ad do ot check uiqueess. You ca make up ad use ay strig of characters that you wat. For exteral use, that is, over the Iteret, it makes sese to stick with Iteret covetios, such as the uique URI-based ame. [8] However, if you are merely testig or usig Web services i a local area etwork or other cotrolled eviromet, you ca certaily be more free ad flexible with what you use for a amespace strig. [8] Uiversally uique idetifiers (UUIDs) are other good cadidates for esurig amespace uiqueess. URIs are recommeded for amespaces Namespaces also ca be used to idicate a requiremet for a certai behavior to the XML processor. Whe the SOAP ecodig amespace appears i a SOAP message, for example, the SOAP processor kows that it has to use the ecodig mechaism described i the SOAP specificatio for serializig ad deserializig the message. Namespaces ca also idicate sematics A amespace URI is ormally simply a idetifier iteded to be uique for the purpose of qualifyig the elemet ames withi the XML documet i which the amespace is used. However, if somethig at the ed poit is refereced by the amespace URI, it is possible to retrieve it ad to use it for validatig the documet, which may also be a XML schema, as URIs poit to Web resources. The idea of placig a schema at the ed poit refereced by a URI is that the schema ca cotai additioal iformatio about the elemet ames withi a amespace for example, to help validate them or to defie their data types. Namespace URIs ca referece schemas Namespace Referece Ambiguity Havig amespace URIs referece files i which schemas are stored leads to ambiguity: Is somethig there or ot whe you're processig the XML file? If there is, how do you recocile what's there with what's defied i the curret XML documet ad/or other associated schemas ad DTDs? XML processors dealig with Web services techologies eed to be able to hadle either situatio successfully. Namespaces are ofte used at the highest-level elemet possible so that their scope is as broad as possible. However, amespaces ca be used o a elemet at ay level. For example: <sktb:boot xmls:sktb= Namespaces ca be used at ay elemet depth Page 50

52 I this example, boot is the XML elemet ame, ad xmls is the amespace costruct idetifyig the prefix sktb as a amespace for the elemet ame; thus the amespace URI becomes part of the elemet ame. The amespace URI is but it could just as easily have bee 1234:abcdefg or aythig else. The amespace qualifies all elemet ames withi the elemet for which it's defied, meaig that the best use of them is typically at the highest level, or overall eclosig elemet. Namespace-aware tools deal correctly with amespaces, but older DOM-orieted tools propagate amespaces simply as attributes of the elemets. Some Web services use the amespace costruct as shorthad to referece the locatio of methods to be executed. For example: <p:getorderstatus xmls:p=" <OrderID>12345</OrderID> </p:getorderstatus> Namespaces ca idicate the locatio of executable programs I this way, you ca associate a URI with a Java object, which i this example is the OrderEtry object. The iput parameter is icluded withi the eclosig elemet (<OrderID>). The service ame is icluded i the amespace ad therefore also uique to the amespace via its prefix referece i the elemet ame <p>. Trasformatio Because XML documet istaces ca have multiple associated schemas, it's importat to be able to map ad the trasform a documet istace from oe schema format to aother. May vedors offer such mappig tools, usually based o the Extesible Stylesheet Laguage: Trasformatios (XSLT) specificatio. Trasformatio amog multiple documet formats is ofte required Mappig data for compatible schema istaces allows documet istaces to be trasformed from oe applicatio-specific format to aother. Of course, this meas that a commo uderstadig of the same cotets of a documet is possible, eve whe it's formatted or structured differetly. [9] [9] Some efforts are uder way at W3C to address this issue formally: the XML Iformatio Set ad Caoical XML. The XML Iformatio Set specificatio defies a cosistet list of XML documet parts, ad Caoical XML defies a way to reduce a XML documet to its essece so that two documets with idetical cotets but differet structures ad elemets ca be compared. XSLT is typically used to trasform oe XML format to aother Page 51

53 The problem of covertig ative data to XML is typically hadled by usig proprietary extesios to trasformatio egies, such as IONA's XML coverter. These tools work very much like XML trasformatio but allow the iput documet to be i a ative data format, such as ASCII or SQL. The output documet is still XML. I fact, XSLT ca be used with ative data formats as log as someoe writes a custom parser for that ative data format ad makes it appear to the XSLT egie as if it were i XML format. Trasformatio amog multiple stadard message formats for Web services is as importat as coversio betwee EBCDIC ad ASCII is for file trasfer operatios. Mappig tools covert ative data to XML XSLT XML uites the worlds of documets ad data, ad trasformatio techology is eeded for both worlds: to put data ito documets ad vice versa ad to trasform oe documet format to aother. XSLT emerged partly as a refiemet o how to separate text from its presetatio, such as displayig oe documet o both a PC browser ad a Wireless Applicatio Protocol (WAP see phoe. I additio, XSLT was desiged to support mappig data betwee XML formats. XSLT is a trasformatio techology XSLT is part of XSL (Extesible Stylesheet Laguage), which was developed to trasform XML documets ito presetatio formats for scree, paper, or spoke word. XSLT has broader applicatio for Web services, especially i trasformig oe form of XML to aother. Extesible style sheets are the foudatio of trasformatio As with may of the markup-laguage techologies described i this book, the cotet of a documet eeds to be separated from its format. Therefore XSL was split ito XSLT ad XSL-FO (Formattig Objects). Luckily, Web services are ot cocered with formattig XML for text or voice, ad we ca focus o XSLT. May applicatios of XSLT use Cascadig Style Sheets (CSS) to specify how to display a XML documet, although this popular applicatio of trasformatio techologies is ot directly relevat to Web services. Trasformatio origiated i the separatio of cotet ad format XSLT requires a parser. Either the DOM or the SAX parser ca be used, although a SAX parser is typically used to create its DOM structure, which is a ode tree structure much like the result of a DOM parsig operatio. XSLT defies a commo set of trasformatio rules for mappig the ode structure ito somethig else. XSLT applies a XSLT style sheet to a XML documet i order to produce the output documet as a trasformatio of the iput documet. This is the same Page 52

54 way XML is trasformed to HT ML; aother documet is simply a differet kid of target for the trasformatio. XSLT works with both DOM ad SAX XSLT implemetatios are typically called XLST processors. Microsoft provides oe, ad Saxo is a ope source Java implemetatio by Michael Kay. [10] XSLT evolved from Documet Style Sematics ad Specificatio Laguage (DSSSL), a techology related to Stadard Geeralized Markup Laguage (SGML). This parallels the evolutio of SGML ito HTML ad XML, i which separatio of cotet from presetatio was a importat goal. [10] See for further iformatio o this ope source project. A good book o XSLT is Michael Kay's XSLT Programmer's Referece. XSLT processors are readily available Oce you achieve this kid of separatio, you have to have a way to map cotet to multiple presetatio formats. Thus the focus o style sheets ad declarative rather tha procedural laguages was foud more appropriate to the trasformatio of structured data ito multiple formats. Schemas or DTDs ca be used to covert from oe documet istace format to the other, although Web services techologies use schemas. If you eed to covert a documet istace from oe schema format to aother, you ca use XSLT to do the trasformatio. Trasformatio maps betwee schema defiitios XSLT style sheets defie rules for trasformig a iput documet ito a output documet ad ca be used to covert ay type of XML documet to ay other. XSLT is also capable of callig out to a program ad passig data from the documet to the program. Fially, XSLT ca geerate a output documet i formats other tha XML, such as ASCII text or SQL schema. XPath While XSLT was beig developed at W3C, a requiremet for a expressio laguage to select parts of a documet for trasformatio was idetified. At the same time, the XPoiter effort was developig a expressio laguage for likig multiple XML documets. Rather tha develop separate expressio laguages, W3C decided to combie the two; the result was XPath (see XPath provides search expressios to select documet parts Page 53

55 XPath is ofte used with XSLT to defie search expressios that locate documet elemets to be used i the trasformatio. But XPath ca also be used idepedetly to lik multiple documets, usig specific expressios ad search paths. XPath defies basic search expressios, calculatios, ad strig maipulatios XPath, as a sublaguage withi a XSLT style sheet, is used for umeric calculatios or strig maipulatios or for evaluatig Boolea expressios. XPath defies the documet path used to select elemets for trasformatio. See the A Simple Example (Revisited) sectio for a complete XSLT style sheet. Documet Structure The hierarchical structure of XML is oe of its key characteristics. Oe of the major requiremets of Web services is to recogize the hierarchical ature of XML ad map existig data ito XML structures ad to trasform data amog multiple XML formats. Coversio from ative data to XML aother major requiremet of Web services is beyod the scope of XSLT ad is typically hadled by usig proprietary products, such as IONA's coverter/mapper tool. A XML documet is always required as iput to a XSLT operatio. XML documets are structured as hierarchies Figure 2-1 illustrates the hierarchical tree structure of a XML documet. Each documet has a root ad a top-level elemet that ecloses the rest of the documet. Elemets withi the top-level elemet i the diagram PurchaseOrder, i this case ca have subelemets, as depicted with a the asterisk (*). Elemets that do ot have subelemets are illustrated usig the data type of the elemet ad the data of the elemet. The elemet ame is put ito a leaf ode uder which is placed the elemet type ad value, if ay. Figure 2-1. A XML documet has a tree structure. Page 54

56 Parsers read through the XML documet ad create a tree structure like this i memory for XML programs to access. XSLT reads through the documet structure ad icludes processig istructios, attributes, expressios, ad so o, to produce a ew documet with a ew structure for example, trasformig the date elemet ito a Java or SQL date data type, if such a mappig were defied. As show i Figure 2-2, the structure of the target documet ca be differet from that of the origial documet. I this case, for example, imagie that the XSLT rules defie that oly the customer data is to be extracted ad moved to the ew documet. Trasformatios therefore represet a importat techology for combiig multiple Web services ito a larger applicatio, sice Web services exchage XML documets of varyig structure ad cotet. Figure 2-2. XML documets ca be trasformed or mapped oto differet structures. Page 55

57 Target documets ca be structured differetly If two or more documets are merged, perhaps to aggregate multiple orders from the same customer, or multiple elemets are to be icluded from two or more services that cotai the same elemet ames, amespaces are used to distiguish betwee them. Namespaces play a importat role i XSLT because elemets i the iput ad output documets might be the same but have differet meaigs or pertai to differet XML applicatios. Namespaces allow the XSLT processor to mix tags from differet XML applicatios i the same documet uambiguously ad to produce correct results. Multiple documets use amespaces to avoid amig clashes As compaies icreasigly use XML for iteral data represetatio, as more ad more ERP systems export XML formats, ad as more ad more XML vocabularies are defied by stadards bodies, the requiremet for trasformatio will icrease. Also, the ability to extract iformatio from XML documets is likely to be very popular, such as extractig the relevat lies from a purchase order or fittig together a Web services iteractio cotaiig partial data ito a larger documet cotext. All this ca be accomplished via trasformatio techology, of which XSLT is the leadig implemetatio. Trasformatio requiremets are likely to icrease Mappig Tools May tools are available for editig XML documets, covertig data to ad from XML, trasformig documets from oe XML format to aother XML format, ad storig, retrievig, ad searchig XML documets. [11] Figure 2-3 shows a complex purchase order documet beig trasformed, or mapped, from its origial format to a ew format. [11] For a good startig poit, check Figure 2-3. IONA's XML trasformatio tool ca map a complex purchase order. Page 56

58 May vedors offer mappig tools for coversio ad trasformatio The object of this sample mappig exercise is to relate data items from a compay's geeric purchase order schema to a specific, exterally accepted schema, such as Commerce Oe's. The result of the mappig exercise is a geerated XSLT style sheet that ca trasform a istace documet coformig to the origial purchase order ito a istace documet coformig to the Commerce Oe purchase order format. The trasformatio from oe schema format to aother is therefore accomplished i stages: The mappig betwee the two schemas is idetified, a style sheet is geerated, ad, fially, the ew istace documet is produced as a result of executig the trasformatio. A Simple Example (Revisited) The followig example cotais a XSLT style sheet that trasforms the XML documet from the Skateboots Compay simple customer example back to its origial ASCII text: Trasformig from XML to ASCII <?xml versio="1.0"?> - <xsl:stylesheet xmls:xsl=" versio="1.0"> Page 57

59 <xsl:output method="text" idet="yes" /> - <xsl:template match="*"> <xsl:apply-templates /> </xsl:template> - <xsl:template match="customernumber"> CustomerNumber: <xsl:value-of select="." /> </xsl:template> - <xsl:template match="customername"> CustomerName: <xsl:value-of select="." /> </xsl:template> - <xsl:template match="customeraddress"> CustomerAddress: <xsl:value-of select="." /> </xsl:template> - <xsl:template match="customerphoe"> CustomerPhoe: <xsl:value-of select="." /> </xsl:template> - <xsl:template match="postalcode"> PostalCode: <xsl:value-of select="." /> </xsl:template> - <xsl:template match="creditlimit"> CreditLimit: <xsl:value-of select="." /> </xsl:template> - <xsl:template match="creditratig"> CreditRatig: <xsl:value-of select="." /> </xsl:template> </xsl:stylesheet> The simple XSLT style sheet show i the example is used as the XSLT processor reads through the iput XML documet show, as i the A Simple Example sectio. The xsl:template match="*" istructio asks the XSLT processor to match all odes or elemets i the documet. The xsl:apply-templates istructio causes the elemet childre to be processed: i this case, all child elemets of the documet root. Whe a elemet match occurs betwee the iput documet ad the style sheet declaratios, the followig XPath expressio selects the text value from the elemet cotets: xsl:value-of select=".". The period i the expressio is the XPath operator, which idicates that the text value of the elemet is to be extracted. At the top of the style sheet, the output method was defied to be text. Style sheets are iput to the trasformatio process The output i the followig example is the ASCII output from usig XSLT to apply the precedig trasformatio style sheet to the XML example i the A Simple Example sectio: Trasformatio output ca be XML, ASCII, or aother format Page 58

60 CustomerNumber: CustomerName: Joe's Boots CustomerAddress: 500 High Street CustomerPhoe: PostalCode: CreditLimit: CreditRatig: 5 Trasformatio techology is also capable of callig out to such programs as Java beas ad classes. XML Specificatios ad Iformatio XML i geeral is represeted by a set of specificatios published by the World Wide Web Cosortium (W3C). May applicatios utilities, documet formats, ad tools icorporate oe or more of these specificatios. Two aspects of XML are of primary importace to Web services: the XML data represetatio format, or istace of the data, ad the associated schemas that defie sematics for the data. However, may other XML-related techologies are of iterest ad sigificace to Web services ad are icorporated ito Web services techologies ad the XML programs ad tools that implemet them. XML is used for a wide variety of applicatios XML Specificatios Related to Web Services The followig XML specificatios are related to Web services: Extesible Markup Laguage 1.0 ( The basic specificatio, first published i February 1988; secod editio, October 2000 XML Base ( A XML v1.0 addedum that describes how to derive the base URI for resolvig URI refereces i XML elemets ad attributes, such as refereces to associated schemas, documet fragmets to be icluded, ad so o XML Names ( A XML v1.0 addedum that describes how to uiquely qualify elemet ames whe processig multiple related documets (usually referred to as amespaces) DOM ( Documet object model i several parts the defiitio of platform- ad laguage-eutral iterfaces that allow programs ad scripts to access ad to update documet structure ad cotets XML Schema ( Parts 1 ad 2 data types ad structures usig XML XML Path Laguage ( Expressios for fidig, evaluatig, ad extractig iformatio from XML documets XML Poiter Laguage ( Based o XPath, idetifies documet fragmets for locatig iteral structures ad exteral parsed etities XML Likig Laguage ( Hyperliks that poit from oe XML documet to aother, icludig fragmets XSL Trasformatio ( A techology that trasforms the structure ad cotets of oe XML documet ito aother Page 59

61 Caoical XML ( A method of geeratig a physical caoical represetatio of a documet such that its cotets ca be compared to aother documet of a differet structure XML Iformatio Set ( A cosistet set of defiitios for other specificatios to use whe referrig to iformatio i a well-formed XML documet XML Iclusios ( A defiitio of mergig multiple XML Iformatio Sets ito a sigle composite Iformatio Set Some of these specificatios were developed with direct referece to others. For example, the XML Base ad XML amespaces specificatios were added directly as addeda to the XML v1.0 specificatio ad thereby icluded by referece withi the basic stadard. Other specificatios, such as XML Poiter Laguage, were developed such that they may or may ot be used with the basic stadard ad therefore may or may ot be supported by a particular XML tool. Most of these specificatios are udergoig chage, ad workig drafts of the ew versios are ofte available. May XML specificatios are related Geeral Iformatio May sources for XML iformatio exist. The specificatios listed here are of particular relevace to Web services ad are excellet sources for further detail o the fudametal stadards ad techologies outlied here. The geeric XML home page maitaied by the W3C is a excellet startig poit (see That page provides liks to all the major specs, workig drafts, otes, ad other techical publicatios of the W3C pertaiig to XML. The page shows the latest status ad updates o the XML specificatios ad related techologies. For example, ew versios of XML ad XSLT are well uder way. It's easy to fid more iformatio o XML XML Is Dautig Wadig through the umerous XML specificatios ad applicatios is a dautig task: There are so may of them ad the relatioships amog them Byzatie. Do you eed a validatig or a ovalidatig XML processor? Are amespaces required? What about trasformatio: Do you use SAX or DOM or both? Imagie the difficulties of formalizig ad regularizig completely ustructured, freeform iformatio. It's oe thig to deal with it i the cotext of iformatio to be displayed i a browser or prited out but quite aother whe it's iteded for software itegratio. It's likely that XML processors, like the XML commuity itself, will begi to split betwee the markup ad data-orieted applicatios. It's too much to uderstad, otherwise: There has to be a way to arrow dow the scope. For some people, that scope is defied by the XML Iformatio Set specificatio, which lists the XML parts produced by parsig a give documet. Eve this is ot eough, however, as the Iformatio Set recogizes processig istructios ad DTDs, which are ot used i Web services. Noetheless, a authoritative way is eeded to represet the essetial parts of a XML documet iteded for use i software-based applicatios. Page 60

62 A good source of summary iformatio o XML ad W3C's work i progress is a documet called XML i 10 Poits. It's available at The W3C provides a summary documet There's eve a report from a task force that studied the differece betwee URLs ad URIs. They mea essetially the same thig, although there's a differece betwee a locator ad a idicator, or ame, whe the ame is just a ame ad does't refer to aythig. However, the same form is possible for both uses. (See Clarificatio o URIs ad URLs Summary XML is used i a broad variety of applicatios. Its mai applicatios i Web services are i data formattig, serializatio, ad trasformatio. Web services commuicate by exchagig formatted istaces of XML documets that carry data. Web services are described usig XML schemas that defie data types, structure, ad sematics. A wide variety of XML specificatios is used i Web services techology defiitios, icludig schemas, amespaces, extesible style sheets, ad others. The mai advatage XML offers Web services is data idepedece so that data types ad structures are ot tied to the uderlyig implemetatios of the services. Previously, data types ad structures for distributed computig were defied withi idividual programmig laguages, database descriptio laguages, ad middleware iterface descriptio laguages. To take advatage of the data idepedece, applicatios must covert data ito XML ad trasform data out of XML ito its ative format. Although XML bega as a documet markup laguage, a large portio of the XML commuity is ow focusig o XML as a techology for data descriptio ad serializatio. Page 61

63 Chapter 3. Describig Web Services: WSDL Web services expose a software-orieted view of a busiess or cosumer fuctio with which applicatios may iteract over the etwork. To successfully eable such a iteractio usig a Web service, it must be described ad advertised to its potetial cosumers. Furthermore, users must be able to fid out about how to iteract with the service: what data it expects to receive, whether it delivers ay results, ad what commuicatio protocol or trasport it supports. I a somewhat primitive form, Web services have bee aroud for a log time. It's possible to sed a search strig or a stock quote request by appedig iformatio to URLs. However, this format is of lim ited usefuless ad scope for may reasos, ot the least of which is the size limit ad the usability of a URL for passig data. It's also difficult to program ad to uderstad, ad o cosistet, stadard approach has bee defied for describig it. Web services have bee aroud for a log time i primitive form The stadard form of Web services puts the request ad the reply ito XML documets, that is, ito the resources that are refereced by the URLs rather tha withi parameters of the URLs themselves. The emergig stadards for Web services also facilitate a more uiversal approach, so that every Web site is ot decidig how to use exteded URLs idividually. The followig example illustrates the most primitive type of Web service: ski Here, the iput data is carried as a parameter to the URL address of the Web page implemetig the service i this case, a employee search fuctio that returs a ame ad a telephoe umber. WSDL Basics The Web Services Descriptio Laguage (WSDL) specificatio was created to describe ad publish the formats ad protocols of a Web service i a stadard way. Web service iterface stadards are eeded to esure that you do't have to create special iteractios with each server o the Web, as you would today, usig the exteded URL approach from a browser. WSDL establishes a commo format for describig ad publishig Web service iformatio WSDL elemets cotai a descriptio of the data, typically usig oe or more XML schemas, to be passed to the Web service so that both the seder ad the receiver uderstad the data beig exchaged. The WSDL elemets also cotai a descriptio of the operatios to be performed o that data, so that the receiver of a message kows how to process it, ad a bidig to a protocol or trasport, so that the seder kows how to sed it. Typically, WSDL is used with SOAP, ad the WSDL specificatio icludes a SOAP bidig. WSDL elemets describe data ad operatios o it Page 62

64 WSDL was developed by Microsoft, Ariba, ad IBM, ad v1.1 of the specificatio was submitted to the W3C, which accepted WSDL as a ote ad published it o the W3C Web site. [1] Twetytwo other compaies joied the submissio, comprisig at that time the largest umber of W3C members ever to support a joit submissio. WSDL therefore already ejoys broad-based support, ad may compaies offer implemetatios of WSDL i their Web services products. I fact, with such ear uaimity withi the vedor commuity, it could be said that the WSDL specificatio provides the de facto defiitio of a Web service descriptio. However, it is very likely that a W3C workig group will oetheless make sigificat improvemets ad chages. [1] See the schema ad for the specificatio. WSDL was developed collaboratively by IBM, Microsoft, ad Ariba Both parties that participate i a Web Services "coversatio" or iteractio must have access to the same WSDL to be able to uderstad each other. [2] I other words, both the seder ad the receiver of a message ivolved i a Web servic e iteractio must have access to the same XML schema. The seder eeds to kow how to format the output message correctly, ad the receiver eeds to uderstad how to iterpret the iput message correctly. As log as both parties to the iteractio have the same WSDL file, the implemetatios behid the Web services ca be aythig. This is the magic of WSDL: It provides a commo format to ecode ad to decode messages to ad from virtually ay back-ed applicatio, such as CORBA, COM, EJB, JMS, MQ Series, ERP systems, ad so o. [2] Alteratively, a privately agreed o, shared XML schema file will do the same trick, but WSDL has already solved the problem, so why ot use it? Both parties to a Web service iteractio eed copies of the same WSDL file As show i Figure 3-1, Web services typically are implemeted usig programmig laguages desiged for iteractio with the Web, such as Java servlets or Applicatio Server Pages (ASPs) that call a back-ed program or object. These Web service implemetatios are also typically based o WSDL or represeted usig WSDL. That is, either ew services ca be geerated from WSDL, or existig services ca be described usig WSDL. It's likely that both approaches will catch o, as desigig ad exposig Web services is boud to be a iterative process. Neither approach by itself is goig to provide the best solutio i all cases. Figure 3-1. A busiess ca use WSDL to advertise its Web services. Page 63

65 Web services are implemeted usig Web-orieted laguages Figure 3-1 shows a EJB described usig a WSDL file ad exported usig a servlet over the etwork. The servlet listes to the etwork through either a Web server or a custom HTTP listeer. I the example, the servlet accepts a SOAP message ad forwards it to the beas that are represeted by the WSDL file. The beas i tur implemet, or coect to, the specific busiess applicatios beig exposed to the etwork, providig the iformatio that is carried i the SOAP body as iput, if ay, ad returig ay results back through the beas to the servlet. If results eed to be set back across the etwork, data is retured to the beas through output argumets ad back to the servlet from which the reply goes back to the servlet. The servlet that provides the implemetatio of the WSDL file packages the data ito a SOAP message reply to sed back across the etwork. I this way, simple extesios to existig Iteret ifrastructure ca implemet Web services for iteractio via browsers or directly withi a applicatio, such as the oe i Figure 3-1. As well as a EJB, the applicatio behid the servlet could be implemeted usig.net, JMS, CORBA, COBOL, or ay umber of proprietary itegratio solutios. Furthermore, Web services ca represet B2B documet-exchage iteractios. Web services defiitios ca be mapped to ay laguage, object model, or messagig system Exposig Objects ad Beas Directly It may ot always make sese to expose a bea or a object directly as a Web service; more ofte, it seems likely that a bea or other program will be writte specifically for the purpose of exposig a Web service. I other words, it's ulikely that existig programs will be a good fit or be built accordig to a desig that fits Web service requiremets, ad special wrapper programs may eed to be writte to expose the level of graularity appropriate to a Web service. Page 64

66 WSDL Elemets WSDL breaks dow Web services ito three specific, idetifiable elemets that ca be combied or reused oce defied. Mappig from existig applicatios meas mappig to these elemets, which idetify the cotets ad data types of the messages, the operatios performed for the messages, ad the specific protocol bidigs, or trasports, for exchagig the messages with the operatios over the etwork. Withi these elemets are further subelemets, or parts: Data types: the data types i the form of XML schemas or possibly some other mechaism to be used i the messages Message: a abstract defiitio of the data, i the form of a message preseted either as a etire documet or as argumets to be mapped to a method ivocatio Operatio: the abstract defiitio of the operatio for a message, such as amig a method, message queue, or busiess process, that will accept ad process the message Port type : a abstract set of operatios mapped to oe or more ed poits, defiig the collectio of operatios for a bidig; the collectio of operatios, because it is abstract, ca be mapped to multiple trasports through various bidigs Bidig: the cocrete protocol ad data formats for the operatios ad messages defied for a particular port type Port: a combiatio of a bidig ad a etwork address, providig the target address of the service commuicatio Service: a collectio of related ed poits ecompassig the service defiitios i the file; the services map the bidig to the port ad iclude ay extesibility defiitios WSDL files ca be divided ito up to three separate, reusable elemets Fortuately, these parts of WSDL usually are geerated usig tools that trasform the existig back-ed applicatio metadata ito XML schema iformatio, which is the merged ito the Web Services Desciptio Laguage file. WSDL is typically geerated by Web services products ad tools, such as IONA' s XMLBus Editio. [3] [3] See WSDL parts usually are geerated automatically usig Web services aware tools IONA's XMLBus Editio provides several optios for Web service geeratio. Figure 3-2 shows the Editio's mai meu, which is displayig the list of sample demos icluded with the product. [4] These demos are prebuilt services, previously geerated from Java classes ad EJBs. The Editio also builds ew Web services from Java classes, JavaBeas, ad CORBA objects. [4] A XMLBus Web services archive (XAR) file represets the XMLBus Web services cotaier, which is deployable stadaloe or o a applicatio server. Figure 3-2. The XMLBus Editio's mai meu lists the product's demos. Page 65

67 Whe buildig a ew Web service, the Editio gathers ecessary iput ad automatically geerates the correspodig WSDL file. The IONA XMLBus product builds a Web service usig iput forms such as the oe i Figure 3-3, which asks the user to select the specific Java class methods for which a Web service is to be geerated. The form also asks the user to select the documet-orieted or RPC-orieted iteractio style ad to select either SOAP ecodig [5] or literal ecodig XML/text for the service. Attachmets are supported for the documet-orieted style. Aother form allows the user to iput a specific amespace for the service istead of havig it geerated by the product. Fially, the user ca geerate either a proxy cliet for Java 2 Platform, Micro Editio (J2ME) devices, such as PDAs or mobile phoes, or a regular Java proxy. Most Web service implemeters, such as IBM ad Microsoft, offer similar tools for automatically geeratig WSDL schemas, proxies, ad amespaces. [5] See Data Type Mappig i Chapter 4. Figure 3-3. Forms are used to select methods ad iteractio style to build a Web service. Page 66

68 The Extesible WSDL Framework Like SOAP ad the other XML itegratio framework techologies, WSDL is a extesible framework. The bidigs for SOAP, for example, exted WSDL, as do the bidigs for HTTP GET ad POST ad MIME. I this way, WSDL separates the abstract defiitio of ed poits ad messages from their cocrete etwork deploymets, or data format bidigs, which permits reuse of the abstract defiitios. WSDL is completely extesible to multiple formats ad protocols The three major elemets of WSDL that ca be defied separately are Types Operatios Bidig As oted previously, WSDL has seve parts, but they are cotaied withi these three mai elemets, which ca be developed as separate documets ad the combied or reused to form complete WSDL files. The major elemets are divided accordig to their level of abstractio i the stack represetig a Web service. The data type declaratios are the most abstract elemet of a service, defiig the data items the XML documets to be exchaged by a Web service. The data types ca be defied oce, like iclude files, ad refereced withi ay of the operatios. The operatios o the data types represet the ext level of abstractio, defiig the way data is passed back ad forth. The bidig, the fial level of abstractio, defies the trasport used to pass the message. Defiig Message Data Types Page 67

69 At its most abstrac t level, a Web service cosists of a XML documet set to ad/or received from a remote software program. The first job i defiig a Web service, therefore, is to idetify the data requiremets for the software program implemetig the Web service fuctioality. Web service processig icludes a XML mappig phase A Web service eeds to defie its iputs ad outputs ad how they are mapped ito ad out of services. WSDL types take care of this. Types are XML documets, or documet parts. WSDL allows the types to be defied i separate elemets so that the types are reusable with multiple Web services. WSDL uses basic XML schema types by default Data types address the problem of how to idetify the data types ad formats you ited to use with your Web services. Type iformatio is shared betwee seder ad receiver. The recipiets of messages therefore eed access to the iformatio you used to ecode your data ad must uderstad how to decode the data. Types are typically defied usig XML schemas; like other parts of WSDL, however, the types portio is completely extesible, ad other type systems ca be used istead. For example, if you kow that the target of a particular istace of a Web service is a CORBA object, you ca use the CORBA type system istead of the XML schema type system. You could also simply itroduce aother stadard self-describig ecodig, such as Abstract Sytax Notatio Oe (ASN.1). This may be useful for local area etwork applicatios of WSDL, for which optimizig or bypassig the mappig stage ito ad out of XML schema types would be helpful. Aother optio is to hard code the type defiitios withi the Web Services Descriptio laguage file. Types ca be defied withi the WSDL elemet or iside other files refereced withi that elemet. Because XML is iheretly flexible, trasformable, ad extesible, the XML data defied for a Web service does ot have to exactly match the data required by the program behid it; i fact, it probably should ot. As log as the data ca be maipulated i the mappig stage, it ca be defied usig a level of abstractio or format differet from the origial applicatio. Because it's ot executable by itself, a Web service icludes a mappig stage, durig which the XML data is mapped to the software program, as well as a executio stage, durig which the program itself is ru.) A mappig stage is required to trasform the XML data ad the XML schema represetatio of a service ito the software program that is executig it. The requiremets for the message data ad operatios part of WSDL therefore are that they express eough of the data ad sematics of the software program to allow a bridge to be costructed to it over the etwork usig the capability of the trasformatio ad mappig phase at each ed. WSDL is a loose represetatio of a object or a database system Page 68

70 As show i Figure 3-4, oe or more idividual data types are mapped ito messages. The same message ca be mapped ito multiple operatios. Types are typically ay of the XML schemasupported data types, such as iteger, strig, Boolea, or date, ad ca iclude complex types, such as structures ad arrays, icludig those defied for SOAP. The data types are therefore either simple schema types or schemas that defie complex types. As i the other areas of WSDL, types are ot restricted to XML schemas, because o oe expects a sigle type of system to be capable of describig all possible message formats for the Web. Figure 3-4. Data types are mapped to messages. The followig example illustrates the type ad message defiitios for a Skateboots.com purchase order service that returs the total value of oe or more purchase orders. The XML schema data types used i the WSDL file are mapped to messages usig the schema elemet ames. <?xml versio="1.0" ecodig="utf-8"?> <defiitios ame="purchaseorderservice" targetnamespace="purchaseorderservice" xmls=" xmls:soap-enc=" xmls:soap=" xmls:ts="purchaseorderservice" xmls:xsd=" xmls:xsd1="purchaseorderservice-xsd" xmls:xsi=" <types> <schema targetnamespace="purchaseorderservice-xsd" xmls=" xmls:wsdl=" <complextype ame="purchaseorder"> <all> <elemet ame="compayname" type="xsd:strig"/> <elemet ame="items" type="xsd1:arrayofitem"/> <elemet ame="address" type="xsd1:address"/> </all> </complextype> <complextype ame="item"> <all> <elemet ame="price" type="xsd:float"/> <elemet ame="partid" type="xsd:strig"/> <elemet ame="descriptio" type="xsd:strig"/> <elemet ame="quatity" type="xsd:it"/> </all> </complextype> <complextype ame="arrayofitem"> <complexcotet> <restrictio base="soap-enc:array"> Page 69

71 <attribute ref="soap-enc:arraytype" wsdl:arraytype="xsd1:item[]"/> </restrictio> </complexcotet> </complextype> <complextype ame="address"> <all> <elemet ame="state" type="xsd:strig"/> <elemet ame="postalcode" type="xsd:strig"/> <elemet ame="city" type="xsd:strig"/> <elemet ame="lie2" type="xsd:strig"/> <elemet ame="coutry" type="xsd:strig"/> <elemet ame="lie1" type="xsd:strig"/> </all> </complextype> <complextype ame="arrayofpurchaseorder"> <complexcotet> <restrictio base="soap-enc:array"> <attribute ref="soap-enc:arraytype" wsdl:arraytype="xsd1:purchaseorder[]"/> </restrictio> </complexcotet> </complextype> </schema> </types> <message ame="postpurchaseorderrequest"> <part ame="order" type="xsd1:purchaseorder"/> </message> <message ame="postpurchaseorderresult"> <part ame="retur" type="xsd:float"/> </message> <message ame="postpurchaseordersrequest"> <part ame="orders" type="xsd1:arrayofpurchaseorder"/> </message> <message ame="postpurchaseordersresult"> <part ame="retur" type="xsd:float"/> </message> Whe usig SOAP, a message is carried as the payload of the SOAP request or respose. That is, the WSDL message defiitio does ot iclude ay iformatio that is mapped to the SOAP evelope, headers, or fault code. I other words, you ca say that WSDL targets a layer of abstractio etirely above that of SOAP. Iformatio i WSDL does ot map to SOAP headers Defiig Operatios o Messages The ext level of abstractio, operatios, addresses the requiremet of a Web service to idetify the type of operatios beig performed o behalf of a give message or set of messages. The operatio is defied so that the Web service kows how to iterpret the data ad what, if ay, data is to be retured o the reply. Oce you have the data, defie the operatios Operatios are defied i correspodece to commo message patters, such as oe-way ad request/respose. WSDL does ot iclude specific defiitios for other operatios, but more Page 70

72 complicated iteractios ca be costructed by combiig these basic types. For example, somethig like the cooperatig parter profile specificatio from ebxml could be used to defie a sequece of oe-way ad request/respose operatios i support of a complex message patter iteractio. As show i Figure 3-5, operatios ca group messages for iput ad output to match the patter of the request/respose message. Figure 3-5. Operatios group message types to match the message patter. WSDL has four types of operatios: Oe-way: Similar to fire-ad-forget, but more simply it meas that the message is set without a requiremet to retur a reply. Request/respose: Similar to a RPC-style iteractio; the seder seds a message, ad the receiver seds a correspodig reply. (Some protocols may ot guaratee that a respose is retured for every request.) Solicit respose (o defiitio yet): A simple request for a respose with o iput data. It's a request to get a message ad does ot ivolve sedig a message, i the sese of a WSDL message cosistig of oe or more defied types. It's the reverse of the oe-way operatio. Notificatio (o defiitio yet): This type of operatio defies multiple receivers for a message, similar to a broadcast, ad ofte ivolves a subscriptio mechaism, as i publish/subscribe, to set it up. Operatios match request/respose ad other message patters Operatios allow sequeces of messages to be correlated ito specific patters without havig to itroduce a more complex flow specificatio. Operatios are ot the same as methods o objects, although certaily the iput ad output parameters defied for operatios will ormally map to method iput ad output argumets whe the services are implemeted usig a object-orieted techology such as.net, EJB, or CORBA. Operatios correlate messages ito specific patters but ot flows Page 71

73 Operatios may iclude optioal fault messages, although their cotet is outside the scope of the specificatio. The followig example illustrates a request/respose operatio defiitio for the Skateboots.com service. <porttype ame="purchaseorderporttype"> <operatio ame="postpurchaseorder"> <iput message="ts:postpurchaseorderrequest" ame="postpurchaseorder"/> <output message="ts:postpurchaseorderresult" ame="postpurchaseorderresult"/> </operatio> <operatio ame="postpurchaseorders"> <iput message="ts:postpurchaseordersrequest" ame="postpurchaseorders"/> <output message="ts:postpurchaseordersresult" ame="postpurchaseordersresult"/> </operatio> </porttype> Iput ad output messages are defied for the request ad respose operatios, usig the message defiitios created i the previously show elemets of the WSDL file. Request/respose operatios do ot require use of the RPC attribute i the SOAP bidig (see Extesios for Bidig to SOAP later i this chapter), although it's probably a good idea. It's good programmig practice to preserve withi the SOAP bidig, for example, the sigature of a object to which the Web service is mapped. The parameterorder attribute lists message part ames, ad the order of the messages must match those of the RPC sigature. Although ot required, it's good to map operatios to SOAP correspodigly There is o sytax to defie a retur value, but if a part ame appears i both the iput ad the output messages it's a i/out parameter; if it's o iput oly, it's a iput parameter. This covetio makes it easier to map WSDL operatios oto RPC bidigs for example, the RPC bidig for SOAP. SOAP also has a documet bidig, ad Web services iteractios will likely iclude both. For example, a purchase order is shared betwee the buyer ad the seller of goods. Both the buyer ad the seller may first exchage a copy of the same documet. They may exchage iformatio dyamically over the Web to fill i the fields o the form, such as available ivetory, ship date, quatity discout, ad so o. This will allow a more dyamic, real-time egotiatio betwee buyer ad seller to set the terms ad coditios of a sale, based o a shared documet. Operatios put iput/output messages i correspodece, although it varies by trasport what type of guarateed correlatio is available; SOAP does ot require correspodece, although HTTP GET ad POST do. Today, separate services have to be defied if you wat to advertise both a documet-orieted ad a procedure-orieted service, but it seems likely that these may be combied i a future versio of WSDL. Mappig Messages to Protocols Page 72

74 After the data types ad the operatio types are defied, they have to be mapped oto a specific trasport protocol, ad a ed poit, or address to which the data is set ad at which it's possible to fid ad ivoke the particular operatio, must be idetified. This operatio is required because the same data types ad operatios ca be mapped oto multiple trasports, such as SOAP, BEEP, IIOP, JMS, ad others, ad a Web service ca live at potetially multiple ed-poit addresses. This part of the WSDL solves the problem of how a trasport expects to uderstad the data beig passed for example, it may be serialized accordig to the SOAP specificatio ad where to fid the service at a Iteret IP address, itraet, LAN, ad so o. Now map messages to trasports ad ed poits First, operatios are grouped ito port types, as show i the previous example. Each port type is the mapped to oe or more specific ports represetig the various trasports over which a service might be available; for example, a port type might be mapped to specific ports for HTTP GET ad POST, SOAP, or MIME. Trasport bidig extesios are the mapped to each specific port i order to defie the iformatio ecessary to offer a give service over a specific trasport. The trasport bidig extesios udereath the data types, operatio types, ad port types idetify the receiver of the data ad the operatio to be performed. So for ay give Web service, it's both ecessary ad possible to defie the data, the operatio o the data, ad the place to which the data is set ad how. Port Types A port type is a logical groupig of operatios, similar to type libraries i.net, classes i Java, or a object's IDL (Iterface Defiitio Laguage) i CORBA. If a operatio is aalogous to a method o a object ad if messages are aalogous to iput ad output argumets, a port type is aalogous to a object defi itio that potetially cotais multiple methods. But these aalogies are ot exact, because WSDL is extesible ad is iteded to provide a level of abstractio greater tha what's provided by ay of these object-orieted systems. Port types idetify to whom the message is set ad how I other words, WSDL is a idepedet data abstractio that ca be used for much more tha simply mappig ito ad out of.net, EJB, or CORBA objects. But whe workig with these object-orieted systems, it helps to uderstad the parts of WSDL that correspod to parts of these systems. The request/respose style uses differet message defiitios for the iput ad output messages; as with documet passig, the oe-way style uses a sigle type as a complete documet. Both types of iteractios ca be defied withi a give port type. As show i Figure 3-6, a port type represets a collectio of operatios, i the same way that a object represets a collectio of methods. For Web services, the mappig betwee a port type ad a object type or a class is quite atural. But because Web services are defied at a high level of abstractio, mappigs ca also be made to documets ad procedure-orieted techologies. Figure 3-6. A port type represets a collectio of operatios. Page 73

75 A port type is a collectio of operatios Ports A port is used to expose a set of operatios, or port types, over a give trasport. The port types ca be grouped for oe or more bidigs, which is how the services are coected over the etwork. A port idetifies oe or more trasport bidigs for a give port type. To cotiue the compariso with object-orieted systems, a port is aalogous to the trasport. For example, a commo trasport for CORBA is IIOP; for EJB, it's RMI (remote method ivocatio) or RMI/IIOP; ad for COM, it's DCOM, which is based o Distributed Computig Eviromet (DCE) RPC. Ports are trasport specific These systems do ot provide a truly equivalet defiitio mechaism with which to defie a particular trasport, although EJB ad CORBA systems certaily ca be ad have bee mapped to a variety of trasports. But the mappig is ot cosidered part of the object defiitio. With WSDL, however, it's ecessary to advertise withi the service defiitio which trasport bidigs are available for a give collectio of operatios. The sedig or discoverig system at a remote etwork ed poit will typically access a published WSDL file via HTTP as a typical documet GET operatio but may the wish to egotiate with the receiver or publisher of the Web service to iteract o a differet trasport that provides additioal fuctioality. Figure 3-7 illustrates the cocept of a port i WSDL, which puts together the operatios, the bidig, ad a URL defiig a specific IP address at which the Web services implemetatio ca be foud. The followig example illustrates the SOAP bidig for the operatios i the Skateboots.com purchase order. Figure 3-7. I WSDL, a port combies operatios, bidig, ad a etwork address. Page 74

76 <bidig ame="purchaseorderbidig" type="ts:purchaseorderporttype"> <soap:bidig style="rpc" trasport=" <operatio ame="postpurchaseorder"> <soap:operatio soapactio="purchaseorderservice/postpurchaseorder" style="rpc"/> <iput ame="postpurchaseorder"> <soap:body ecodigstyle=" ecodig/"amespace="purchaseorderservice" use="ecoded"/> </iput> <output ame="postpurchaseorderresult"> <soap:body ecodigstyle=" ecodig/"amespace="purchaseorderservice" use="ecoded"/> </output> </operatio> <operatio ame="postpurchaseorders"> <soap:operatio soapactio="purchaseorderservice/postpurchaseorders" style="rpc"/> <iput ame="postpurchaseorders"> <soap:body ecodigstyle=" ecodig/"amespace="purchaseorderservice" use="ecoded"/> </iput> <output ame="postpurchaseordersresult"> <soap:body Page 75

77 ecodigstyle=" ecodig/"amespace="purchaseorderservice" use="ecoded"/> </output> </operatio> </bidig> Note the use of the SOAP Actio, the SOAP ecodig, ad the RPC iteractio style. The trasport bidig ca be doe per operatio. Ports by defiitio iclude the trasport bidig or bidigs, which i the case of the SOAP bidig icludes a declaratio of whether the iteractio is request/respose (RPC) or documet passig (DOCUMENT). This is the SOAP bidig style. Several other extesios to WSDL are defied specifically for use with SOAP, such as a way to defie the SOAP Actio [7] ad iput ad output messages. [7] WSDL will eed to be modified for cosistecy with SOAP v1.2 oce it's completed for example, removig its use of the SOAP Actio header, sice v1.2 removes the SOAP Actio feature. Trasport bidigs are doe for operatios <soap:operatio soapactio= <iput> <soap:body use="literal" amespace=" ecodigstyle=" </iput> <output> <soap:body use="literal" amespace=" ecodigstyle=" </output> </operatio> The SOAP ecodig optioally ca be used with WSDL, as show i the example, ad both optios are explicitly supported. (See Extesios for Bidig to SOAP later i this chapter for further iformatio o the SOAP bidig extesios.) Bidigs ca be defied for other trasports, such as SMTP, ad extesios icluded specifically for them. The separatio of the trasport bidig extesios from the defiitio of the port type allows oe Web service to be available over multiple trasports without havig to redefie the etire WSDL file. Agai, because it is desiged to be completely extesible, WSDL allows other bidig extesios to be used, such as for example for IIOP,.NET, JMS, MQ Series, ad so o. Bidigs ca be defied for multiple trasports Page 76

78 Services As show i Figure 3-8, the service part of WSDL ecloses oe or more port types, similar to the way i which a object class ca cotai multiple objects. The followig example illustrates the service bidig for the Skateboots.com purchase order totalig service: <service ame="purchaseorderservice"> <port bidig="ts:purchaseorderbidig" ame="purchaseorderport"> <soap:address locatio=" xmlbus/cotaier/purchaseorder/ PurchaseOrderService/ PurchaseOrderPort"/> </port> </service> Figure 3-8. A service is a collectio of port types. Services group operatios i the same way that objects or classes group methods Note the defiitio of the service address (i this case a locally hosted address). The service allows a give ed poit i a remote applicatio to choose to expose multiple categories of operatios for various kids of iteractios. For example, oe category might cotai a set of documet-orieted iteractios to asychroously exchage ad complete a purchase order for a future shipmet. Aother category might cotai a set of RPC-orieted iteractios to sychroously iteract o a order for immediate shipmet. I the former case, access to real-time ivetory data is ot required; but i the latter case, it is. Puttig It All Together Page 77

79 Oce all the parts ad elemets of WSDL are defied, the WSDL file is complete ad ca be placed i a directory accessible to the Web via a URL. (WSDL files are typically geerated, so do't worry too much about their idividual complexity; the mai poit is to uderstad how WSDL solves particular problems.) Figure 3-9 illustrates the two types of operatios, or usage patters, for Web services defied i the WSDL specificatio: request/respose ad oe-way messages. For the request/respose operatio, a iput message is set to the receivig SOAP hadler as a part of a HTTP request, ad a output message is retured via HTTP respose. For the oe-way operatio, a iput message is set to a MIME hadler o a differet port idetified by the same service. Figure 3-9. WSDL defies messages, operatios, ports, ad trasports for SOAP ad MIME. Importig WSDL Elemets The import elemet allows WSDL elemets that were separated ito idepedet documets to be imported, as eeded, to create a complete documet. Differet amespaces are used to qualify ames i the three elemets. WSDL elemets ca be imported As metioed previously, types, abstract operatios, ad bidigs ca be developed idepedetly ad combied later to create the complete WSDL file used to describe a particular Web servic e istace. Thus WSDL allows differet data types to be combied with differet operatios ad differet bidigs. Namespaces are defied for each elemet, ad the tricky part is to esure that the amespaces do't overlap. Page 78

80 Usefuless of Multiple Trasports Multiple ports meas multiple trasports for the same service. This flexibility ca be hady for the Iteret, where some ed poits might uderstad MIME but ot SOAP, ad for a itraet, where some ed poits will ot uderstad ay of the Web protocols or eve ay stadard protocol. Part of the power of Web services for use iside the eterprise derives from the ability of the services to map easily to multiple protocols ad trasports through the separatio of the bidig extesios from the abstract iformatio about a service. WSDL layerig clearly separates the abstract defiitio of a service from its physical, or etwork, realizatio ad allows for extesios to be defied for ay etwork protocol capable of carryig XML data, or i other words, just about aythig. The advatage for a busiess is that existig trasports ca be used; Web services do ot assume or require that a specific software compoet has to be istalled o each ed poit. Multiple schemas may be associated with a particular amespace, ad it is up to a processor of XML to determie which oe to use i a particular processig cotext. The WSDL specificatio provides the processig cotext via the <import> mechaism, which is based o the XML schema's grammar for the similar cocept. WSDL-Related Namespaces WSDL icludes a amespace specifically for use withi the curret documet. I additio to applicatio-defied ame spaces, several amespaces importat to WSDL are defied i the specificatio: used for the WSDL framework used for the SOAP evelope defiitio i the WSDL bidigs for SOAP used for HTTP GET ad POST bidig for WSDL used for the WSDL MIME bidig used for the SOAP v1.1 ecodig scheme used for the SOAP v1.1 evelope used for the XML schema amespace ts the amespace prefix used by covetio to refer to the curret documet WSDL makes extesive use of XML amespaces Extesios for Bidig to SOAP Because SOAP is the most popular trasport for WSDL, it's importat to cover its bidig i further detail. The SOAP specificatio cotais predefied rules for physically represetig such data types as Booleas, itegers, ad arrays. Bidig to SOAP therefore requires the abstract data types, messages, ad operatios to be boud to cocrete physical represetatios o the wire. The WSDL <bidig> elemet associates a port type with a port to defie the cocrete aspects of operatios. For example: <bidig ame='iseasoorderbidig' type='wsdls:iseasoorderport' >... </bidig> Page 79

81 SOAP is the most importat bidig for WSDL The amed bidig attribute is also required for the WSDL <port> elemet. Iside the <bidig> elemet is a WSDL SOAP extesio elemet called <soap:bidig>, which specifies the physical trasport protocol ad the style of request: RPC or documet. For example: <soap:bidig style='rpc' trasport=' http' /> This example defies the RPC style of iteractio for a SOAP mappig to HTTP. For each operatio withi the service, the value of the SOAPActio HTTP header has to be icluded. SOAPActio is a HTTP header that the requestig system seds whe it ivokes the service. The SOAP processor o the receivig system ca use the header to determie the ultimate destiatio of the service. For example: <bidig ame='iseasoorderbidig' type='wsdls:iseasoorderport' > <soap:bidig style='rpc' trasport=' soap/http' /> <operatio ame='orderetry' > <soap:operatio soapactio=' order/ordermaagemet.orderetry' />... </operatio> </bidig> The SOAP Actio HTTP header is required The <operatio> elemet cotais the same ame as the operatio defied earlier. A <soap:operatio> with the soapactio attribute is icluded withi this <operatio> to show that the ultimate destiatio of the message is the OrderEtry service i the /order folder. Next, the ecodig mechaism for the iput ad the output messages must be specified, as show here. <bidig ame='iseasoorderbidig' type='wsdls:iseasoorderport' > <soap:bidig style='rpc' trasport=' /> <operatio ame='orderetry' > <soap:operatio soapactio=' OrderMaagemet.OrderEtry' /> <iput> <soap:body use='ecoded' amespace=' ecodigstyle=' ecodig/' /> </iput> <output> <soap:body use='ecoded' amespace=' ecodigstyle=' Page 80

82 ecodig/' /> </output> </operatio> </bidig> Both the <iput> ad the <output> elemets use a <soap:body> elemet to specify data type ecodig rules. The URI refereces the optioal SOAP ecodig style, meaig that it will be used for the serializatio, or data type ecodig, of the iput ad output messages. Summary The Web Services Defiitio Laguage provides a complex, full-fuctio mechaism for defiig iterfaces to Web services. Iterfaces ca be defied as a collectio of Web service operatios supported at a give ed poit. WSDL, a specific type of XML schema, defies a laguage for expressig Web services iterfaces i a way that commoly available XML software ca uderstad ad use. Desiged for use with SOAP as the messagig trasport, WSDL icludes a attribute to specify whether a give iterface supports the documet-orieted or the RPC-orieted iteractio style. WSDL is difficult to read ad to uderstad, but Web service toolkits typically geerate ad cosume WSDL files automatically. Iterfaces from established distributed computig techologies, such as Java classes, JavaBeas, CORBA objects, Visual Basic classes, ad C# classes, traslate easily ito WSDL, although they might ot be defied at the level of graularity appropriate for Web services. WSDL cotais a descriptio of the data types ad structures used i Web services messages, as well as iformatio required for mappig the Web service defiitio oto a uderlyig executio eviromet. The three mai parts of WSDL message types, operatios, ad bidigs ca be defied i separate documets ad combied at executio time. By default, message types use XML schemas for data typig ad structurig. Operatios typically map to method or program ames implemetig the Web service. Bidigs describe the protocols ad trasports used to sed the data to the operatio. Chapter 4. Accessig Web Services: SOAP The Simple Object Access Protocol (SOAP) is perhaps the most sigificat of all Web services techologies. True, Web services would't exist without a way to abstractly represet the data ad publish the iterface defiitios, but SOAP accomplishes arguably the most importat aspect of Web services: gettig the data from oe place to aother over the etwork. With the Web emergig as the world's premier etwork ad XML emergig as the world's premier data represetatio format, it makes sese that Web services data trasport requires a combiatio of the two. This is exactly what SOAP provides. SOAP allows the seder ad the receiver of XML documets over the Web to support a commo data trasfer protocol for effective etworked commuicatio. SOAP provides data trasport for Web services Page 81

83 I relatio to the Web, SOAP is a kid of extesio to the HyperText Trasport Protocol (HTTP) that supports XML messagig. Istead of usig HTTP to request a HTML page to be dowloaded ad displayed i a browser, SOAP seds a XML message via HTTP request ad receives a reply, if ay, via HTTP respose. To hadle the XML message correctly, the HTTP listeer, such as Apache or Microsoft Iteret Iformatio Server (IIS), eeds to provide a SOAP processor. I other words, a HTTP listeer receivig a SOAP message must iclude a XML processig capability. SOAP ca exted HTTP for XML messagig More specifically, a HTTP listeer receivig a SOAP message must be able to validate ad to uderstad the particular XML documet format defied i the SOAP specificatio. [1] The SOAP specificatio allows the SOAP messagig protocol to be mapped to other trasports, although the mappig to HTTP is the oly mappig defied i the specificatio. [1] This chapter is primarily based o the SOAP v1.1 specificatio; v1.2 is the W3C versio, due for release i mid Wheever possible, otes are icluded to highlight differeces betwee v1.1 ad v1.2. For further iformatio o the curret status of this ad other W3C specificatios, see the W3C techical publicatios Web site: Despite its ame, SOAP does ot iclude a object model. SOAP defies a oe-way XML messagig protocol o top of which additioal applicatios ca be built, icludig the request/respose iteractio style familiar to object- ad procedure-orieted processig, asychroous messagig ad evet otificatio familiar to message-orieted middleware systems, uackowledged messages, ad forwardig via SOAP itermediaries. SOAP processors ru o SOAP odes SOAP iteractios are modeled as occurrig betwee SOAP odes, which ca be SOAP message seders, receivers, or both. A special case of a SOAP ode ca play the role of a itermediary betwee seder ad receiver for the purpose of hadlig special headers. A SOAP ode supports oe or more SOAP processors ad is resposible for hadlig the SOAP blocks whe a message is received. A SOAP itermediary is a special case of a SOAP ode Figure 4-1 illustrates the three major blocks, or parts of SOAP messages: the evelope, the header, ad the body. The evelope is required ad marks the start ad the ed of the SOAP message. The header is optioal, ad ca cotai oe or more header blocks carryig the attributes of the message or defiig the qualities of service for the message. Headers are iteded to carry cotexts or ay applicatio-defied iformatio associated with the message, such as security tokes, trasactio idetifiers, ad message correlatio mechaisms. The body is required ad cotais oe or more body blocks comprisig the message itself. Page 82

84 Figure 4-1. SOAP cosists of three parts. SOAP has three major parts: evelope, header, ad body SOAP trasports a XML documet across the Web ad, potetially, across other types of etworks, to reach a Web service implemetatio. A SOAP message is, i fact, a XML documet created i a specific format. A coformig SOAP implemetatio uderstads how to iterpret such a documet ad how to map the data to a uderlyig software implemetatio of the service. SOAP does ot defie the service itself, however, but rather just eough about the message so that a SOAP processor ca recogize. SOAP defies what it meas to recogize the message as a SOAP message, but the Web service implemetatio has to kow how to iterpret the data cotaied i the message as a target for the uderlyig software implemetatio of the service. SOAP bridges Web service implemetatios Usig SOAP ad WSDL, a eterprise ca choose to expose busiess data usig services, or iterfaces, that exchage complete documets or that map the data oto objects usig method ames ad iput ad output argumets. Complete documets also ca be exchaged usig SOAP with Attachmets (see SOAP Multipart MIME Attachmets later i this chapter), as ebxml ad RosettaNet have defied. Remote procedure call (RPC) mappigs must be doe withi the body of the SOAP message, usig complex data types, the SOAP ecodig, ad the RPC covetio Page 83

85 defied i the SOAP specificatio (see RPC Covetio later i this chapter). Oe of the trickier aspects of uderstadig SOAP is that it is defied at a sufficiet level of abstractio to ecompass both documet- ad RPC-orieted iteractios. SOAP ca exchage complete documets or call a remote procedure A Simple Example The followig example shows a simple applicatio of SOAP, a oe-way broadcast message to a list of comuicatio mechaisms. The header block cotais the list of devices to which the message is to be set. The body block cotais the actual otificatio message to be delivered: a remider to joi a coferece call i progress. SOAP ca be used for broadcastig a message <ev:evelope xmls:ev=" soap-evelope"> <ev:header> <:broadcastservice xmls:=" <:list>pda, Cell, , Voic , IM</:list> </:broadcastservice> </ev:header> <ev:body> <m:fuctio xmls:m=" sed"> <m:message> Eric, you are late for the cocall agai! </m:message> </m:fuctio> </ev:body> </ev:evelope> The example illustrates a simple SOAP message cotaiig the evelope, a optioal header block that defies attributes of the message, ad a body block that cotais the message itself. I this example, the meetig remider message will be broadcast to the device list by the sed service located at the address defied by the URL: Separate amespaces (broadcastservice ad Fuctio) are used to qualify the elemet ad attributes for each part of the message. The evelope refereces the most recet v1.2 evelope amespace, No ecodig is specified, so o ecodig amespace appears i the example, which meas that the default XML types are used (that is, text). The header ad the body both use applicatio-defied amespaces to qualify the respective elemets ad attributes. This simple oe-way message ca easily be boud to HTTP usig HTTP POST, as i the followig example: Request header: POST /broadcastservice HTTP/1.1 Host: Page 84

86 Cotet-Type: text/xml; charset="utf-8" Cotet-Legth: <?xml versio='1.0'?>...soap request documet Respose header (if ay): HTTP/ OK Cotet-Type: text/xml; charset="utf-8" Cotet-Legth: <?xml versio='1.0'?>...soap respose documet Outgoig messages typically are boud to HTTP POST As show i the example, the proscribed way to use SOAP with HTTP is to sed a request documet (such as i the previous example) usig HTTP POST. The HTTP header idicates that the documet is beig set to the broadcastservice service at the address. Whe the software program implemetig the broadcastservice receives the message, it will decode the body block ad execute the sed request. If a respose were defied for this message (such as a cofirmatio that the message was set), the respose would be cotaied withi the HTTP respose HTTP/ OK. Icomig messages typically are boud to HTTP respose The 200 code is a HTTP code idicatig success. If some kid of failure occurred i processig the request, the HTTP code o the respose would be a failure code, such as HTTP/ Iteral Server Error. I case of a failure to process a SOAP request, the body of the respose icludes a SOAP fault message detailig the problem (see SOAP Faults later i this chapter). The SOAP Specificatio The SOAP specificatio was developed ad published o the Web i late SOAP is a extesio of the XML-RPC specificatio, origially defied by Dave Wier of UserLad. Implemetatios of XML-RPC predate SOAP ad cotiue to be used, but SOAP has gaied a wider acceptace because of its additioal features ad fuctioality. SOAP was developed by UserLad, DevelopMetor, ad Microsoft IONA ad the IBM joied the effort i mid-2000 ad helped produce the v1.1 specificatio, which was submitted to the W3C by 11 vedors. The v1.1 specificatio became the foudatio of the XML Protocols Workig Group at W3C, which is movig the v1.2 specificatio toward recommedatio status. [2] (A recommedatio status is the highest offered by W3C ad Page 85

87 recommeds adoptio of a specificatio as a stadard. W3C does ot call its specificatios stadards, however, because it does ot have the official stadig of a stadards orgaizatio, such as the Iteratioal Orgaizatio for Stadardizatio.) [2] To date, the December 2001 SOAP v1.2 specificatio draft is scheduled to progress to recommedatio, or fial status, i May However, it is ot uusual for these target dates to slip a bit while last-miute cotroversies are resolved. Submittig SOAP to the W3C Started the Web Services Movemet SOAP ca be cosidered the start of the Web services movemet. Submittig the SOAP v1.1 spec ificatio to W3C ad startig the XML Protocols Workig Group were watershed evets. Sice the, the software idustry has etered a cosolidatio phase ad has begu to broadly adopt SOAP, WSDL, ad UDDI. More tha 80 idepedet implemetatios of the SOAP v1.1 specificatio have bee developed, testifyig to its simplicity, popularity, ad the appropriateess of the solutio it offers to the problem of trasportig data across the Web. IBM provides a ope source Java versio as part of its AlphaWorks program, ad implemetatios are also available i.net, C, C++, Visual Basic, Perl, ad Pytho, amog others. A wide variety of SOAP implemetatios exists With all the varied implemetatios ad iterpretatios of the SOAP specificatio, oe of the big areas to be worked o is gettig the various implemetatios to iteroperate. Resolvig issues ucovered i vedor iteroperability testig will be a major part of the ogoig work o SOAP at W3C to esure that SOAP reaches the iteroperability levels achieved usig HTTP ad HTML. The authors of the origial SOAP specificatio iteded to keep the specificatio small ad simple to esure that a basic level of fuctioality would be supported i all SOAP implemetatios ad that higher-level fuctioality could be built o a commo basic protocol. As the specificatio matures, it will likely defie more ad more of these thigs while preservig compatibility at the most basic level as HTTP ad HTML do today, for example. But, implemetatios of SOAP are ot ecessarily compatible i how they address these higher-level issues, such as how to esure that a request has a correspodig reply or what it meas to coordiate busiess trasactios across two or more Web services. Addressig these higher-level issues represets aother major step for W3C. The origial itet was to keep SOAP simple To provide a basic, commo XML messagig protocol for the Web, the SOAP specificatio defies The start ad the ed of a evelope that ecloses the XML documet to be trasported How to represet ay optioal headers for additioal iformatio, icludig poiters to additioal schemas associated with the documet, such as security, trasactio coordiatio, ad so o Page 86

88 How to serialize data type ecodigs optioally over the wire, with specific support for RPC-style iteractios A bidig to HTTP to esure that it carries the documet correctly to its destiatio ad that the destiatio directs the message to a appropriate SOAP processor SOAP defies the elemets ad the rules of XML messagig The mai sytax parts are defied as idepedet blocks so that oe or all may be implemeted ad processed by separate hadlers associated with each. The evelope elemets ad the ecodig rules are defied usig differet amespaces to esure that elemet ad attribute ames withi them do't clash. The SOAP specificatio defies a layered approach to the protocol so that it ca be used i combiatio with other trasports, such as the OMG Iteret Iter-Orb Protocol (IIOP), Java Messagig System (JMS), ad the IETF Blocks Eviromet Extesible Protocol (BEEP). However, oly the HTTP bidig is defied i the curret documet. SOAP sytax blocks are associated with hadlers for processig SOAP Evelope The evelope, the outermost elemet i a SOAP message, comprises the XML documet root elemet. The SOAP evelope is specified usig the ENV amespace prefix ad the Evelope elemet. The evelope chages whe SOAP versios chage. A v1.1-compliat SOAP processor will geerate a fault whe receivig a message cotaiig the v1.2 evelope amespace. A v1.2- compliat SOAP processor geerates a VersioMismatch fault if it receives a message that does ot iclude the v1.2 evelope amespace. The followig example illustrates the v1.2 draft evelope amespace ad the origial v1.1 evelope amespace: V1.2: <SOAP-ENV:Evelope xmls:soap-env=" 12/soap-evelope" V1.1: SOAP-ENV=" evelope/" The evelope is the top-level XML elemet i a SOAP message Looseess of the Specificatio Oe problem with the SOAP specificatio is that it cotais a lot of rules that may or may ot be eforced. Thus it is very likely that two coformig SOAP implemetatios will ot implemet the same collectio of optioal features ad thus be icompatible. There's always a balace betwee required rules i a specificatio ad broad acceptace. A lot of the discussio about SOAP at the W3C cocers where to draw the lie. Some members push for requirig more features i the base protocol, whereas other members believe that it's better to keep the base protocol as simple as possible. Loose rules help ecourage implemetatio because it's easier to produce a miimally coformat Page 87

89 versio. Similarly, specificatio rules that are too tight might discourage implemetatio. Strikig the right balace is critical. The Web Services Iteroperability Orgaizatio was fouded for precisely this reaso to help esure iteroperability by agreeig o a commo iterpretatio of the SOAP, WSDL, ad UDDI specificatios. The optioal SOAP ecodig is also specified usig a amespace ame ad the optioal ecodigstyle elemet, which could also poit to a ecodig style other tha the SOAP oe. The followig example illustrates the v1.2 draft ecodig amespace ad the origial v1.1 ecodig amespace: V1.2: SOAP-ENC:ecodigStyle=" 2001/12/soap-ecodig" V1.1: SOAP-ENC=" ecodig/" Namespaces idetify the evelope versio ad specify ecodig style The ecodig amespace refereces simple types ad eumeratios from XML schema but uiquely defies complex structures, such as arrays ad structs. The ecodig amespace, like amespaces i geeral, ca be refereced at ay level of the documet, icludig the evelope, or top-level elemet. The ecodig amespace ca be set to ull to tur off, or disallow, ecodig for a specific part of the message. The SOAP evelope idicates the start ad the ed of the message so that the receiver kows whe a etire message has bee received. The SOAP evelope solves the problem of kowig whe you're doe receivig a message ad are ready to process it. The SOAP evelope is therefore basic ally a packagig mechaism. Both the publisher ad the cosumer must agree o the ecodig rules typically by dowloadig ad usig the same XML schema that defies them. The evelope ad the ecodig rules are defied usig differet XML amespaces, however, which allows multiple ecodig rules to be applied to the same message. The followig brief example o SOAP evelope sytax is based o the SOAP v1.2 specificatio draft. [3] [3] Note the absece of the SOAPActio field i the HTTP header. This SOAP v1.1 feature was made optioal i the v1.2 draft specificatio. The evelope ca specify ecodig rules for the etire message POST /OrderEtry HTTP/1.1 Host: Cotet-Type: applicatio/soap; charset="utf-8" Cotet-Legth: <SOAP-ENV:Evelope xmls:soap-env=" soap-evelope SOAP-ENV:ecodigStyle=" /"> Page 88

90 ... </SOAP-ENV:Evelope> This example illustrates the use of a SOAP message withi a HTTP POST operatio, which seds the message to the server. It shows the amespaces for the evelope schema defiitio ad for the schema defiitio of the ecodig rules. The OrderEtry referece i the HTTP header is the ame of the program to be ivoked at the xmlbus.com Web site. The HTTP bidig specifies the locatio of the service SOAP Header The header, a optioal part of a SOAP message, ca occur multiple times, if it occurs at all. The sematics, or meaig, of each header is typically defied withi a associated XML schema. The ame of the top-level elemet i the header block ca be used to map the block to the sematics defied i the associated schema. The header elemet is a child elemet of the evelope. Headers are optioal ad ca be multiple Headers are the mai mechaism by which SOAP ca be exteded to iclude additioal features ad fuctioality, such as security, trasactios, ad other quality-of-service attributes associated with the message. The header is ecoded as the first immediate child elemet of the SOAP evelope. Whe more tha oe header is defied, all immediate child elemets of the SOAP header are iterpreted as SOAP header blocks. Headers are iteded to add ew features ad fuctioality The SOAP header cotais header etries defied i a amespace. The iformatio i the headers is used alog the message path somewhere ad is ot always iteded for use at the ultimate SOAP processor destiatio, although, of course, it may be. The headers may have attributes, such as a ecodig-style URI or a actor URI, for itermediaries that process thigs, such as user ame/password, ID for reliable messagig, or a digital sigature for security checkig. Header etries are defied i a amespace Stadard Headers Needed The header mechaism i SOAP, imprecisely coceived ad defied, was iteded for use by specific applicatios built atop the base protocol, providig a place i which to defie SOAP extesios. Of course, for such extesios to be geerally meaigful, they eed to be stadardized. This is part of the work that eeds to be doe to complete Web services: to defie stadard SOAP headers for security, trasactios, process flow, routig, message correlatio, guarateed message delivery, ad so o. However, util Page 89

91 oe or more other W3C workig groups start to defie stadards for them, SOAP headers are likely to remai cofusig ad ill-defied. There is o compellig reaso yet to use them. Applicatio-specific iformatio ca just as easily be carried i the SOAP body. Headers iclude a attribute called mustuderstad, which allows seders ad receivers to egotiate agreemet o support of a give header or set of headers. This attribute is the same as the madatory attribute i the HTTP Extesio Framework, to which the SOAP specificatio also provides a mappig. Thus the mustuderstad attribute, like may other aspects of SOAP, is a carryover of a cocept defied origially i HTTP. The itet of this cocept is to allow applicatios built usig the older versios of the specificatio, or the applicatios ot up to the same revisio level as ew applicatios, to fail gracefully whe they receive a message that they do ot uderstad. For example: <SOAP-ENV:Header> <t:trasactio xmls:t=" SOAP-ENV:mustUderstad="1"> 5 </t:trasactio> </SOAP-ENV:Header> A seder ca require the receiver to uderstad a header The example shows a possible header for trasactio support, which is ot yet defied, that uses the mustuderstad attribute to require the receiver to support trasactios if the seder wats to use them. If the receiver of the SOAP message does't support trasactios, the receipt of such a message will geerate a SOAP fault. Headers ca require SOAP processors to uderstad them or to reject the message Whe a header block is tagged with a SOAP mustuderstad attribute with a value of 1 or True, the targeted SOAP ode must process the SOAP block accordig to the requiremets of the header or ot process the SOAP message at all ad retur a error code. Headers are for addig features to a SOAP message i a decetralized maer without prior agreemet betwee the commuicatig parties. But SOAP does ot defie ay headers, ad it's ot clear which headers will be used, although SOAP does defie some attributes for use with the headers i aticipatio of such use. Headers allow decetralized additio of features to SOAP I desigig the headers, the specificatio authors aticipated that a wide variety of header fuctios would be developed over time. Each SOAP ode may iclude the software ecessary to implemet oe or more such extesios. A SOAP header block is uderstood by a receivig Page 90

92 SOAP ode if the software at that SOAP ode has bee writte to fully implemet the sematics coveyed by the fully qualified ame of the outermost elemet of that block, that is, by the sematics defied i the associated schema for that elemet ame. SOAP Body The SOAP body cotais the applicatio-defied XML data beig exchaged i the SOAP message. The body must be cotaied withi the evelope ad must follow ay headers that might be defied for the message. The body is defied as a child elemet of the evelope, ad the sematics for the body are defied i the associated SOAP schema. The body cotais iformatio that must be set to the ultimate recipiet The body cotais madatory iformatio iteded for the ultimate receiver of the message. For example: Request <SOAP-ENV:Evelope... <SOAP-ENV:Body> <m:getorderstatus xmls:m=" <ordero>12345</ordero> </m:getorderstatus> </SOAP-ENV:Body> </SOAP-ENV:Evelope> Respose <SOAP-ENV:Evelope... <SOAP-ENV:Body> <m:getorderstatusrespose xmls:m=" <status>shipped Jue 18</status> </m:getorderstatusrespose> </SOAP-ENV:Body> </SOAP-ENV:Evelope> The precedig body portio of two typical RPC-orieted SOAP messages shows a request ad a respose for a order status service. The request seds the order umber, ad the respose message returs the most recet status. A GetOrderStatus request is set to the OrderEtry service. The request takes a iteger the order umber ad returs a strig i the SOAP respose. The XML amespace is used to qualify applicatio-specific elemet ames. Normally, the applicatio also defies a schema to cotai sematics associated with the request ad respose elemets. The OrderEtry service might be implemeted usig a EJB ruig i a applicatio server; if so, the SOAP processor would be resposible for mappig the body iformatio as parameters ito ad out of the EJB implemetatio of the OrderStatus Page 91

93 service. The SOAP processor could also be mappig the body iformatio to a.net object, a CORBA object, a COBOL program, ad so o. The SOAP processor maps the request ad respose iformatio to a EJB or other program SOAP Faults Whe a error occurs durig processig, the respose to a SOAP message is a SOAP fault elemet i the body of the message, ad the fault is retured to the seder of the SOAP message. For the HTTP bidig, a successful respose is liked to the 200 to 299 rage of status codes; the SOAP fault is liked to the 500 to 599 rage of status codes. The SOAP fault mechaism returs specific iformatio about the error, icludig a predefied code, a descriptio, the address of the SOAP processor that geerated the fault, ad applicatio-geerated details about the error, if it occurred while processig the body block. A fault is retured whe a SOAP message ca't be processed A SOAP respose message ca carry a sigle fault block i the body of the message. Cotaied withi the SOAP fault body block are the followig subelemets: <faultcode>: a software-geerated XML qualified fault ame qualified as either Seder or Receiver, depedig o whether the message was foud to be icorrect o receipt or a error occurred durig processig of the message <faultstrig>: associated with the fault code, a explaatory text that describes the problem, similar to the Reaso-Phrase defied i HTTP <faultactor>: a URI idetifyig the address of the SOAP processor that geerated the fault <detail>: applicatio-specific iformatio about the fault, required whe the message could ot be successfully processed A message ca carry oly oe fault block Error iformatio geerated whe processig header blocks must be carried i the header blocks themselves o a respose message. If the <detail> elemet is ot filled i, the fault was ot related to processig the cotets of the body block. This sigifies whether the body was processed at all. Fault codes are defied i the SOAP evelope schema. For example: HTTP/ Iteral Server Error Cotet-Type: text/xml; charset="utf-8" Cotet-Legth: <ev:evelope xmls:ev=" soap/evelope"> Page 92

94 <ev:header> <V:Upgrade xmls:v=" soap-upgrade"> <evelope qame="s1:evelope" xmls:s1=" soap-evelope" </evelope> </V:Upgrade> </ev:header> <ev:body> <ev:fault> <faultcode>ev:versiomismatch</faultcode> <faultstrig>versio mismatch</faultstrig> </ev:fault> </ev:body> </ev:evelope> The presece of the detail elemet idicates that a error occurred durig body processig As show i the example, a SOAP processor geerates a fault respose whe uable to uderstad a previous versio of the specificatio. For the HTTP mappig, the fault correspods to the HTTP 500 error, ad the body block of the respose cotais the <fault>, <faultcode>, ad <faultstrig> elemets. Because the fault was geerated by the ultimate recipiet of the message, the <faultactor> elemet is optioal ad is ot icluded. A fault geerated by a itermediary is required to cotai a <faultactor> elemet, however. Ad because the fault was geerated as a result of a versio mismatch, ot while processig a a body block, the <detail> elemet is ot icluded. The <detail> elemet is icluded oly whe the fault occurs durig the processig of a body block. Note the v1.1 amespace used for the evelope, which idicates that the fault was geerated by a v1.1-compliat SOAP processor that received a v1.2 SOAP message it could't uderstad. For aother example: HTTP/ Iteral Server Error Cotet-Type: text/xml; charset="utf-8" Cotet-Legth: <ev:evelope xmls:ev=" soap-evelope" > <ev:body> <ev:fault> <faultcode>ev:server</faultcode> <faultstrig>server Error</faultstrig> <detail> <e:myfaultdetails xmls:e=" > <message> Page 93

95 The database was uavailable </message> <errorcode>1001</errorcode> </e:myfaultdetails> </detail> </ev:fault> </ev:body> </ev:evelope> The example illustrates a SOAP fault block geerated as the result of a failure durig the processig of a body block. Agai, the HTTP 500 error is retured alog with the fault respose. This time, however, the <detail> elemet is provided to give additioal iformatio about the error that caused the fault block to be retured, i this case to sigal that processig failed because the database was uavailable. RPC Covetio The SOAP specificatio icludes a optioal defiitio of how to ecapsulate remote procedure call (RPC) fuctioality usig XML. For the RPC-orieted iteractio patter, this is the heart of SOAP. Requiremets for the RPC mappig iclude providig a URI for the target SOAP ode, a procedure or method ame, a optioal procedure or method sigature, ad the parameters to the procedure or the method. Optioal header data ca be icluded to pass security iformatio, trasactio cotext, or other attribute iformatio that may be associated with the procedure call. A major feature is mappig SOAP messages to remote procedure calls SOAP relies o the uderlyig trasport mechaism, such as HTTP, to carry the URI address of the message destiatio. Life-cycle maagemet for the objects accessed via Web services are outside the SOAP spec, but it is possible to sed cookies via the SOAP headers to implemet such additioal features at the applicatio level. A RPC ivocatio is modeled as a sigle struct cotaiig a accessor for each i or i/out parameter. The struct is amed ad typed idetically to the target procedure or method ame. Each i or i/out parameter is viewed as a accessor, with a ame correspodig to the type of the parameter, i the same order as i the target procedure or method. (See Data Type Mappig later i this chapter for further iformatio o SOAP data types.) RPC ivocatios are modeled as structs The request struct ame is idetical to the method ame so that the mappig occurs correctly. The respose struct ame is defied usig a amig covetio that makes it easier for the SOAP processor to map the respose from a program. For the RPC mappig, the use of headers roughly correspods to the use of attributes i the rutime eviromet for the target procedure or method, such as what may be defied for a EJB cotaier or.net package attributes. Page 94

96 A respose message idicates that the request message was successfully processed. A fault message idicates that a failure occurred either before or durig message processig. A SOAP processor caot retur both a respose message ad a fault message. The result ca be a fault message or a respose message, but ot both The followig example illustrates a request/respose SOAP message defiitio. The example cotais a SOAP message i the form of a request to a purchase order service that totals the purchase order ad returs the total value of the order. The customer ca the decide whether to cofirm the order. <?xml versio="1.0"?> <SOAP-ENV:Evelope xmls:soap- ENV=" xmls:xsd=" xmls:xsd1=" xmls:soap- ENC=" xmls:xsi=" <SOAP-ENV:Body> <s1:postpurchaseorder xmls:s1=" <order xsi:type="xsd1:purchaseorder"> <CompayName xsi:type="xsd:strig">iona</compayname> <Items xsi:type="soap-enc:array" SOAP-ENC:arrayType="xsd1:Item[1]"> <item xsi:type="xsd1:item"> <Price xsi:type="xsd:float">129.99</price> <PartID xsi:type="xsd:strig">1234</partid> <Descriptio xsi:type="xsd:strig"> SkateBoots </Descriptio> <Quatity xsi:type="xsd:it">40</quatity> </item> </Items> <Address xsi:type="xsd1:address"> <State xsi:type="xsd:strig">ma</state> <PostalCode xsi:type="xsd:strig">02451</postalcode> <City xsi:type="xsd:strig">waltham</city> <Lie2 xsi:type="xsd:strig"></lie2> <Coutry xsi:type="xsd:strig">usa</coutry> <Lie1 xsi:type="xsd:strig">200 West Street</Lie1> </Address> </order> Page 95

97 The example icludes a referece to the associated XML schema for the applicatio-defied parts of the message (PurchaseOrderService-xsd) ad the post request (postpurchaseorder), which also uses a XML amespace to qualify the elemet ames i the request. The two major categories of data types are show, icludig a simple, schemastadard strig type for the CompayName, ad a custom- defied SOAP array type for the items. Note that the custom-defied array is icluded withi the PurchaseOrderService-xsd schema. Importace of Data Typig The RPC mappig is a example why data typig is so importat, especially for structs. Structs ad complicated data types are used for RPC method ame ad argumet mappig. Without them, it would be much more difficult to defie the specific way i which data i the SOAP body could be mapped ito ad out of procedures or objects usig remote calls. As it is, SOAP implemetatios geerally decode the iformatio i the structs ad create remote procedure call sigatures for Eterprise JavaBeas,.NET objects, CORBA objects, COBOL programs, ad so o. Without the defiitio of arrays, accessors, ad structs i SOAP, each implemetatio would have to desig ad build this type of mappig idividually, i a proprietary fashio. So although the array ad struct defiitios i the SOAP data types may appear complex ad uecessary, they are helpful i the key area of mappig SOAP messages to remote procedure ad object ivocatios. The followig example illustrates the Java programmig laguage class defiitio for the implemetatio behid the purchase order example. A Java or C# class implemets the executable service public class PurchaseOrderService { public float postpurchaseorder(purchaseorder order) { Item items[] = order.getitems(); float total = 0.0f; for (it x = 0; x < items.legth; x++) { total += items[x].getprice()*items[x].getquatity(); } retur total; } This very simple example, which could just as easily have bee a C# or VB.NET class shows executable code providig a Web service implemetatio to which a SOAP message ca be set. Other programs are, of course, required to accept ad to geerate the SOAP messages themselves. The associated XML schema cotais sematic iformatio, or a kid of "programmig istructio" that the programs ca key off of to uderstad how to process the service. As show i the examples, the SOAP RPC mappig covetio refereces a method ame i the HTTP POST request. Because SOAP defies a oe-way messagig model, a request does't require SOAP respose; the respose ca be empty. The respose ca also be a fault (see SOAP Faults later i this chapter). Page 96

98 Schemas cotai sematic iformatio to istruct the uderlyig service implemetatio <?xml versio='1.0' ecodig='utf-8'?> <SOAP-ENV:Evelope xmls:soap-env=" xmls:xsd=" xmls:xsd1=" xmls:soap-enc=" xmls:xsi=" <SOAP-ENV:Body> <s1:postpurchaseorderrespose xmls:s1=" <retur xsi:type="xsd:float">5199.6</retur> </s1:postpurchaseorderrespose> </SOAP-ENV:Body> </SOAP-ENV:Evelope> This example illustrates the respose to the SOAP request show i the previous example. [4] The same schema is used (PurchaseOrderService-xsd), ad the method ame, postpurchaseorderrespose, uses the SOAP covetio of amig the result i correspodece to the request. The retur uses a simple stadard float data type. [4] Note that both examples use the v1.1 amespaces. Is the RPC Covetio Part of the Protocol or Not? The RPC represetatio, or covetio, for SOAP is the subject of some cotetio i the SOAP commuity ad is optioal i the curret specificatio draft. The protocol does ot guaratee that a respose message will be related to a request message; it has to be doe programmatically by the applicatio, possibly usig correlatio IDs passed i header blocks. SOAP is a oe-way messagig system, although request/respose patters ca be achieved, ad WSDL supports them as well. Some specific additioal bidigs for example, to IIOP i a LAN eviromet to protocols beyod those i the specificatio ca be used to make this more explicit or required. Some qualities of service, or attributes of the message, are iteded to be iherited from the uderlyig trasport. Part of the SOAP commuity aticipates a solutio through mappig SOAP to BEEP, but the time ad effort required to lauch a ew Iteret protocol leave this potetial solutio i some doubt. Others i the SOAP commuity propose addig spec defiitios that require the respose correlatio to be part of SOAP itself: for example, by defiig a required correlatio ID header, which may be a more practical resolutio. The atural mappig of HTTP POST to the request message ad HTTP reply to the respose message esures at least that the respose will be retured usig the same HTTP coectio as the request but is ot guarateed if the HTTP coectio is lost. Data Type Mappig Page 97

99 The SOAP ecodig style is iteded to be geeralizable across ay programmig laguage or database maagemet system. However, if the SOAP ecodig style does ot fit a particular software system's requiremets, aother ecodig system ca be used. SOAP is completely flexible ad extesible i this regard, but both seder ad receiver have to use the same ecodig scheme. SOAP data types ca be simple, such as iteger, float, text, or date, as defied i XML schema laguage. Or, they ca be complex, such as structures ad arrays, as defied i the SOAP ecodig schema or alterative. Simple SOAP data types are the same as schema data types Data types are defied usig a schema, which is used to geerate a XML grammar for the data types. Give the type system schema ad a graph of values coformig to that schema that is, a buffer area cotaiig the data to be mapped a XML istace ca be geerated. I reverse, give a XML istace produced accordig to the rules ad give access to the origial schema, the origial data types ca be recostructed. XML istaces are geerated by mappig iput data to schemas Give a existig data type defiitio, Web services are defied so that the types ca be mapped to a XML schema. If output from a existig system ito a file, for example, or a memory area, the data ca be used as a source of iput for geeratig a XML istace. First, the existig schema or data type defiitio is mapped, or trasformed, ito a correspodig XML schema. Next, the XML schema is used with the data output to a file or memory to geerate a XML documet cotaiig those values. Fially, the XML documet is trasmitted from seder to receiver, usig SOAP. The ecodig amespace has to be used to qualify elemet ad attribute ames if the SOAP ecodig is used. Compoud values defied i the SOAP ecodig have accessors that poit to a specific value withi the structure or the array. Arrays ca be ested or ca cotai structures; ested arrays ca be of types differet from the eclosig arrays. Arrays ad structs are used to cotai the iformatio required to describe a RPC-style iteractio i particular, how the arrays ad structures are accessed. Although it is possible to use the xsi:type attribute such that a graph of values is selfdescribig both i its structure ad the types of its values, the serializatio rules permit that the types of values may be determiate oly by referece to a schema. I other words, it's possible, but ot required, to restrict type defiitio to a schema. HTTP Bidig The SOAP specificatio allows for the possibility of multiple trasport bidigs, although bidig to HTTP is the oly oe curretly defied. Other mappigs have bee successfully defied for SOAP to SMTP, BEEP, JMS, IIOP, ad others, however. The HTTP bidig esures that SOAP messages are cosistet with HTTP's message model ad idicate to HTTP servers that a SOAP message has arrived. HTTP servers ca therefore act o a Page 98

100 SOAP message by kowig that it's SOAP, rather tha simply a XML documet carried the way a HTML documet would be carried. The HTTP bidig esures that SOAP messages are carried correctly over HTTP The bidig works for HTTP POST requests. A SOAP itermediary is ot the same as a HTTP itermediary. Oly a HTTP-origi server ca be a SOAP itermediary, a fully fuctioal SOAP processor capable of receivig ad sedig SOAP messages. A SOAP Actio header field, if ay, caot be computed; the seder must kow it i advace. The SOAP Actio idicates the itet, ot the defiitio, of the message. The SOAP Actio is like a processig istructio to the SOAP processor, triggerig a certai predefied actio associated with the message, such as routig it to a JMS queue or forwardig it to aother SOAP processor behid the firewall. I the v1.2 specificatio draft, iformatio about the target of the SOAP message is cotaied withi the HTTP header itself, ad the SOAP Actio header field is ot eeded. Versio Cotrol SOAP, like ay other protocol, evolves over time. SOAP v1.1, for example, is the versio origially submitted to the W3C, whereas SOAP v1.2 is the curret workig draft versio published by the W3C after the XML Protocols Workig Group made some revisios to the specificatio. More tha 80 implemetatios of the v1.1 specificatio exist or have bee released o the market. May of these implemetatios will adopt the v1.2 specificatio, but presumably ot all at oce or i a coordiated fashio. Furthermore, applicatios may have bee deployed already based o v1.1 implemetatios, whereas other, ewer applicatios may be deployed based o v1.2 implemetatios. What happes whe a v1.1 implemetatio seds a message to a v1.2 implemetatio ad vice versa? SOAP versioig is hadled via amespace revisio This is, of course, a very commo problem for stadards ad techologies that evolve. Usually, stadards ad techologies strive to be upwardly compatible, meaig that a ewer versio ca iteroperate with a older versio. That a older versio iteroperates with a ewer versio is less ofte possible. How ca the older versio kow what chages have occurred i the ewer versio? To hadle this problem, SOAP defies ew amespaces. The v1.1 SOAP evelope amespace is The v1.2 draft SOAP evelope amespace is The v1.2 amespaces are chaged as ew specificatio drafts are published. For example, the "2001/12" idicates the December 2001 workig draft. Whe the evelope schema chages for a ew versio of SOAP, both the seder ad the receiver will have to uderstad it i order to take advatage of ew features i the revisio. As SOAP Page 99

101 evolves ad chages, the SOAP evelope schema has to chage to add the ew features, correctios, ehacemets, ad so o ad must do so i a upwardly compatible way. Schema chages idetify versio chages A SOAP processor is therefore resposible for checkig the evelope amespace for compatibility with the curret versio. If it is't compatible, the SOAP processor has to treat this as a versio mismatch error ad geerate a VersioMismatch SOAP fault. A v1.2 SOAP processor, o the other had, may optioally choose to process a upwardly compatible SOAP v1.1 message or otherwise to geerate a VersioMismatch fault. A SOAP v1.2 processor ca list the evelope versios it supports, usig the SOAP upgrade amespace idetifier. SOAP Message Processig I geeral, SOAP messages like the oes i the examples must be viewed together with their associated XML schemas, which tell the cosumers of SOAP messages how to uderstad them. The most popular format for such XML schemas is WSDL (see Chapter 3). The SOAP amespaces for evelope ad ecodig have schemas associated with them, too. Schemas defie how to iterpret messages The followig example, take from the SOAP evelope schema, defies the major SOAP parts: <xs:schema xmls:xs=" xmls:ts=" soap-evelope"targetnamespace=" 2001/12/soap-evelope"> <xs:elemet ame="evelope" type="ts:evelope" /> - <xs:complextype ame="evelope"> - <xs:sequece> <xs:elemet ref="ts:header" mioccurs="0" /> <xs:elemet ref="ts:body" mioccurs="1" /> </xs:sequece> <xs:ayattribute amespace="##other" processcotets="lax" /> </xs:complextype> At the top of this example is the SOAP evelope schema, foud at the SOAP evelope amespace URI: The amespace is used i the schema to qualify SOAP evelope schema ames. The top-level elemet is the Evelope elemet, which cotais the Header ad the Body elemets. The Header elemet is optioal ad therefore has a mioccurs of 0; the Body is required ad has a mioccurs of 1. SOAP processors are required to obtai ad to use this ad other schemas defied for SOAP whe hadlig messages. Page 100

102 The seder ad the receiver of SOAP messages must use the same serializatio format, i order to correctly parse ad iterpret the message. The seder ad receiver eed the schema for the SOAP evelope itself; a schema for the optioal SOAP ecodig mechaism, if ay; ad schemas for ay optioal headers used. Ad, of course, there are schemas for applicatio-specific data elemets i the body. All applicatio-specific schemas associated with SOAP messages have to be selfcotaied; that is, SOAP processors are't allowed to import applicatio-defied attributes, values, or processig istructios from the applicatio-defied schemas. Seder ad receiver eed to have the same schemas The SOAP ecodig-style schema is available at the ecodig-style amespace URI: The ecodig schema cotais defiitios for all simple ad complex data types that ca be used with the optioal SOAP ecodig, icludig a base64 type for serializig biary data. The ecodig style is defied i a schema The schemas for validatig the various parts of the SOAP message are ormally posted o the Iteret by the SOAP receivers ad have to be dowloaded by ay party i a exchage of messages to esure that they are geerated ad uderstood correctly. The schemas may also be discovered i a UDDI or a ebxml registry (see Chapters 5 ad 6) or by usig the Web services ispectio laguage (WS-Ispectio). For more o this, see Chapter 7. Applicatio-defied schemas validate applicatio data Optioal header schemas ca be defied to iclude iformatio about the RPC-style iteractio, if eeded, or to carry other geeral iformatio about the message, such as priority ad expiratio time, security iformatio, mail-to addresses for the message, if ay, or paymet codes for purchase orders. Headers are iteded to provide a extesibility mechaism for addig features ad capabilities to SOAP. I geeral, both seder ad receiver should support the same headers, usig the same schemas or compatible schemas defied for the headers. Some SOAP implemetatios, however, may support a egotiatio phase durig which they ca agree ot to support the same headers. Optioal header schemas ca be defied The header ad body parts of SOAP work together to esure that what's iteded to be commuicated betwee the parties is commuicated, with the appropriate qualities of service, ad that SOAP messages are mapped correctly to the uderlyig service implemetatio. Header ad body are related Page 101

103 The SOAP Actio attribute (optioal i the v1.2 draft) is part of the HTTP bidig ad provides additioal iformatio iterpreted by the receiver of the message for example, to post the message to a message queue. I additio, a attribute ca be defied to idetify a itermediate destiatio for header iformatio. I the v1.2 draft, actor attributes have bee expaded to idicate which SOAP ode is resposible for processig which header. This is to clarify which itermediaries, if ay, process which headers. Actor attributes idetify itermediaries, if ay Header Subtleties Normally, the seder of a SOAP message will obtai all the receiver's schemas i advace. I other words, the typical Web service model ivolves dowloadig the WSDL file from the receiver ad geeratig a SOAP message coformig to the receiver's schema(s). So it would seem that the seder would have to kow i advace whether the receiver supported certai headers, makig the mustuderstad attribute irrelevat. Ad it would also seem that without explicitly defied support i WSDL for headers, actors, ad itermediaries, these mechaisms wo't be used. Fially, the idea of supportig itermediaries idepedet of SOAP seder/receiver pairs likely will be realized oly after SOAP itself is widely adopted ad used. All the fuctioality i Web services fudametally seems to require egotiatio ad agreemet betwee seder ad receiver i advace rather tha at coectio or discovery time, throwig doubt oto the usefuless of the SOAP header model for itermediary processig. As oted previously, itermediaries alog the message path ca operate o message headers. [5] For example SOAP headers ca be extracted or supplemeted at a itermediary, ad parts of the SOAP header ca be used to idicate which itermediary hadler is to be used to process which header. [5] The SOAP specificatio does ot, however, iclude ay routig protocol. IBM ad Microsoft have joitly published WS-Routig, a proposal for that purpose, however. See Chapter 7 for a summary of WS-Routig. Messages ca be routed through itermediaries that process headers A SOAP ode is the etity that processes a SOAP message accordig to the SOAP specificatio rules to access the services provided by the uderlyig protocols through SOAP bidigs. The SOAP specificatio defies a correlatio betwee the parts, or blocks, of a SOAP message ad software hadlers are desiged to hadle, or process, each part of the message i the appropriate way. Message processig ivolves mappig to the uderlyig services Page 102

104 Some implemetatios may develop specific hadlers for each part of the SOAP message ad work from clues i the major SOAP elemets to determie which parts of the message are appropriate for which hadler. I geeral, SOAP block hadlers key off of elemet ad attribute ames that associate the sematics i the schema with the elemets eclosed withi the blocks. Implemetatios may hadle blocks differetly A SOAP processor ca be a seder, a receiver, or a itermediary, which is both a seder ad a receiver; a attribute ca idicate that a give header is iteded for a itermediary. A coformig SOAP processor has to validate the SOAP evelope, usig the SOAP evelope schema. The SOAP processor has the implicit requiremet to uderstad the SOAP schema ad to raise errors if DTD elemets ad processig istructios are used i other words, if the message violates the subset defiitio of XML used i SOAP. SOAP processors have to follow a certai order A SOAP message is a XML documet that coforms to certai rules set dow i the specificatio, ad applicatios that process SOAP messages have to coform to other rules set dow i the SOAP specificatio. For example, the specificatio says that implemetatios of SOAP processors ca provide sematic equivalece to the order i which the message must be processed. That is, as log as the implemetatio comes up with the same results, the parts of a message ca be processed i a order other tha that defied i the specificatio. SOAP processors have to eforce the XML subset used for SOAP messages A SOAP processor must first check to see whether the SOAP message cotais ay header with the mustuderstad attribute set to 1 or True, meaig that the processor must uderstad the header. If the message cotais a header with such a attribute ad the processor does't uderstad the header, the processor must retur a fault ad immediately stop processig the rest of the message. SOAP processors first have to check the mustuderstad attribute, if ay Next, the processor must check the SOAP blocks iteded for it ad process them, icludig ay headers. Uless the order is costraied i a applicatio-specific optioal header, the blocks ca be processed i ay order. SOAP processors, icludig itermediaries, must be able to access the etire evelope durig processig. Itermediaries ca process, remove, or add headers if they are targeted with a attribute at the itermediaries. This is a way to forward a message ad to have the itermediary redirect the message to a ew address, potetially with additioal or chaged istructios about Page 103

105 how to process the message. If it does ot recogize some of the blocks or elemets i the message, a itermediary must igore them ad forward them. The itermediary ca remove headers ad add headers, as log as the removed headers are iteded for the itermediary. SOAP itermediaries ca process headers but ot the body SOAP applicatios also have to be able to process amespaces, ad all SOAP messages should be ecoded i XML. The processor has to discard messages that do ot have correct amespaces, but it ca process SOAP messages without amespaces, if it wats to. SOAP Use of Namespaces SOAP messages use amespaces to qualify elemet ames i the separate blocks, or parts, of the message. Applicatio-specific amespaces are used to qualify applicatio-specific elemet ames. The curret v1.2 SOAP-defied amespaces are for elemets ad attributes defied for the mai or madatory parts of the documet for elemets ad attributes defiig the data types of the optioal serializatio mechaism to qualify fault code ames used i fault messages : to qualify the list of versios that a SOAP processor supports Namespaces qualify block ames ad specify attributes A SOAP message a XML documet with a madatory evelope, a optioal header, ad a madatory body uses XML amespaces to qualify elemet ad attribute ames withi the various parts of the documet. Some elemet ames are global, or refereced throughout the etire SOAP message, but most are local, or scoped via amespaces to the particular part of the message i which they are foud. XML amespaces scope local elemet use withi SOAP parts SOAP uses the local, uqualified attribute of type ID to specify the uique idetifier of a ecoded elemet. SOAP uses the local, uqualified attribute href of type ay URI to specify a referece to that value. Relative URIs are resolved usig XML Base. Chages i the v1.2 Draft The major chage for v1.2 is that the SOAP specificatio is ow based o a abstract XML Iformatio Set defiitio, icludig serializatio rules. Esurig that SOAP specificatio sytax has a Iformatio Set defiitio helps other Web services techologies more easily cosume, uderstad, ad exted SOAP messages. Additioal chages i v1.2 are as follows: Page 104

106 The SOAP acroym is ot spelled out. The specificatio is split ito two major ormative parts ad a iformative primer: Part 0, Primer; Part 1, Messagig Framework; Part 2, Adjucts. [6] Geerally speakig, Part 0 provides a tutorial o the SOAP specificatio, Part 1 describes the required parts of SOAP, ad Part 2 describes the optioal parts. [6] See for draft updates. The v1.2 specificatio is i draft form as of this book's publicatio date, ad is subject to further chage. No elemet is permitted after the body elemet. New fault codes have bee added for MustUderstad ad DTDNotSupported. I the HTTP bidig, text/xml has bee replaced with applicatio/soap+xml to create a SOAP cotet category explicitly for HTTP. (HTTP filters ca therefore more easily idetify SOAP messages.) Fault codes o loger use dot otatio for qualifyig the ames, ad detail has bee added for helpig to iterpret SOAP faults ad HTTP status codes. A explicit <respose> elemet was added to the RPC mappig to make it easier to correlate requests ad resposes for this iteractio style. SOAP v1.2 itroduces several chages I geeral, as SOAP is beig developed ad improved, its relatio to other XML specificatios is beig clarified. Difficulty i Writig about Evolvig Specs This chapter mixes examples ad descriptios from the SOAP v1.1 ad v1.2 draft specificatios. It's difficult to write about a specificatio i progress. It appears that the major cotroversies iclude the divisio of required ad optioal fuctioality, the defiitio ad role of headers relative to body iformatio, ad appropriately defiig a message path ad the role of SOAP processors alog it. As is ofte the case with committee drafts, may of the chages i the specificatio are the result of compromise, which raises the questio of whether v1.2 will be a true improvemet over v1.1 ad the extet to which specificatio chages will, i fact, be adopted. This chapter takes a best guess at which chages will make the fial cut ad icorporates them ito the examples ad text. SOAP Multipart MIME Attachmets The SOAP with Attachmets specificatio is accepted as a ote at W3C, adopted by the ebxml ad RosettaNet cosortia, ad uder cosideratio at the XML Protocols Workig Group. This specificatio solves the problem of sedig biary data or etire XML documets. Without the SOAP with Attachmets specificatio, the processor has to uuecode or base64 biary data, which adds a lot of overhead. SOAP with Attachmets allows the SOAP message to be set withi a MIME evelope, with attachmets liked from withi the SOAP evelope. A cotet ID i the MIME evelope defies the SOAP message to be eclosed. For this to work, the schema defiig the relatioship has to be set up i advace. For example, to embed a photograph or a architectural drawig i a SOAP Page 105

107 attachmet, the message type has to be defied i advace to idicate to the SOAP processor what's beig set ad how. For example: <SOAP-ENV:Body> <photo> <photo1 href= "cid:[email protected]" /> </photo> </SOAP-ENV:Body> SOAP with Attachmets seds biary data ad large XML documets The cid prefix tells the SOAP processor that the lik is a referece to a attachmet withi aother MIME boudary. For example: Cotet-Type: image/jpg Cotet-Trasfer-Ecodig: biary Cotet-ID: "[email protected]"...image... Cotet IDs tell SOAP that the lik is to a attachmet withi aother MIME boudary This approach directs processig of the payload to a separate MIME part hadler. Each MIME part ca be processed by a separate hadler. The ebxml ad RosettaNet cosortia adopted this approach for its messagig trasport specificatio, placig the message headers ito the SOAP body ad referecig the actual documets via liks withi the body, carried as MIME attachmets. (See Chapter 6 for more iformatio o ebxml.) Both ebxml ad RosettaNet adopted SOAP with Attachmets SOAP i the Cotext of Existig Systems O receivig a SOAP message, perhaps formatted accordig to oe of the various emergig XML stadards, a SOAP processor may process the message ad route it to the appropriate e-commerce compoets ad/or existig applicatios. O the retur, the SOAP processor may gather the replies from the applicatios ad format the XML message appropriately for the type of request. SOAP messages ca be mapped to existig systems As show i Figure 4-2, SOAP messages may be itegrated with other Web services fuctios, usig a SOAP ad a XML schema parser. The Web Services Directory maager tracks the iterfaces exported to the Iteret ad maages them via the product's itegratio with the Page 106

108 Lightweight Directory Access Protocol (LDAP), UDDI, or the ebxml registry (see Chapters 5 ad 6 for more iformatio o UDDI ad the ebxml registry, respectively). Figure 4-2. SOAP supports existig applicatios. The SOAP processor also maitais a local resource maager to allow XML fragmets to be stored ad retrieved as eeded to create ad to parse SOAP messages. The XML cotet repository is used primarily to maage Web service cotet, but XML from the repository ca be extracted to produce SOAP messages. Fially, the back-ed XML adapter ca be used to route SOAP messages to ay umber of other applicatio servers, maiframe/legacy busiess systems, ad itegratio servers for complete ed-to-ed messagig. SOAP processors eed local metadata maagers Web services built usig SOAP ca easily be liked to other eterprise SOAP processors, idepedet of operatig system, programmig laguage, ad object model. Busiess applicatios itegrated with SOAP ca easily ad quickly exchage formatted XML messages with other busiesses across the Iteret. SOAP's Future Directios SOAP v1.2 is a simple yet extesible mechaism for bridgig Web services across the Iteret, regardless of platform, laguage, or object model. A cosiderable list of features ad fuctioality Page 107

109 is missig, compared to a more complete distributed object system, such as CORBA or.net, icludig Security Trasactios Quality-of-service policies Object refereces Garbage collectio Fault tolerace Work flow or busiess process flow SOAP cotiues to be ehaced ad improved This Is Not Easy Stuff SOAP does ot defie a object model, laguage bidigs, or sematics relative to the uderlyig systems beyod the requiremet to accept ad to process a XML documet i the form of a SOAP message. SOAP addresses oly the wire. But this also idicates the extet to which thigs are left udefied relative to what's already bee defied for.net, CORBA, ad J2EE, i which ot oly data is passed but also a method ame is ivoked, ad the data ad sematics are tied to the method ame ad the defiitio of the respective object model. Also, these distributed computig techologies iclude defiitios for security, trasactios, guarateed messagig, ad other trasport-level qualities of service. Although it's helpful to separate the cocept of data mappig from the uderlyig software ad to trasport data i a maer that ca be mapped ito ad out of virtually ay existig program, the lack of completeess i the SOAP documet also makes it highly subject to iterpretatio, susceptible to proprietary extesios, ad difficult to esure that iteroperability will be preserved as extesios are defied. Several of these features are uder developmet at W3C, OASIS, or idepedet cosortia; however, it may take a cosiderable time before all these features ad fuctios are part of stadard Web services. Oce the questio of SOAP stadardizatio is settled, it is hoped that the questios of ehacemets ad extesios ca be quickly addressed. Some of the work i progress is preseted i Chapter 7. It's ulikely that SOAP will ever address the level of detail foud i existig object models ad distributed computig systems, but it's very likely that more ad more of the mappig to ad from these systems will be automated or made easier. Summary The Simple Object Access Protocol (SOAP) makes it possible for Web services to exchage data, o matter where they are located i the etworked eviromet. SOAP is mapped to HTTP by default ad iherits some qualities of service from its bidig to the HTTP request/respose protocol. SOAP is desiged to be mapped to other uderlyig trasport protocols, from which it might iherit other qualities of service. SOAP is a evolvig specificatio, with ogoig activity at W3C's XML Protocols Workig Group focused o producig a recommeded versio of the specificatio. Page 108

110 The desigers of SOAP iteded it to provide a simple, extesible mechaism for mappig to multiple types of messagig iteractios ad uderlyig software systems. SOAP is defied usig XML Ifoset, schemas, ad amespaces, which idetify ad scope the elemets for its major parts: evelope, header, ad body. Page 109

111 Chapter 5. Fidig Web Services: UDDI Registry After a Web service is set up, people must have a way to fid ad use the service. That's the purpose of the uiversal descriptio, discovery, ad itegratio (UDDI) registry, established by a idustry cosortium to create ad to implemet a directory of Web services. The UDDI registry accepts iformatio describig a busiess, icludig the Web services it offers, ad allows iterested parties to perform olie searches ad dowloads of the iformatio. To cotact a busiess to order somethig, you eed a way to fid iformatio about that busiess: street address, telephoe umber, Web site, or Web service address. You ca obtai the iformatio directly from a busiess represetative, perhaps i the form of a busiess card, hadwritte ote, or . You ca also look up a busiess ame i a telephoe directory ad obtai the address ad telephoe umber. UDDI fids the Web service address ad other iformatio about a busiess Similarly, the iformatio ecessary for a program ruig o your computer to talk to a program ruig o someoe else's computer over the Web must be published. Although UDDI is like a White Pages or Yellow Pages for Web services, it also eables developers to iteract with UDDI at both desig time ad rutime. I short, UDDI resources ca be cosidered part of the Web services architecture ad ifrastructure. UDDI is part of the Web services ifrastructure Whe you wat to iteract with a busiess's Web service to check ivetory availability before placig a order or to check for the right hotel, car, ad flight before makig a travel reservatio, you eed to be able to fid ad cotact the busiess's Web service. UDDI supports Web services iterface discovery If you do't kow the busiess ame or if you wat to compare several suppliers' terms ad coditios, the problem becomes greater, ad the eed for a geeric search ad discovery mechaism becomes more evidet. The UDDI registry provides such a mechaism ad is therefore importat to the ultimate success of Web services. Figure 5-1 illustrates the public UDDI service hosted by IBM, Microsoft, SAP, HP, ad potetially others. Each vedor provides a publicly accessible database cotaiig busiess registry data, posted via SOAP requests to oe of the vedor's data ceters ad replicated to the others. SOAP requests query the results of the posted updates to fid iformatio about busiesses to be cotacted, icludig metadata about a busiess's Web services. Figure 5-1. Multiple vedors host the public UDDI service. Page 110

112 UDDI operators host a replicated registry database The hosted databases are called operator sites, ad UDDI programmers use SOAP APIs to iteract with oe or more of the sites. The operators do ot charge for the basic UDDI service. Busiess data ca cotai poiters to Web services iterface specificatios, such as WSDL. Private UDDI services are ofte used to store a busiess's iteral iformatio, such as a list of available Web services. The UDDI Orgaizatio UDDI bega as collaboratio amog Microsoft, IBM, ad Ariba to promote the adoptio ad use of Web services stadards. The compaies fouded UDDI.org ad ivited other compaies to participate: some with fouders' rights ad others with advisory privileges. The compaies ivited as fouders set the groud rules, defied the iitial specificatios ad requiremets, ad decided o the evetual dispositio of the work. The three origial fouders were also the origial operators, or hosts, of the iitial public UDDI repository. Later, Hewlett-Packard joied the project ad replaced Ariba as a registry host site, ad SAP joied as aother operator. Other operators may joi over time if they meet the terms ad coditios set by the origial operators ad if the foudig membership agrees. Coverig UDDI Operator Costs Who will pay for the operator site costs over time? Today, IBM, Microsoft, HP, ad SAP are absorbig the costs of ruig the public registry, but as UDDI evolves ad gais acceptace, the cost issues will have to be addressed. For example, the sites already offer additioal services beyod the base specificatio requiremets, such as easy-to-use browser APIs. Whe UDDI is trasferred to a idepedet orgaizatio or Page 111

113 authority, as plaed whe versio 3 is completed, the idepedet orgaizatio will be faced with coverig the costs of operatig the public registry. It may be possible to charge for listigs, as the telephoe compay charges for Yellow Pages listigs, or to charge for added-value services. I ay case, if a public registry like UDDI becomes required for Web services to be a truly established ad successful part of everyday busiess operatios o the Iteret, it's ot clear how the cotiuig cost of the service will be bore, or by whom. More tha 300 compaies joied UDDI.org i support of the effort to establish a Web-hosted busiess directory of services. Fiftee of the compaies form the core Workig Group that is resposible for settig the strategic course of the project ad for resolvig coflicts ad makig decisios. The remaider are members of the Advisory Group, which allows a compay to review ad to commet o specificatio drafts before they're made public ad, o approval or ivitatio of oe or more of the Workig Group members, to joi oe of the specificatio draftig teams. More tha 300 compaies belog to UDDI.org The Workig Group members have the fial say o orgaizatioal issues ad specificatio decisios, but small teams, icludig compaies ot i the core membership, perform the work o specificatios. The specificatios developed by the teams are set for review ad approval to the etire membership before they are published. UDDI v2, o which this chapter is based, cotais ehacemets, such as publishig the operator ad replicatio specificatios, improvig the query capability, ad providig iteratioalizatio support. Workig Group members have the fial say UDDI.org aouced its itetio to complete v3 of the specificatios ad to submit them to a stadards body, perhaps W3C or OASIS, for further maiteace ad ehacemet. The foudig members did ot submit the work to a stadards body origially, because it's more efficiet ad effective to develop the specificatios i a private cosortium first; more progress could be made more quickly that way, they said. Also, UDDI is uique as a specificatios developmet group iasmuch as part of the core membership also hosts the public service based o the specificatios. UDDI v3 specificatios will be submitted to a idepedet stadards body The operators ru both a test site ad a productio site, allowig Web services providers ad busiesses to test their UDDI cliets before postig real iformatio to the productio database. Of course, before beig allowed to post the real iformatio to the productio database, a busiess eeds to be authorized to do so, ad the data eeds to be validated. To prevet spoofig ad wiretappig, commuicatio with UDDI requires ecrypted messages i the form of HTTPS. Amog the work items for UDDI 3 is improved security. Operators ru both test ad productio sites Page 112

114 Ogoig Role for the Fouders? What happes to the host, or operator, part of the orgaizatio oce the specificatios are placed uder the cotrol of a stadards orgaizatio: Will the operator sites also be placed uder idepedet cotrol? The issue is related as much to the dispositio of itellectual property i the form of specificatios ad workig agreemets as it is to the dispositio of real property i the form of computers, databases, ad etwork equipmet dedicated by private compaies to a public fuctio. Evetually, it seems clear, a public Web services registry is likely to require govermet regulatio to esure idepedet cotrol ad ope access. The Cocepts Uderlyig UDDI The public UDDI registry works a little like the Iteret domai ame service (DNS). Busiesses ca register with ay of the hosts IBM, HP, SAP, or Microsoft ad the iformatio they provide will be placed ito the database at that host site. At regular itervals, at least ightly, all iformatio placed ito oe of the host site databases is replicated to the other host site databases, esurig that they are all kept i sych. Users requestig data about a busiess ca the receive the same iformatio about a registered busiess from ay of the host databases. Whe it eeds to update the data, however, a busiess must retur to the origial site to which the data was placed ad execute the update fuctio. Registry replicatio works similarly to DNS For obvious reasos, security is a primary cocer of UDDI.org members. Busiesses are authorized to update iformatio by oe of the operators ad therefore must retur to the origial operator to chage or to delete ay iformatio they posted. Busiesses wishig to register with UDDI must first obtai authorizatio to do so ad must be approved by at least oe of the operators. Approval meas sedig to the busiess a authorizatio toke that allows the busiess to log oto the UDDI site ad to store or to update data. Authorizatio to update the registry is hadled by the operators idividually; logi iformatio from oe operator will ot work for aother. For all practical purposes, someoe registerig iformatio with UDDI has to choose oe of the operators ad stick with that operator. Security is a prime cocer Aother primary cocer is the quality, or validity, of the data. Someoe has to esure that the busiess beig registered is a real busiess; that the busiess ame, ID umber, category iformatio, phoe umber, Web page, ad street address are correct; ad that the busiess category ad geographical iformatio are correct. UDDI v2 is set up to allow third parties to do this ad does validate category data. Data validity is aother primary cocer Page 113

115 UDDI has two mai parts: registratio ad discovery. The registratio part meas that busiesses ca post iformatio to UDDI that other busiesses ca search for ad discover, which is the other part. Busiesses ad idividuals iteract with UDDI by usig SOAP APIs or oe of the user iterfaces provided by the operators or other Web services vedors. UDDI operators post WSDL descriptios of their Web services for registratio ad discovery. UDDI provides separate WSDL files for registratio ad discovery services, usig its ow XML documet format. The two mai parts of UDDI are registratio ad discovery Some UDDI SOAP APIs are used for isertig iformatio ito the registry; others, for browsig ad retrievig specific iformatio from the registry. UDDI APIs require a specific subset of SOAP; that is, UDDI does ot use the optioal seria lizatio format ad some other features defied i the SOAP specificatio. (See UDDI Support for SOAP ad Uicode, later i this chapter for further iformatio.) SOAP APIs are used to submit ad to retrieve data How UDDI Works UDDI iformatio is ofte described as beig divided ito three mai categories of busiess iformatio: White Pages: Busiess ame ad address, cotact iformatio, Web site ame, ad Data Uiversal Numberig System (DUNS) or other idetifyig umber. Yellow Pages: Type of busiess, locatio, ad products, icludig various categorizatio taxoomies for geo-graphical locatio, idustry type, busiess ID, ad so o. UDDI cotais White Pages, Yellow Pages, ad Gree Pages iformatio Issues with UDDI Acceptace Part of the problem that UDDI has to overcome is trust. I other words, will busiesses really trust private vedors to host ad operate such a thig? Aother issue is stadardizatio. I other words, will UDDI really become a recogized stadard? Usefuless of the model may also be questioed, meaig that the proposed categorizatio of busiesses, busiess iformatio, ad Web services iterface iformatio may ot prove to be useful. Fially, there is a thory legal issue with respect to doig busiess over the Web, icludig Web services. Is a busiess-to-busiess iteractio over the Web equivalet legally to a paper-documet exchage usig a fax machie or regular mail? Aother fudametal questio cofrotig UDDI ad its users is: What does it mea that busiesses are categorized? Does it somehow relate to cotact iformatio? Is't the most importat thig what a busiess sells rather tha its geographical locatio? Is the locatio of a busiess i a physical sese as relevat as what it supports i terms of iteractios over the Iteret? With all the outstadig questios about proper ad useful categorizatio, it's likely that the full realizatio of UDDI's potetial is several years away if ever. Page 114

116 Gree Pages: Techical iformatio about busiess services, such as how to iteract with them, busiess process defiitios, ad so o. A poiter to the busiess's WSDL file, if ay, would be placed here. Iformatio i this category describes a service's features/fuctioality, icludig a uique ID for the service. This category is quite ew ad specific to the Iteret. The data structure of UDDI is expressed usig complex types i XML schemas. These schemas allow for extesibility ad great flexibility i the data stored for a particular busiess or etity. UDDI data structures are expressed usig XML schemas Classificatio ad idetificatio iformatio is useful for searchig ad retrievig lists ad specific details about busiesses. Busiesses ca add ay umber of classificatios to their registratios for the purpose of assistig searches. Classificatio ad idetificatio iformatio icludes such thigs as IRS idustry codes, Du ad Bradstreet DUNS umbers, product codes, geographical codes, ad so o. Classificatios ad idetificatios are hadled via property bags, or ustructured data sequeces, i which virtually ay type of classificatio ad idetificatio iformatio ca be stored. UDDI stores classificatio ad idetificatio iformatio Flexible ad Extesible Data Structures The UDDI data structure provides so may optios ad extesios that it's almost impossible to predict the level of cosistecy that will be achieved amog etries for differet busiesses. I other words, it may be very difficult to predict the type of detail available for a give etry. If UDDI is ever to succeed, the data will have to be ormalized ad regularized a good deal more tha it is. Although UDDI is addressig this problem by publishig best-practices documets ad providig wizards for the registratio process, the problem remais. Classificatio taxoomies for category iformatio iclude the followig: North America Idustry Classificatio System (NAICS) Uiversal Stadard Products ad Services Classificatio (UNSPSC) Iteratioal Orgaizatio for Stadardizatio (ISO) (geographical regios, codes for coutries, ad so o) Operator sites validate category iformatio for idustry codes via NAICS, product ad service classificatios via UNSPSC, ad geographical codes via ISO However, icludig iformatio o ay or all of these categories is optioal, as is checkig this data whe registerig. Other classificatio taxoomies ca be used, but they are ot checked for validity. Operators validate some category iformatio Page 115

117 UDDI v2 supports checked ad uchecked classificatios ad idetificatios. Although UDDI does ot check or validate classificatio ad idetificatio iformatio beyod NAICS, UNSPSC, ad ISO 3166, UDDI.org does support a program that is meat to ecourage third parties to provide such a acillary service. Registered data ca be checked or uchecked UDDI Data Model UDDI registratio iformatio is comprised of the followig five data structure types: busiessetity, the top-level structure, describig the busiess or other etity for which iformatio is beig registered. The other structures are related via refereces from this structure. busiessservice, the ame ad descriptio of the service beig published. bidigtemplate, iformatio about the service, icludig a etry-poit address for accessig the service. tmodel, a figerprit, or collectio of iformatio uiquely idetifyig the service specificatio. This data structure also supports top-level searches. publisherassertio, a relatioship structure puttig ito associatio two or more busiessetity structures accordig to a specific type of relatioship, such as subsidiary or departmet of. UDDI idetifies five basic data structures Whe the data is submitted for the first time, the UDDI operator assigs a uique key that idetifies each of these data structures. The uique keys take the form of uiversally uique idetifiers (UUIDs), sometimes called globally uique idetifiers (GUIDs). The UUID format is derived from the Ope Software Foudatio (ow part of the Ope Group) Distributed Computig Eviromet; formalized ow as ISO/IEC 11578: 1996 Iformatio Techology Ope Systems Itercoectio Remote Procedure Call (see also UDDI operators assig uique keys for data structures A UUID geerator uses a complex algorithm, which takes ito accout factors, such as the curret date ad time, to produce a hexadecimal umber that has a statistical guaratee of uiqueess. The odds of producig a duplicate umber, i other words, are so great as to be impossible i practice. A example of a UUID is C90D731D-777D DE C2. Figure 5-2 illustrates the basic UDDI data model, i which data related to the busiessetity structure ca be retured as results to a query. Relatioships amog data structures are established via key refereces. Figure 5-2. The basic UDDI data model is a cotaimet hierarchy. Page 116

118 I Figure 5-2, the uderlied fields, such as busiesskey, are required elemets; that is, a request to store data will be rejected if these elemets are ot preset, although i some cases a required elemet ca cotai zero etries. The data model is a cotaimet hierarchy i which busiessetity is the root, or top-level, structure. The publisherassertio schema was added for UDDI v2 to allow multiple busiessetity etries to be placed i relatio with oe aother for example, to accommodate large compaies wishig to register their various divisios or subsidiaries. The UDDI data model has required elemets The arrows i Figure 5-2 illustrate the elemets that are used to establish the relatioships. The etry i busiessservices i the busiessetity schema is optioal; if preset, it cotais oe or more servicekey fields cotaiig key values that are preset i associated busiessservice etries. Relatioships are established amog the data structures Similarly, the bidigtemplate elemet i the structure busiessservice cotais bidigkey etries that referece ay associated bidigtemplate structures. The bidigtemplate i tur refereces the tmodel structure. Iformatio i the bidigtemplate ad the tmodel structures ca be combied to fid a complete Web service iterface. Geeric Data UDDI is desiged to accept virtually ay type of Web services descriptio, icludig idustryspecific descriptio laguages. WSDL provides a geeral-purpose laguage for describig the iterface, protocol bidigs, ad deploymet details ad as such is complemetary to UDDI but ot required by it (see Usig WSDL with UDDI later i this chapter). I other words, the data structures established by UDDI ot oly predate WSDL but also are desiged to be completely Page 117

119 extesible to cotai ad to referece ay type of cotract agreemet betwee two parties i a distributed or etworked exchage of iformatio. UDDI accepts virtually ay type of data Quality of UDDI Data Is a Questio Today, eve though UDDI is alive ad i productio, the quality of the data does ot fullfill the UDDI visio. Despite provisios for third parties to work with UDDI.org members to establish validatio services, the orgaizatio itself does ot provide more tha basic validatio of category iformatio. I other words, o mechaism has bee established to esure that the data goig i is sufficiet to create a truly successful Web services registry. The XML schema structures defied for UDDI do ot prescribe ay uderlyig storage format. That is, the way i which the data is set to a UDDI operator may be differet from the way i which it is stored. This does't matter as log as the XML structure ca be recreated from the persistet database storage format. (This is cosistet with the whole XML approach to data idepedece, which relies o mappig ito ad out of XML structures that are idepedet from the way i which data is represeted i the uderlyig programs ad databases.) The XML schemas do't prescribe ay uderlyig storage format As show i Figure 5-3, the UDDI data structures provide several types of iformatio, icludig cotact, idetificatio, ad category, to be stored i associatio with the mai busiessetity structure. Each of these is hadled via repeatig types of iformatio sequeces cotaied withi the busiessetity structure. The descriptive iformatio is basically the iformatio that ca be searched for a match ad for which service iformatio ca be retured via referece to the tmodel keys. Figure 5-3. UDDI maages several types of descriptive iformatio. Page 118

120 The Busiess Etity The top-level structure (busiessetity) is where most queries start. Depedig o the type of iformatio beig searched, however the queries will usually also iclude oe or more idetifiers or category keys. Queries may also start with other etities, however. Here is a example. The busiess etity structure is where queries ad registries usually start <elemet ame = "busiessetity"> <complextype> <sequece> <elemet ref = "discoveryurls" mioccurs = "0"/> <elemet ref = "ame" maxoccurs = "ubouded"/> <elemet ref = "descriptio" mioccurs = "0" maxoccurs = "ubouded"/> <elemet ref = "cotacts" mioccurs = "0"/> <elemet ref = "busiessservices" mioccurs = "0"/> <elemet ref = "idetifierbag" mioccurs = "0"/> <elemet ref = "categorybag" mioccurs = "0"/> </sequece> <attribute ref = "busiesskey" use = "required"/> <attribute ref = "operator"/> <attribute ref = "authorizedname"/> </complextype> </elemet> The precedig illustrates the XML defiitio for the top-level busiessetity structure. The schema defies a complex elemet sequece costraied by the use of attribute ames ad usage qualifiers for repetitio ad required characteristics. BusiessKey is required, ad UUID keys are assiged whe the structures are created. The miimum ecessary to create a busiesskey etity, therefore, is the busiess ame, ad queries typically start with that. Does UDDI Support Too May Optios? With so may optioal ad extesible fields, UDDI is very easy to use ad ca cotai virtually ay type of iformatio. But with all the flexibility ad extesibility, how ca a real patter of registratio ad searchig be established to support meaigful search ad discovery? For example, the oly required field whe registerig is a busiess ame. Searches o ames are difficult to get exactly correct because of spellig ad other attributes of ames, such as Ic. or PLC, that ca be icluded. So it's almost certai that someoe will have to review a list of ames maually to pick out the right oe. I additio, there's o required format for cotact iformatio or for idetifyig iformatio or category iformatio; i fact, there is't ay way to esure cosistecy or appropriateess of search iformatio. UDDI as a cocept holds great promise for Web services, ad the orgaizatio is hard at work addressig the various issues. The problem UDDI is tryig to solve is tremedous, ad oe of great potetial beefit. The Bidig Template The bidig template provides iformatio for physically accessig a Web service or other type of service registered with UDDI. A busiess may register multiple bidig templates for a give busiess service ad idetify differet access poits for that service, if appropriate or useful. Page 119

121 A bidig template cotais the service access poit, or URL type The access poit types i the bidigtemplate structure iclude the followig URL types: mailto: http: https: ftp: fax: phoe: other: The iformatio followig the type has to be formatted correctly for the type. For example, the mailto: type requires a valid address; the http: type, a valid URL format; ad phoe: a valid telephoe umber. I this way, a busiess ca provide the right access type for various cotact mechaisms for the same or differet services. No validatio is doe to esure that somethig exists at the other ed of the address; i most cases, however, this is o more of a cocer tha the geeral cocer over the validity of UDDI data. Iformatio has to be correctly formatted for each bidig type The tmodel I UDDI terms, a tmodel is the mechaism used to exchage metadata about a Web service, such as the Web service descriptio, or a poiter to a WSDL file. The UDDI defiitio of a Web service is much broader tha the examples show i this book. The UDDI registry aims to be geeral eough to support ay type of service accessible over the Iteret. So that's why UDDI does't use oly WSDL. If WSDL becomes popular ad widely accepted, perhaps most tmodels will use WSDL. For ow, however, other protocols ca be cosidered Web services by UDDI's defiitio, at least i terms of what's acceptable to put i a tmodel. A tmodel uiquely idetifies a Web service UDDI also predates WSDL. I this book, WSDL has bee used as a itegral part of a Web services defiitio, but UDDI defies a Web service a bit differetly ad more broadly. UDDI defies Web services as "techical services that are exposed for either private or geeral use. Examples iclude purchasig services, catalog services, search services, ad shippig or postal services exposed over trasports, such as HTTP or electroic mail." Busiess-to-busiess protocols, such as RosettaNet ad ebxml, ca be cosidered Web services by UDDI's defiitio, although either of them uses WSDL. UDDI v1 predates WSDL Page 120

122 A tmodel is roughly the UDDI equivalet of WSDL but is broader ad ca iclude poiters ad refereces to services usig addresses other tha URLs ad trasports other tha SOAP. Each tmodel is assiged a UUID key by a operator whe iitially stored. The descriptive iformatio stored i associatio with the mai tmodel structure is iteded to help esure that duplicate services ca be idetified. (Usig WSDL with UDDI is discussed later i this chapter.) WSDL is compatible with UDDI A tmodel is desiged to idetify uiquely iterface specificatios for Web services i the broad sese i which UDDI defies them ad to help allow them to be discoverable. A tmodel provides alterative etry poits ito the UDDI data structures i order to discover specific services ad to lik them to the busiesses that provide them. It's also likely that multiple busiesses will ed up exposig the same service. Oce firmly established, Web services are ot goig to be uique or customized to a particular busiess. A tmodel ca be shared by multiple busiesses The tmodels, represetig keyed metadata about a service, are iteded to esure compatibility of iterfaces or services across multiple registry etries. To be useful, a tmodel should cotai a poiter to a place where the user ca obtai more iformatio about the service. Aother iteded fuctio of tmodels is to support registry searches for a specific service. For example, suppose that your busiess wats to access a catalog service or a credit card validatio service. The UDDI APIs support searchig for specific service defiitios ad listig the compaies that offer compatible services. If you ca obtai a tmodel key value associated with the specific type of service you wat, you ca search UDDI for compaies that offer it. A tmodel is iteded to be a separate, idepedet etity refereceable by oe or more busiesses that offer a give Web service. I other words, the UDDI desigers assumed that a Web service might be a geeric or geeral-purpose service that more tha oe busiess or etity would provide. Therefore the tmodel is ot specific to a give busiess or etity ad is a searchable structure i its ow right, liked to oe or more busiesses or etities. The tmodel assumes that Web services are separately refereceable etities The reverse is also true; a busiess or a etity ca referece multiple tmodels. I the short term, it seems likely that most busiesses will expose uique Web services, but over time, it seems likely that some compaies will host services for other compaies, ad perhaps multiple compaies will get ivolved i the Web services hostig busiess. UDDI defies tmodels to look up its ow services, icludig tmodels that defie the iquiry ad publisher APIs for iteractig with the registry ad taxoomy maiteace APIs. For example, tmodels are defied for NAICS, UNSPSC, ad ISO 3166 classificatio taxoomies. These examples illustrate the use of a tmodel as a abstract amespace defiitio. Page 121

123 UDDI SOAP APIs The UDDI APIs are divided ito those that register iformatio ad those that search the iformatio i the registry. The registratio APIs are used by publishers, that is, by busiesses ad/or busiess agets that sed requests to eter the iformatio ito UDDI. The search APIs are used by registry cosumers to fid busiess iformatio by category ad to retrieve detailed iformatio about oe or more idividual busiesses that meet the search criteria. UDDI APIs are separated ito publisher ad cosumer APIs I geeral, APIs for registerig iformatio iclude savig ad updatig curret iformatio ad deletig old iformatio. APIs for searchig iformatio iclude returig summary iformatio about a group of etries or returig complete iformatio for a specific sigle etry. Ayoe wishig to use ay of the publisher APIs must first apply for a autheticatio toke from a operator. Each operator distributes autheticatio tokes usig its ow mechaism; so i practice, a publisher iteracts with oly oe operator. A publisher therefore sigs up with a idividual operator ad is grated credetials for loggig o ad usig the publisher APIs. The publisher APIs are required to be used over HTTPS (SSL v3.0) for ecryptio o the wire. Publishers must be authorized by operators Versioig is accomplished via amespaces. For example, the followig is a attribute o the v2 APIs to idicate that the v2 APIs are beig used: xmls="ur:uddi-org:api_v2" Namespace revisios idicate UDDI API versios Publisher ad cosumer SOAP APIs are available via HTTP POST oly. APIs support Uicode, which requires the use of UTF-8 ecodig. Publishers ca register busiess ad other descriptios usig multiple huma laguages. UDDI accepts HTTP POST operatios oly Iquiry APIs Usig oe or more search criteria, the iquiry APIs browse registry iformatio ad obtai specific iformatio about a registered busiess or service specificatio oce the proper uique key is obtaied. Iquiry APIs support browsig ad drillig dow o specific etries Page 122

124 Various search criteria are used to fid oe or more matchig records. Typically, a search starts with a geeric request that returs a list of busiesses that match a give category or idetificatio strig. The other iquiry APIs are used to retur service ad/or cotact iformatio for a give specific busiess. Iquiries ca be doe usig matches o busiess ames or idetifiers or usig category iformatio, such as idustry type or geographic locatio. Iquiry APIs support varied criteria Iquiry APIs are as follows: fid_bidig, locates specific bidig iformatio ad returs a bidigdetail message that icludes the access poit, by URL type, for the service fid_busiess, the mai API for the iitial search, fids iformatio about oe or more busiesses ad returs a busiess list message fid_relatedbusiesses, fids busiesses related to the busiess key ad returs a busiess list message; checks for subsidiary or other departmets for a give busiess fid_service, fids ad returs specific services listed for a specific busiess fid_tmodel, fids ad returs tmodel structures, providig a way to search the registry for matchig services get_bidigdetail, fids ad returs bidigtemplate iformatio sufficiet for ivokig a service hosted by a specific busiess; returs a bidigdetail message get_busiessdetail, gets full detail o a specific registered busiess ad returs a busiessdetail message, usually a secod iquiry oce a list of matchig busiesses is retured by a previous iquiry get_busiessdetailext, fids ad returs a exteded busiessdetailext message; that is the same as get_busiessdetail but with exteded iformatio defied for after v1 get_servicedetail, fids ad returs all iformatio about a give set of registered busiess service iformatio; returs a servicedetail message get_tmodeldetail, gets full details for a set of registered tmodel data; returs a tmodeldetail message Iquiry APIs retur o values if there's o match for oe of the search keys. The APIs iclude a optio to set a maximum umber of rows to be retured ad a flag to idicate that more rows exist tha ca be retured. Wildcard searchig is available o the fid_busiess API ame parameter. Iquiry operatios retur blak messages if there's o match for ay search value The fid_busiess API, the mai search API, ca search via ame, idetifiers, categories, or tmodel refereces ad ca also search for URLs. Up to five ame values are supported for a search. Usually, the first search returs a list of matches to oe or more of the criteria. Page 123

125 The fid_service API ca be used to fid specific services that meet specific criteria. You ca browse by ame o a service, get the UUID for the service, ad pass it back i to the fid_service API to get the specific service etry. Fid specific service iformatio The bidig-detail API gets the iformatio you eed to call a service. The iformatio ca be cached ad refreshed as eeded. Extesio (Ext) APIs are available for compatibility whe thigs are added. For example, get_busiessdetailext returs the same iformatio as get_busiessdetail, plus more ifo: extesios to UDDI for v2, i other words. Obtai the bidig detail to ivoke the service Sometimes, the results of oe query feed the iput for aother query. For example, get_busiessdetail might retur a tmodel key from the tmodelistaceifo associated with the busiess iformatio; the the ext call ca use the tmodel key to obtai a specific tmodel record. Fially, the tmodel ca be liked to oe or more busiess etity structures to obtai the iformatio ecessary to access the service. No autheticatio is required for iquiry APIs. No wire ecryptio is used. Iquiries do't eed security Publisher APIs Publisher APIs are used to store, to update, ad to delete or hide iformatio i the registry. Like all APIs that store data, the data beig stored ideally takes typical subsequet query operatios ito accout. I other words, appropriate data has to be stored to allow the iquiries to produce meaigful results. Publisher APIs store, update, ad delete registry iformatio Passig a blak UUID key idicates that the data is beig stored for the first time. New or differet iformatio with the same UUID replaces the old iformatio. Relatioship iformatio ca be chaged by makig chages to the keys that defie the relatioship iformatio. Whe busiessetities are registered, the operator site creates a URL that ca be used to get the elemet beig registered by usig a HTTP GET operatio. The publisher APIs allow ay umber of classificatio codes to be stored for a busiess. Classificatios iclude category codes for a busiess or geographical iformatio. Whe registerig iformatio, a busiess or a aget has the optio of askig for the categorizatio Page 124

126 iformatio to be checked or to remai uchecked, that is, for UDDI to accept ay categorizatio data the busiess or aget wats to store. Ay umber of classificatio codes ca be stored UDDI operators hope that third parties will develop ad provide checkig services. If the checked optio is used, oly the ame is stored uless the category iformatio checks out. Data ca be checked whe stored Followig are some publisher APIs: add_publisherassertios, adds relatioship assertios, or puts oe or more busiesses ito relatioship, such as departmets or subsidiaries delete_bidig, removes a bidigtemplate delete_busiess, deletes a registered busiessetity delete_publisherassertios, deletes relatioship iformatio delete_service, deletes a registered busiessservice delete_tmodel, hides a tmodel [1] [1] Because existig refereces might use them, tmodels are ot deleted. Hidde tmodels ca be reactivated by ivokig the saved tmodel with the origial data. discard_authtoke, iforms the operator with which the busiess or the aget is registered that the autheticatio toke is ot valid aymore; that is, the busiess or the aget is discardig the toke or is ot goig to use it aymore get_assertiostatusreport, a report, primarily for operator use, to check ad to help validate registered relatioships get_authtoke, requests a autheticatio toke from a operator site; a prerequisite for usig other publisher APIs get_publisherassertios, lists active assertios for a give publisher to defie relatioship iformatio get_registeredifo, provides a summary of all iformatio registered o behalf of a specific user, is operator specific, ad based o autheticatio toke save_bidig, either stores a ew or updates a existig bidigtemplate save_busiess, either stores a ew or updates a existig busiessetity save_service, either stores a ew or updates a existig busiessservice save_tmodel, either stores a ew or updates a existig tmodel set_publisherassertios, save ew assertios or replace existig oes; all elemets are required Operators ca impose space limits to prevet busiesses from registerig too much iformatio. Such limits are part of the egotiatio with the operator you choose, but the spec calls for these limits for a ew user, per accout grated: Busiess etity per accout: 1 Busiess service defiitios: 4 Page 125

127 Bidig templates: 2 tmodels: 100 Publisher assertios or busiess relatioships: 10 Maximum message size: 2MB Operators are allowed to impose resource limits o publishers Each registered bidigtemplate must cotai a valid servicekey that correspods to a registered busiessservice cotrolled by the same accout, that is, the same autheticatio key. It's possible to chage a bidigtemplate relatioship, however If a busiessservice or a bidigtemplate is cotaied withi more tha oe busiessservice, the relatioships are determied by processig order: the fial operatio redefies the relatioships for the registered iformatio. Bidig iformatio ca be moved from oe relatioship to aother, although UDDI does ot provide ay validatio of the resultig chage. I other words, UDDI ca't validate or eforce the meaig or sigificace of chagig relatioships amog busiesses ad services. A service ca be liked to more tha oe busiess UDDI allows relatioships to be defied amog busiesses but has o way to recocile, or check, duplicate etries for the same busiess, as whe a subsidiary registers separately from the paret compay. The validate_values API is also part of the publisher APIs but is reserved for operator use. The operator uses the API to call out to a third party with which it has agreed o usig as a validatio service for additioal categorizatio taxoomies ad idetificatio schemes. This allows UDDI data categorizatio to be validated after a save or a update operatio o the UDDI odes whe further details are required. Subsidiaries ca be liked to paret compaies Usage Sceario Imagie that the Skateboots Compay wats to register its cotact iformatio, service descriptio, ad olie service access iformatio with UDDI. The followig steps are ecessary: 1. Choose a operator with which to work. Each operator has differet terms ad coditios for authorizig access to its replica of the registry ad may provide some value-added servic es o top of the basic UDDI services. Also, wheever you eed to update or to modify the data you've registered, you have to go back to the operator with which you etered the data. 2. Build or otherwise obtai a UDDI cliet, such as those provided by the operators. 3. Obtai a autheticatio toke from the operator. 4. Register iformatio about the busiess. Iclude as much iformatio as might be helpful to those searchig for matches. 5. Release the autheticatio toke. 6. Use the iquiry APIs to test the retrieval of the iformatio, icludig bidig template iformatio, to esure that someoe who obtais it ca use it successfully to iteract with your service. Page 126

128 7. Fill i the tmodel iformatio i case someoe wats to search for a give service ad fid your busiess as oe of the service providers. 8. Update the iformatio as ecessary to reflect chagig busiess cotact iformatio ad ew service details, obtaiig ad releasig a ew autheticatio toke from the operator each time. The examples i the followig sectios show how the Skateboots Compay would register its iformatio ad how a distributor iterested i carryig the Skateboots lie might fid iformatio about how to cotact the compay ad place a order, usig the Skateboots.com Web services. Skateboots gets clearace from oe of the operators Updatig the Registry After obtaiig a autheticatio toke from oe of the operators Microsoft, for example the Skateboots.com developers decide what iformatio to publish to the registry ad use oe of the UDDI tools provided by Microsoft. If ecessary, the developers ca also write a Java, C#, or VB.NET program to geerate the appropriate SOAP messages. Here is a example. Skateboots ca register ad be discovered POST /save_busiess HTTP/1.1 Host: Cotet-Type: text/xml; charset="utf-8" Cotet-Legth: SOAPActio: "save_busiess" <?xml versio="1.0" ecodig="utf-8"?> <Evelope xmls=" <Body> <save_busiess geeric="2.0" xmls="ur:uddi-org:api_v2"> <busiesskey=""> </busiesskey> <ame> Skateboots, Ic. </ame> <descriptio> You kow, like the oes i Batma ad Robi... </descriptio> <idetifierbag>... </idetifierbag>... </save_busiess> </Body> </Evelope> This example illustrates a SOAP message [2] requestig to register a UDDI busiess etity for Skateboots Compay. The key elemet is blak because the operator automatically geerates the UUID key for the data structure. Most fields are omitted for the sake of showig a simple example. [2] Note that the examples i this chapter use SOAP v1.1. Page 127

129 Skateboots ca always execute aother save_busiess operatio to add to the basic iformatio required to create a busiess etity. Most likely, Skateboots Compay will wat to iclude oe or more idetifiers ad category IDs ad lik its two Web services for PreSeaso ad I-seaso orders to tmodel iformatio. Retrievig Iformatio After Skateboots Compay has updated its UDDI etry with the relevat iformatio, compaies that wat to become Skateboots distributors ca look up cotact iformatio i the UDDI registry ad obtai the service descriptios ad the access poits for the two Web services that Skateboots.com publishes for olie order etry: preseaso bulk orders ad i-seaso restockig orders. Customers retrieve the iformatio POST /get_busiessdetail HTTP/1.1 Host: Cotet-Type: text/xml; charset="utf-8" Cotet-Legth: SOAPActio: "get_busiessdetail" <?xml versio="1.0" ecodig="utf-8"?> <Evelope xmls=" <Body> <get_busiessdetail geeric="2.0" xmls="ur:uddi-org:api_v2"> <busiesskey="c90d731d-777d de c2"> </busiesskey> </get_busiessdetail> </Body> </Evelope> This example illustrates a sample SOAP request to obtai busiess detail iformatio about the Skateboots Compay. Oce you kow the UUID, or key, for the specific busiess that's bee registered, you ca use it i the get_busiessdetail API to retur specific iformatio about that busiess. Normally, to refie the iitial search, you might sed a message to UDDI cotaiig the busiess ame or a partial ame with a wildcard to see whether you ca get ay matches. 9DE3-..."> <ame>preseaso Orders</ame> </serviceifo> <serviceifo <busiesslist geeric="2.0" operator="uddi.sourceoperator" trucated="false" xmls:="ur:uddi-org:api_v2"> <busiessifos> <busiessifo busiesskey="c90d731d-777d de c2"> <ame>skateboots Ic.</ame> <serviceifos> <serviceifo servicekey="d90d731d-777d de3-..."> servicekey="e90d731d-777d <ame>i-seaso Orders</ame> </serviceifo> Page 128

130 </serviceifos> </busiessifo> <busiessifo>... [more Skateboot maufacturers] </busiessifos> </busiesslist> The preceedig example illustrates a sample message that might be retured from ay of the UDDI operators o receipt of the fid_busiess request. The service iformatio the servicekey is the used to locate the bidig iformatio that is eeded to iteract with the preseaso ad i-seaso Web services. Aother approach would have bee to search for the tmodel defiitio of the service, usig idetifier or category search IDs. But i this case, the distributor kows that oly oe compay maufacturers the particular skateboots it wats to sell, so it's ulikely that a geeric service exists for orderig from the factory. Alteratively, search usig the tmodel Figure 5-4 illustrates sample iformatio stored i UDDI for the Skateboots Compay's Web services after it's doe registerig. A more complete etry would iclude idetifiers ad category taxoomy iformatio, which also cotai poiters to tmodel structures, providig a alterative traversal path for obtaiig service iformatio. Figure 5-4. This sample shows a partial UDDI etry for Skateboots.com. The sample i Figure 5-4 shows a straightforward traversal path, startig with a iquiry o the busiessetity for Skateboots ad from that etry is able to fid the cotact iformatio Page 129

131 stored withi the busiessetity structure ad locate the Web services iformatio via the bidig template. Usig WSDL with UDDI The UDDI data model defies a geeric structure for storig iformatio about a busiess ad the Web services it publishes. The UDDI data model is completely extesible, icludig several repeatig sequece structures of iformatio. Although it was desiged ad specified before WSDL, UDDI did aticipate the eed for somethig like WSDL to be icluded. However, UDDI is desiged ad iteded to work with ay service descriptio laguage. UDDI icludes data structures appropriate for storig protocol bidigs ad etwork services. WSDL is fairly straightforward to use with UDDI WSDL is represeted i UDDI usig a combiatio of busiessservice, bidigtemplate, ad tmodel iformatio. As with ay service registered i UDDI, geeric iformatio about the service is stored i the busiessservice data structure, ad iformatio specific to how ad where the service is accessed is stored i oe or more associated bidigtemplate structures. Each bidigtemplate structure icludes a elemet that cotais the etwork address of the service ad has associated with it oe or more tmodel structures that describe ad uiquely idetify the service. WSDL iformatio is divided betwee geeric service iformatio ad specific bidig iformatio The busiess service iformatio describes the Web services. A bidig template cotais techical iformatio about a service etry poit ad costructio specificatios. The tmodel cotais descriptios of the specificatios for services or taxoomies, which are the basis for a techical figerprit for the service specificatio. The access poit i the bidig template gives the ed-poit address of the Web service. It's possible to store WSDL iformatio i several ways i UDDI, give UDDI's flexibility ad extesibility. WSDL best-practice authors recommed splittig the reusable iformatio from the iformatio specific to a give service. Although WSDL is ot required for registry with UDDI, IBM's toolkit aticipates the usefuless of registerig WSDL i UDDI by dividig WSDL ito two mai parts for proper fit ito UDDI: service iterface ad service implemetatio. Figure 5-5 shows how the WSDL parts fit ito this split. The split is recommeded so that iformatio commo to a category of busiess, such as message formats ad data types, port types, ad protocol bidigs, are i the reusable portio, whereas the iformatio about a particular service ed poit; that is, the port defiitio, is icluded i the service implemetatio defiitio portio. Figure 5-5. The WSDL parts list ca be grouped accordig to recommeded UDDI split. Page 130

132 As described i Chapter 3, WSDL is composable of separate XML files, or elemets, that ca be icluded together to form a complete WSDL file. WSDL service iterface defiitios are registered as UDDI tmodels; the overviewdoc field i the tmodel poits to the correspodig WSDL documet. Usig UDDI, the Web service developer follows the URL stored i the overviewdoc elemet to obtai the WSDL documet. Split WSDL iformatio alog elemet boudaries for compatibility with UDDI Whe UDDI is used to store WSDL iformatio, or poiters to WSDL files, the tmodel should be referred to by covetio as type wsdlspec, meaig that the overviewdoc elemet is clearly idetified as poitig to a WSDL service iterface defiitio. For UDDI, WSDL cotets are split ito two major elemets the iterface file ad the implemetatio file to similarly split the abstract defiitio of a service from its physical implemetatio oto a give trasport. Abstract defiitios ca thus be mapped oto multiple trasports. UDDI for Private Use UDDI ca be used iside the firewall as a directory of iteral Web services, or iteral itegratio poits. Applicatios ca be wrapped usig XML itegratio techologies ad registered with the iteral UDDI, icludig extesios to the UDDI data model that make sese ad/or apply to iteral use scearios. Whe usig Web services techology for itegratig iteral applicatios, registerig the itegratio poits i a commo registry makes it easier for other departmets to come alog later ad discover applicatios ready to be itegrated with, just as it's doe o the Web. UDDI is also suitable for iside-the-firewall storage of metadata Page 131

133 Figure 5-6 shows the role of a iteral UDDI registry as a service metadata store i corporate itegratio projects. Because the UDDI data structure is extesible ad because virtually ay iformatio ca be stored for the idetity ad the category bags, it's easy for a busiess to adapt the registry for iteral use. Figure 5-6. UDDI ca be used for iteral itegratio architectures. A local, or private, UDDI ca be used to store metadata about the ed poits of a orgaizatio's applicatios that expose iterfaces to other applicatios for the purpose of itegratig them. For example, a bak may have customer data i the retail savigs accout applicatio, mortgage accout divisio, ad moey market or mutual fud divisio. A private UDDI ca register ad discover applicatio itegratio metadata A customer relatioship maagemet system used to cosolidate fees for a customer with several types of accouts would have to obtai iformatio from these three differet applicatios. If Web services or aother service-orieted mechaism is used to accomplish the itegratio of these applicatios, metadata about the iterfaces could be stored i the private UDDI registry. If, say, a marketig applicatio wated some or all of the same iformatio from the other applicatios, developers could search the private registry to fid metadata ad iterfaces about the existig, itegrated applicatios. UDDI therefore ca provide a service that is useful i the cotext of iteral itegratio architectures comprised of other services such as a itegratio hub, commuicatios maager, documet repository, data trasformatio, ad process flow. Page 132

134 UDDI Support for SOAP ad Uicode This sectio describes the specific requiremets for usig SOAP with UDDI, icludig how UDDI treats the SOAP Actio header, ad prohibits the use of SOAP headers ad the optioal SOAP ecodig. This sectio also describes the UDDI requiremets for Uicode support. SOAP UDDI v1 required a empty strig value for the SOAP Actio HTTP header field. However v2 allows the field to iclude the ame of the UDDI API refereced withi the SOAP message. For example: SOAPActio: "save_busiess" UDDI v2 permits the SOAP Actio HTTP header UDDI does ot support SOAP headers. However, UDDI implemetatios are allowed to igore ay headers i the SOAP message as log as they do ot iclude the mustuderstad attribute, which, of course, requires a SOAP processor to uderstad the header withi which the attribute is specified. If a UDDI operator receives a SOAP message that icludes a required header, the operator will reject the message ad retur a SOAP mustuderstad fault. Cosequetly, the actor attribute of a SOAP header is ot supported, either. No SOAP headers or actor attribute UDDI does ot support the optioal SOAP ecodig. Ay SOAP message that does cotai the SOAP ecodig amespace attribute will fail ad retur a SOAP fault, a UDDI error code of E_usupported, ad a SOAP errifo text that describes the error. No SOAP ecodig SOAP request ad respose documets set to ad received from UDDI operators use the default SOAP amespace without a XML prefix. For example: xmls=" Default amespace required Uicode UDDI operators decided to use UTF-8 ecodig for all requests ad require that all operator sites support all the characters defied for the Uicode stadard for multiple-laguage support. Messages ca therefore cotai descriptio text i multiple laguages for busiess iformatio that eeds to be registered i more tha oe huma laguage. Uicode is required for all requests Summary UDDI provides a flexible, powerful, ad extesible mechaism for registerig ad discoverig busiess iformatio over the Iteret. UDDI also has may advatages for use iside the firewall. The public UDDI registry is hosted by private compaies, ad the specificatios will be cotrolled Page 133

135 by those compaies withi the UDDI.org cosortium util they are tured over to a idepedet stadards body for maiteace. UDDI represets its structured data by usig XML schemas ad supports SOAP APIs for storig ad retrievig iformatio. UDDI operators host both a test ad a public registry. Iformatio i the UDDI repository is ot, ad may ever be, cosistet or comprehesive eough to solve the worldwide categorizatio problem. However, UDDI provides a strog, widely adopted ad used model ad set of services for Web services metadata maagemet. Page 134

136 Chapter 6. A Alterative Approach: ebxml A iteratioal group joitly sposored by the Uited Natios Cetre for Trade Facilitatio ad Electroic Busiess (UN/CEFACT) [1] ad the Orgaizatio for the Advacemet of Structured Iformatio Stadards (OASIS) [2] drove the iitial electroic busiess XML (ebxml) activity. The ebxml group's charter was to research, develop, ad promote global stadards based o XML to exchage busiess data electroically ad by doig so to improve the efficiecy ad lower the cost of doig busiess worldwide. [1] See UN/CEFACT also sposors the EDI stadardizatio work. [2] See -ope.org. The ebxml iitiative paralleled the developmet of the core Web services techologies ad pursued the same goals. Hudreds of compaies, idustry orgaizatios, vedors of software ad services, ad stadards bodies participated i the ope process that created the ebxml specificatios. Ayoe with a computer, a Iteret coectio, ad a address could take part, ad ofte did, although primarily Electroic Data Iterchage (EDI) champios ad large compaies with sufficiet capital to ivest i specificatio draftig guided the effort. The iitial eightee-moth effort bega i November 1999 ad eded i May 2001 with the publicatio of the phase 1 specificatios. If implemeted as specified, ebxml provides the ability for tradig parters to exchage stadard electroic busiess messages, such as orders, delivery schedules, receipts, ad ivoices. These messages might iclude etire XML documets or oly the data that has chaged or is required to fill i the documet, assumig that both parters have a curret copy. The goal is to allow large ad small busiesses to cocetrate o productio ad marketig ad to devote less time ad effort i admiistratio, particularly of coected IT systems. The assumptio is that busiesses will be able to directly coect or at least map to their IT systems over the Iteret. Of course, this same assumptio also lies behid the SOAP, WSDL, ad UDDI iitiatives; ebxml differs maily i the degree to which it recogizes busiess process modelig as a core feature ad icludes idustrial-stregth quality of services. ebxml assumes that busiesses ca coect their IT systems over the Iteret Late i the iitial draftig cycle, the ebxml messagig team voted to adopt SOAP with Attachmets, sigalig covergece betwee ebxml ad SOAP, WSDL, ad UDDI. I cotrast to those three specificatios, the ebxml specificatios reflect requiremets from the busiess commuity for a more robust, secure commuicatio eviromet ad iclude a busiess process modelig methodology ad schema. I phase 2, OASIS assumed resposibility for maitaiig ad ehacig the ifrastructure specificatios, icludig the work of makig the ebxml registry compatible with Web services metadata. UN/CEFACT cotiued with the developmet of metadata ad iformatio models, icludig the busiess process iformatio model (BPIM), the core compoets (CC), ad busiess iformatio object (BIO) libraries. Page 135

137 Ogoig work is divided betwee OASIS ad UN/CEFACT Uder UN/CEFACT, the ogoig ebxml effort comprises te ew projects defiig BPIM metadata to esure cosistet busiess models, usig the Uified Modelig Laguage (UML) ad the Uified Modelig Methodology (UMM). This goal is drive by the eed to defie reusable processes ad iformatio blocks. It should also be oted that UN/CEFACT's BPIMs are techology eutral; that is, they ca be used for ebxml, EDI, ad ay other packagig ad trasport sytax. As to the work o CC, it is a bridgig tool for the migratio of data-cetric, bottom-up, EDI to the process-cetric, top-dow, BPIM world, but is ot a madatory compoet. Overview of ebxml Fudametally, SOAP, WSDL, ad UDDI grew out of a iterest amog Iteret commuity members i establishig a remote procedure call (RPC) mechaism for exchagig XML documets across the Web. By cotrast, ebxml grew out of a iterest amog existig EDI commuity members to create a better way to exchage busiess documets usig XML ad to trasport them over the Iteret, rather tha usig expesive, private value-added etworks (VANs). Later, after a documet-orieted iteractio style was added to SOAP, the two efforts bega to coverge, ad ebxml adopted SOAP as its default messagig trasport. ebxml defies the busiess process iteractio The goal of ebxml, like that of EDI, is to elimiate the expesive process of sedig paper documets through the mail or via fax ad to elimiate duplicate data etry tasks i the busiess applicatios of tradig parters by directly coectig their IT systems. I other words, the goal is to elimiate duplicatio whe iformatio is etered oce by the tradig parter that creates the documet ad agai by the tradig parter that receives the documet ad to achieve efficiecies ad cost reductios by miimizig huma steps withi the processes. The idea is to ecode busiess data i XML documets that ca be mapped directly ad automatically to existig busiess systems. ebxml's goal is to streamlie electroic commerce The itetio of ebxml, furthermore, is to improve o the EDI model by elimiatig the paiful prior agreemet aspect, which requires itese legal activity to create a tradig parter agreemet (TPA) betwee parties wishig to exchage documets via EDI. Furthermore, ebxml seeks to elimiate the difficult EDI setup period that requires ecodig the TPA ito the applicatios o both sides. I additio, the ebxml alterative is iteded to be available at lower cost ad to be easier to use tha EDI. For early twety years, the EDI stadard has bee used by a relatively small umber of large busiesses that could afford the start-up cost ad deal with its complexity. EDI was developed by poolig may related data item defiitios, thereby creatig a superset of all possible data items for such documets as purchase orders, shippig bills, ivoices, ad so o. This iformatio set proved uwieldy. Also, EDI required private etworks; expesive, specialized software; ad high-priced cosultats. Page 136

138 ebxml is iteded to be cheaper tha EDI I deliberate cotrast to the EDI approach, ebxml focuses o defiig the processes ad procedures by which busiesses might agree to exchage documets ad the messagig iteractios required to implemet those processes ad procedures. [3] Istead of idetifyig the various data items ad may optioal items i a busiess documet, the ebxml user starts by idetifyig the busiess process, or iteractio, betwee two or more parties that exchage busiess documets. [3] A earlier stadard for itrabusiess documet flows, RosettaNet, had adopted a similar model but was focused o the electroics idustry. By cotrast, ebxml seeks to accomplish the same thig for geeral busiess. RosettaNet cofirmed ebxml's accomplishmet by aoucig that it would alig with ebxml. A Simple Example Each busiess that participates i a exchage of documets that is ebxml-compliat idetifies the actios that it must perform to sed ad to receive a give documet. The iformatio eeded for such a documet is the derived from the patter of exchage. From the busiess process, therefore, ebxml derives the busiess data ecessary to carry out the agreed-o iteractio. Begi by idetifyig the busiess iteractio For example, a busiess process betwee two compaies might be defied as follows: 1. Based o its expected volume for its ormal witer seaso, Harry's Sports seds a advace order to Skateboots Compay. 2. Skateboots Compay seds a ackowledgmet of the order to Harry's Sports ad provides a expected shipmet date. 3. Harry's Sports may sed a iquiry about the status of the order at ay time ad receive a update, such as a message sayig that the shipmet will be a week later tha expected. 4. Skateboots ships the order ad seds a message cofirmig the shipmet to Harry's. 5. Harry's receives the order ad seds Skateboots a ackowledgmet that the order arrived. 6. Skateboots seds a ivoice to Harry's for the order. 7. Harry's seds paymet for the ivoice. 8. O receipt of paymet, Skateboots seds a ackowledgmet, edig the trasactio. Some aspects of this iteractio may be defied as optioal, such as sedig ackowledgmets o receipt of the order, the ivoice, ad the paymet. Other aspects may ot be defied as optioal, such as sedig the order ad the ivoice. A busiess trasactio, such as this purchase order, fudametally ivolves a exchage of thigs betwee busiesses, such as goods for moey. The ebxml busiess process ad tradig-parter iformatio allow optios ad requiremets i such a exchage to be explicitly defied ad agreed o betwee two or more parties to a busiess trasactio ad implemeted electroically over the Iteret. I this case, Skateboots would have stored i the ebxml registry iformatio about the busiess trasactios it offers over the Iteret, such as this log-ruig preseaso order. Harry's Sports Page 137

139 would have discovered the iformatio from browsig the ebxml registry ad cotactig Skateboots to formalize the agreemet. The goals for the ebxml registry iclude the automatic discovery of the tradig parter, usig search criteria specified i the collaboratio parter profile (CPP). Use the registry to store ad to retrieve busiess process iformatio Defie the Documets Accordig to the iteractio defiitio, the trasactio depeds o certai documets, icludig the purchase order ad the ivoice. With ebxml, the data ad the documets are ot defied; rather the iteractios betwee the two busiesses are formalized ito a agreemet that ca be executed. The agreemet assumes that the exchage of iformatio will be carried out accordig to the predefied busiess process iteractio. The ebxml BPIM idetifies the iteractios amog tradig parters participatig i a trasactio. Each activity withi a trasactio is associated with a exchage of iformatio, whether request or respose. Iformatio is at the root of ay exchage activity, trasactio, ad busiess process. Although the various parties to a iteractio may have differet iformatio requiremets, ebxml does ot wat to stadardize the iformatio exchage; EDI showed that this approach is either reasoable or successful. A busiess process may have a umber of activities defied to achieve the same ed result, but each of those activities typically has differet costraits ad differet iformatio requiremets that dictate a differet path through the BPIM. I other words, the ebxml BPIM allows ad eve assumes that multiple paths will be specified to achieve the same busiess iteractio, depedig o the tradig parter or tradig parters ivolved. Each valid path represets a separate sceario for that busiess process. I the CPP, a ebxml party idetifies which of those scearios it is capable of executig. For the collaboratio parter agreemet (CPA) to be completed, both parties agreeig to a sceario require at least oe iteractio patter match. A busiess process may support multiple activities Oce the iteractio patter is formalized ad agreed o by the participatig busiesses, documets either ca be chose from oe of the busiesses or from oe of the various stadards bodies dealig with XML documets or ca be based o oe or more of the models stored i the registry. A ebxml assumptio is that documets will be defied i a commo, shareable way as compaies implemet ebxml ad store their models ad profiles i the repository. As show i Figure 6-1, ebxml iteractio patters cotrast with those proposed by SOAP, WSDL, ad UDDI i that ebxml assumes a egotiatio phase betwee two or more busiesses that use ebxml-compliat software. Similar to the SOAP/WSDL/UDDI approach, ebxml assumes that a automatic discovery ad egotiatio phase will evetually become part of establishig a coectio betwee tradig parters. The automatic discovery ad egotiatio phase would be accomplished usig ebxml-compliat software that searched the registry for compatible busiess process metadata ad quality-of-service requiremets o behalf of a tradig parter. O fidig such compatibility, the software would cotact the tradig parter's ebxmlcompliat software to accept the process ad iitiate the iteractio. Page 138

140 Figure 6-1. A ebxml iteractio starts with a agreemet o the busiess process. A egotiatio phase is required to agree o a shared busiess process The ebxml registry is desiged to support browsig ad ad hoc queries. Oce the busiess searchig the registry Harry's Sports, i this case fids the supplier it is lookig for ad idetifies a target busiess process iteractio i this case, the preseaso purchase order process the cliet busiess ca either cotact the supplier to formalize agreemet o the busiess process to be implemeted betwee them or use automatic egotiatio via CPP, if supported. I either case, oce the process is agreed to, the fial step is for both tradig parters to set up their ebxml-compliat software to implemet the agreed-o iteractio i this case, submittig preseaso orders for skateboots. The ebxml registry supports ad hoc queries Legality of Electroic Documets The legality of electroic commerce trasactios is a thory questio. That is, does a electroic purchase order have the same legal stadig as a paper oe? This questio is outside the scope of ebxml, which does ot deal with the issue. However, for electroic commerce to become reality, this issue will have to be resolved. A electroic commerce trasactio will have to have legal status equivalet to a paper trasactio. This is already true for a automatic teller machie at a bak or a olie stock trade. But these trasactios use private etworks ad proprietary systems. Geeric purchase orders, ivoices, ad ebxml busiess processes do ot yet have this status whe trasmitted over the Iteret, uless, perhaps, whe they are prited out, but such importat questios as how to represet compay letterhead ad authorized sigatures legally remai uaswered. UN/CEFACT's legal workig group says that the CPP/CPA phase ca form a legal cotract ad has published a documet that descibes Page 139

141 the requiremets for a e-commerce agreemet that is fullfilled whe tradig parties perform a static CPP/CPA agreemet. This documet does ot have the legal stadig of UN member-coutry law but provides a good idicatio of a possible future resolutio of the issue. Some ebxml members also are proposig to establish the legality of the dyamic, or o-the-fly, trade-parter egotatio via itelliget software applicatios. But this is a much greater problem, perhaps usolvable i practice, as there is very little, if ay, precedet for software programs to be recogized as able to establish legal cotracts o their ow. The huge questio here, of course, is defedig or validatig what your software program has egotiated o your behalf. Deployig ebxml Iteractios, such as the fairly simple patter described earlier, ca be codified usig the ebxml CPA, which serves a similar purpose as WSDL. Assumig that ebxml-compliat software systems are available, the CPA drives the automatic iteractio betwee the IT systems of tradig parters that ca agree o a commo busiess process, give sufficiet iformatio i the registry. The CPA codifies agreed iteractios I our example, Harry's wats to fid a maufacturer of skateboots ad uses the ebxml registry to obtai iformatio ecessary to order from Skateboots Compay. Eve if Harry already kows that it wats to order from Skateboots Compay, Harry's ca use the ebxml registry to obtai iformatio about the services offered by Skateboots Compay for olie orderig. Harry's ca examie Skateboots's registered CPP ad associated busiess process models to see whether there's a potetial match with Skateboots's codified terms, coditios, ad iteractio scearios. The CPP is examied for a potetial iteractio patter match The ebxml model assumes that each busiess takig part i a Iteret trasactio will search the ebxml registry to fid a qualified tradig parter: oe that has registered a appropriate iteractio patter, such as the purchase order ad shipmet process for Skateboots Compay, ad that a perso or program at that busiess will explicitly decide whether the published iteractio fits. After agreeig o the iteractio patter, or busiess process, the ebxml-compliat software at each compay ca begi to execute the defied iteractio. As show i Figure 6-2, ebxml deploymet requires ebxml-compliat software to implemet the scearios, or patters, it describes ad to which each tradig parter agrees. The ebxmlcompliat software has to uderstad how to derive or map iterfaces to busiess applicatios, usig the CPP, which defies all potetial collaboratio mechaisms that a give busiess supports. The CPA defies a specific collaboratio o which the two or more tradig parters agree; i other words, a CPA represets the itersectio of two or more CPPs. Figure 6-2. The ebxml deploymet model requires ebxml-compliat software. Page 140

142 The modelig iformatio is recommeded but ot required to be defied usig the UMM, a subset or profile of the UML stadard from the Object Maagemet Group (OMG). The UMM or other modelig iformatio is mapped to a busiess process specificatio schema (BPSS) ad stored i the registry, where it ca be refereced from a CPP. Modelig is typically doe usig UMM The iformatio i a CPP, which is also iteded to be stored i the repository, idetifies which trasports are available for the iteractio, such as SMTP or HTTP, ad security requiremets, such as ecryptio, orepudiatio, ad digital sigatures. The CPP also idetifies the busiess processes available for egagemet: Is it just order placemet or a full supply-chai iteractio? Does a busiess process have various scearios? Page 141

143 SOAP versus ebxml Skateboots Compay ad Harry's Sports could certaily have chose to implemet the same busiess process sceario usig SOAP, WSDL, ad UDDI. The ebxml specificatios ad the SOAP/WSDL/UDDI specificatios sigificatly overlap. I fact, the ebxml messagig service is mapped to SOAP with Attachmets, ad UDDI ca be liked to the ebxml registry. UDDI may ot implemet all the features of the ebxml registry, but UDDI is flexible ad extesible eough to support search ad discovery of ebxml metadata. With the future directio ad stadardizatio of the UDDI ad ebxml registries still a ope questio, the covergece of these two idustry efforts would seem to be i everyoe's iterests. However, the sad truth is that primarily for political reasos, the two efforts maitai a coscious ad forced divergece. Su Microsystems supports ebxml while Microsoft does ot, for example. Some of Microsoft's proposals for extedig the core Web services specificatios overlap with fuctioality defied i ebxml, which Su prefers to referece. Therefore adherets of each ted to emphasize the differeces rather tha the similarities, which is too bad, as the similarities are more sigificat tha the differeces. Give the iheret extesibility of WSDL, it's also possible to iclude CPA ad CPP iformatio i WSDL ad to defie or to advertise a ebxml-compliat busiess service usig WSDL. Similarly, oe ca easily imagie a ebxml-compliat system that exposes Web services iterfaces, that is, usig WSDL istead of the collaboratio protocol i the CPA schema. The CPP allows a busiess to provide as may or as few details as it is willig to disclose publicly. Some busiesses may provide a lik to their complete product catalogs; other busiesses may provide simply a high-level descriptio of product categories or services. However, at least oe busiess process model sceario has to be idetified if a ebxml-compliat iteractio is to be supported. The CPA icludes the agreed-o trasport ad security optios, as well as the selected busiess sceario, via a bidig to a busiess process specificatio schema (BPSS). The target party ca either accept or reject a offered CPA. After the party accepts a CPA, the selected busiess sceario ca be iitiated by sedig the first busiess iformatio message i a payload over the agreed trasport. The the rest of the sceario is executed, ad the correspodig messages are exchaged. The CPA also icludes agreed-o security ad trasport optios After the busiess process modelig is doe, the models are mapped to XML that is, usig the BPSS format ad stored i oe or more registries. The busiess service iterfaces are registered, as are the CPPs, to describe the iterface implemetatios. Vedors ad busiesses providig ebxml-compliat software the use iformatio extracted from the registry to build the busiess service implemetatios that wrap existig or ew busiess applicatios. The CPA defies the specific payload cotets for each iteractio, which by default is delivered usig SOAP with Attachmets as the trasport, but other trasports are possible. Busiess process models are mapped to XML ad stored i the registry Page 142

144 The ebxml Specificatios Phase 1 ebxml work cosists of three major parts: Trasport, or messagig specificatio, based o SOAP with Attachmets Registry, usig either UDDI or ative ebxml stores busiess process model defiitios ad collaboratio protocol defiitios Collaboratio, meaig the automatic executio of models ad iteractios amog busiess parters Implemetatios are started with the trasport Vedors are typically implemetig ebxml i this order, although some are cocetratig first o modelig tools. Busiesses ca use ebxml to fid out about oe aother usig the registry, to defie TPAs, ad to exchage XML messages i support of busiess operatios. The goal is to evetually perform all these activities, without huma itervetio, over the Iteret. Work o ebxml is ot yet completed, however. Work o the specificatios ad compliat software cotiues at UN/CEFACT, OASIS, W3C, ad other cosortia, ad at various systems ad software compaies. Although phase 1 has bee completed ad implemetatios are o the market, the ebxml specificatios remai works i progress. ebxml specificatio work cotiues May similarities exist betwee ebxml ad SOAP/WSDL/UDDI, as both efforts sprag from very similar requiremets ad objectives. Because ebxml started from the busiess process model ad SOAP/WSDL/UDDI started from the RPC model, the overlap is ot complete. It's more like a itersectio; ebxml maps dow to implemetatios at the trasport level, ad SOAP/WSDL/UDDI map up to the documet-orieted iteractio style. Much commoality is also see betwee UDDI ad the ebxml registry. Coceptual overlap with Web services techologies The shaded area of Figure 6-3 illustrates the coceptual overlap betwee the ebxml specificatios ad the SOAP, WSDL, ad UDDI Web services specificatios. Both specify a type of service iterface that gets stored i a registry, ad both specify a trasport usig SOAP. Although WSDL is ot really equivalet to CPA, the ideas are very similar. Figure 6-3. ebxml overlaps with SOAP, WSDL, ad UDDI. Page 143

145 Although origially SOAP/WSDL/UDDI ad ebxml started out as separate, competig efforts, today the ebxml specificatios ca be see as a source of requiremets for the cotiuig W3C work o SOAP ad related specificatios. The ebxml specificatios defie features, fuctios, ad qualities of service beyod those i the basic Web services specificatios. Several vedors are supplyig ebxml-compliat products, but it's possible that the covergece will overtake the mometum of ebxml ad that all its features ad fuctioality will be icorporated ito Web services. The Java Commuity Process (JCP) iitiative called Java APIs for XML Registry (JAXR) [4] defies a Java API commo to both the ebxml repository ad UDDI, for example. [4] See ebxml ca be a source of requiremets for Web services Architectural Overview The ebxml specificatios, created separately by idividual authorig teams, were iteded to fit withi a comprehesive techical architecture, as described i the techical architecture specific atio. The ebxml techical architecture builds o the experiece of EDI but takes advatage of the flexibility of XML ad the ubiquity of the Iteret. The ebxml architecture maps a busiess process ad iformatio model to XML documets ad defies requiremets for the software that processes the documets ad exchages them amog tradig parters. ebxml is iteded to fit withi a comprehesive techical architecture Page 144

146 Adoptio of ebxml Because ebxml aliged with SOAP, it seems likely that the ebxml trasport will be adopted ad implemeted. However, the bigger questio ceters o busiess process, which is where ebxml started ad how ebxml is differet from EDI. Stadardizig busiess processes is at least as big a job as stadardizig busiess data. May attempts at the latter have bee made, ad may have failed. Busiess processes, like the busiesses that iveted them, are ofte uique ad sometimes are part of a compay's competitive advatage. It's ot clear that busiesses will agree to stadardize them or eve to disclose them i sufficiet detail for stadardizatio. Ad if this does't happe, ebxml may fall flat. The ebxml architecture defies the followig: Busiess processes ad their associated messages ad cotet A registry ad discovery mechaism for publishig busiess process sequeces ad related message exchages Compay profiles Tradig-parter agreemets A uiform message trasport layer Coformace to the ebxml architecture is defied for each idividual specificatio ad also, geerally, i the techical architecture specificatio. Coformace appears to require implemetatio of all the specificatios, although may of the features ad fuctios are listed as optioal withi the idividual specificatios. Coformace requiremets vary The mai ebxml specificatios [5] are as follows: [5] See Techical Architecture: a overview ad detailed summary of the complete architecture Busiess Process ad Iformatio Modelig: defiitio of the BPSS ad a modelig methodology for producig a BPSS Collaboratio Protocol Profile ad Agreemet Specificatio: defiitio of tradig parter iformatio ad how it's codified i XML documets Registry ad Repository Services: for storig ad retrievig busiess process models ad specificatios, tradig-parter idetity, ad techology requiremets Messagig Service: defiitio of how ebxml-compliat documets are trasported across a etwork Core Compoets ad Core Library: shared compoets across idustries, icludig a busiess documet overview ebxml cosists of six mai specificatios Page 145

147 Subsequet subsectios detail the busiess process, collaboratio protocol, registry, messagig, ad core compoets specificatios ad provide some examples ad illustratios of the major poits. Some people say that ebxml ca be implemeted i stages, but formal coformace is defied as comprisig all the architectural compoets of the ebxml ifrastructure. Sortig out which vedor cofirms to what specificatio ca be a complex task, however. Busiess Processes ad Iformatio Modelig The steps ecessary to execute a busiess trasactio with oe or more busiess parters defie a busiess process. A busiess process is first defied ad the executed. The executio of a process cosists of a series of messages exchaged amog oe or more parters. The messages usually iclude busiess documets, but they ofte are ackowledgmets or other iformatioal messages as well. Busiess process steps execute a busiess trasactio A busiess process is defied usig a combiatio of a tradig-parter profile, which lists the busiess trasactios supported by a particular party to the exchage, ad the tradig-parter agreemet, which idetifies the specific trasactio to be executed by the parties. The cetral idea of ebxml is that the parties to a busiess trasactio will first characterize the trasactios that they geerally offer ad the egotiate a agreemet with each other either maually or automatically, if automatic egotiatio is supported to execute oe or more of the geerally available trasactios. Parties first describe their trasactios ad the egotiate mutual agreemets Specificatio versus Implemetatio Oe of the thigs that distiguished the etworkig stadards battle betwee the Ope Systems Itercoectio (OSI) stadards of the Iteratioal Orgaizatio for Stadardizatio (ISO) ad the Trasmissio Cotrol Protocol (TCP) of the Iteret Egieerig Task Force (IETF) durig the 1990s was that the OSI specificatio was developed first, ad the vedors were expected to implemet it. IETF, o the other had, required referece implemetatios before a specificatio could be adopted. The IETF way of workig tured out to be much faster ad more effeciet ad helped result i the victory of TCP over OSI etworkig as the adopted stadard. Of course, there were other reasos havig to do with simplicity, ease of implemetatio ad adoptio, ad feature match with requiremets, but the parallels betwee ebxml ad SOAP are clear. Today, ebxml exists primarily as a collectio of specificatios, whereas SOAP, WSDL, ad UDDI are both prelimiary implemetatios ad specificatios. If ebxml succeeds, it will show that the busiess process iteractio is more importat to defie tha is the data or the documet. Usig the Iteret for busiess is goig to require the adoptio of stadards that make sese to busiesses ad that offer the level of features, fuctioality, ad qualities of service they have come to expect ad rely o i their Page 146

148 proprietary etworks ad LANs. If ebxml succeeds ad is widely adopted ad implemeted, ebxml will become such a stadard. Meawhile, however, SOAP, WSDL, UDDI, ad other Web services specificatios are evolvig toward what's defied by ebxml. Which oe will wi may deped o who gets there first; give the complexity ad ucertaities surroudig the critical ebxml registry specificatio, this may well be the tellig battle. The ebxml specificatio for busiess process ad iformatio modelig cotais a methodology for describig busiess process scearios ad a XML schema, BPSS, for ecodig those scearios. Each busiess process sceario defies tradig-parter roles, relatioships, ad resposibilities for a give busiess trasactio. The BPSS is capable of represetig a sceario for a multiple-party exchage, as well as for a simple exchage betwee two parties. To set up a busiess process sceario, a party creates a tradig-parter profile to list all the trasactios to be geerally offered ad the creates a CPP for storage i the ebxml registry. The busiess process models, also stored i the registry, use the BPSS ad are boud to the CPP whe it's created. Whe a ew tradig parter is elisted for a party, a CPA is created, theoretically as the matchig subset, or compatible itersectio, betwee the two parties' CPPs ad refereced BPSSs. Followig a exchage of CPPs ad the discovery of a mutually compatible subset of the CPP defiitios, the CPA is created ad proposed by the iitiatig party to the receivig party. The receivig party ca reject a uwated collaboratio. Parties list their trasactios i a CPP The BPSS icludes stadard busiess collaboratio patters that ca be used to determie the exchage of messages ad sigals betwee tradig parters. The BPSS also cotais cofiguratio iformatio for rutime system deploymet. The BPSS is available as a UML profile ad as a XML DTD or schema. Iformatio i the BPSS is the primary iput for the CPPs ad CPAs. Here is a example. The BPSS icludes stadard collaboratio patters <BusiessTrasactio ame="create Order"> <RequestigBusiessActivity ame="" isnorepudiatiorequired="true" timetoackowledgereceipt="p2d" timetoackowledgeacceptace="p3d"> <DocumetEvelope ispositiverespose="true" busiessdocumet="purchase Order"/> </RequestigBusiessActivity> <RespodigBusiessActivity ame="" isnorepudiatiorequired="true" timetoackowledgereceipt="p5d"> <DocumetEvelope ispositiverespose="true" busiessdocumet="po Ackowledgemet"/> </RespodigBusiessActivity> </BusiessTrasactio> Page 147

149 The example illustrates busiess process characteristics i a BPSS, such as orepudiatio that is, to esure that the documet is from whom it's supposed to be from ad a requiremet for a ackowledgmet of the message withi a certai time period. These characteristics are defied usig attributes of the RegistryBusiessActivity elemet. The BPSS also icludes the basic request ad respose messages that defie the busiess process sceario itself, that of sedig a purchase order ad receivig the ackowledgmet that the purchase order was received. The security ad timeout features are good examples of the type of busiess requiremet ebxml defiitios iclude beyod what's foud i the basic SOAP, WSDL, ad UDDI specificatios. The use of the UMM is specified for graphically depictig a busiess iteractio ad its associated flow of busiess data amog tradig parters. Busiess processes are the used to defie the message sequece depicted i the graphical model. A BPSS ca be geerated from its UMM depictio. Busiess processes ca be defied graphically Tradig-Parter Profiles ad Agreemets A importat feature of ebxml is the specificatio that defies a busiess's ability to coduct busiess with a tradig parter over the Iteret. A exchage of electroic iformatio betwee tradig parters requires each parter to have sufficiet detail of the other parter's eviromet ad the techology with which the other parter seds ad receives messages. Although ebxml is aimed, i geeral, at solvig this problem, specific defiitios of tradig-parter tools, techologies, ad trasport optios are required. As metioed earlier, the BPSS serves as a primary iput for the CPP ad the CPA. Icluded i the CPP ad the CPA are idustry iformatio; details of parter requiremets for trasport, messagig, ad security; ad bidig to a BPSS. Tradig parters that agree o the trasport, messagig, security, ad BPSS formalize the agreemet by geeratig a CPA ad the execute the CPA electroically to iitiate a trasactio. I short, these profile ad agreemet documets represet a methodology, or approach, to solve the problem of how to idetify busiess trasactios to be executed over the Iteret betwee two or more tradig parters easily ad perhaps automatically. BPSS serves as primary iput for the CPP ad the CPA A CPA ad the BPSS it refereces defie the ature of the coversatio betwee two or more tradig parters. The coversatio represets a sigle uit of busiess ad cosists of oe or more busiess trasactios. The BPSS defies the sequece of request ad respose messages comprisig a particular busiess trasactio. Coceptually, therefore, a busiess-to-busiess (B2B) server [6] at each parter's site implemets the CPA ad the BPSS. The B2B server must iclude the rutime software that supports commuicatio with the other parter's B2B server, executio of the fuctios specified i the CPA, iterfacig to each parter's back-ed systems, ad loggig the iteractios betwee the parters for audit ad recovery. [6] B2B servers ca be built i a variety of ways, such as o top of applicatio servers, usig ative Java code with servlets, or usig.net servers. B2B servers implemet the CPA The CPA is derived from the itersectio of two or more CPPs, mutually agreed o by tradig parters wishig to exchage busiess documets electroically usig ebxml. The defiitio of exactly how to create a CPA from mutually agreed o CPPs is left up to the implemeter, which meas that a variety of mechaisms will be provided. Both XML DTD ad schema cotet Page 148

150 models are available for the BPSS, CPA, ad CPP documets. CPPs ad CPAs are validated agaist the followig XML schema: The CPA is derived from two or more CPPs The model of ebxml states that a formal CPP descriptio is to be published ad the uiversally uderstood by iterested parties. Publishig a CPP is achieved by postig the documet to UDDI or to a ebxml global registry. A CPA cotais the messagig service iterface ad implemetatio details pertaiig to the mutually agreed-o busiess process scearios. Tradig parters may, but do't have to, register their CPAs i a ebxml registry. Oce a CPA has bee agreed o, however, electroic busiess iteractio may begi. Here is a example. <tp:partyifo> <tp:partyid tp:type="duns"> </tp:partyid> <tp:partyref xlik:href=" /> - <tp:collaboratiorole tp:id="n00"> <tp:processspecificatio tp:versio="1.0" tp:ame="buysell" xlik:type="simple" xlik:href=" /> <tp:role tp:ame="buyer" xlik:type="simple" xlik:href=" /> <tp:certificateref tp:certid="n03" /> - <tp:servicebidig tp:chaelid="n04" tp:packageid="n0402"> <tp:service tp:type="urireferece"> uri:example.com/services/buyerservice </tp:service> <tp:override tp:actio="ordercofirm" tp:chaelid="n08" tp:packageid="n0402" xlik:href=" xlik:type="simple" /> </tp:servicebidig> </tp:collaboratiorole> This example cotais a excerpt from a simple CPA published i the ebxml Collaboratio- Protocol Profile ad Agreemet Specificatio. The excerpt cotais tradig-parter, or party, idetity iformatio, icludig the DUNS ID umber for the parter, the lik iformatio for the XML documet to be exchaged, a role defiitio for the parter ("buyer," i this case), a service bidig, ad the defiitio of a order cofirmatio requiremet. Migratio of traditioal EDI-based applicatios ad other legacy applicatios to platforms based o the ebxml specificatios is facilitated. I particular, the CPP ad the CPA are aimed at the migratio of applicatios based o the ANSI X Tradig-Parter Profile used i EDI. Because they defie the techical requiremets for the electroic exchage of busiess documets CPAs are similar to the EDI tradig-parter agreemets, o which they are based. Ulike EDI TPAs, however, the CPAs are ot paper documets but XML documets, which themselves ca be electroically exchaged. ebxml supports migratio from traditioal EDI applicatios Madatory Compoets It's very strage that laguage i the ebxml specificatios describes the CPP ad CPA as optioal ad that a compay may or may ot support it. Eve though the success of ebxml most likely depeds o the widespread use of the registry, storig CPPs ad CPAs i the registry is itself optioal, as are the CPPs ad CPAs i the first place. Also, the messagig system is ot required to be SOAP or is ay particular middleware or Page 149

151 other software assumed to exist although somethig must be there to execute thigs. Furthermore, busiess process ad iformatio modelig is ot madatory. However, if implemetors ad users select the Busiess Processes ad Iformatio specificatio, they shall use the UN/CEFACT Modelig Methodology, which uses UMM. This meas that oe ca directly register XML, but it is't clear from the specs. It would seem especially importat to require the CPP ad the CPA, as the successful iteractio betwee tradig parters basically depeds o their existece or the existece of somethig like them. But if they are't there, what is to be used i their place is't clear: potetially, some form of private agreemet, or perhaps SOAP/WSDL. Registries ad Repositories The ebxml Registry ad Repository Service specificatio defies a set of services that store ad retrieve the busiess process, message, ad vocabulary defiitios used i the trasactios executed amog tradig parters. Compaies ca lik private ad public ebxml registries to store their busiess process models, BPSSs, CPPs, CPAs, ad related iformatio. Registry services store ad retrieve the process model, message, ad other trasactio defiitios The itet of the ebxml registry is to allow compaies to search for ad to discover other compaies with which they wish to eter ito olie tradig partership. The ebxml registry services are desiged to share service descriptios, discovery liks, ad catalogs of busiess collaboratio defiitios. If the goal of the Core Compoet specificatio is realized, reusable busiess documets also will be available through registry services. I cotrast to the UDDI registry, the ebxml registry is desiged to support ad hoc queries. UDDI ca, however, be used to implemet a ebxml registry, ad ebxml.org publishes a whitepaper describig how to do this. [7] UDDI ad ebxml registry services ca complemet each other. For example, it seems likely that busiesses will be able to discover services that are published i UDDI registries ad that lik to ebxml registries. [7] See The ebxml registry does ot assume ay rutime access by the applicatios that use it; all iformatio eeded for electroic busiess iteractio must be retrieved from the registry ahead of time ad cached. Oce autheticated, registry users are allowed access, usig a XML sigature, ad authorizatio for registry users is defied by a access cotrol policy with default roles for admi, user, ad ower. The registry does ot assume rutime access Oce a registry is set up, ebxml-compliat software ca access iformatio i the registry to fid tradig parters ad other parties with which to do busiess. This could take the form of a search for a particular product or service, such as a local flower shop, bolts for a airplae, or a geeric search for a busiess i a particular idustry, such as furiture maufacturig. Access to the ebxml registry ca be achieved via the ebxml messagig service, but this is optioal, ad access ca also be provided via ay umber of other trasports ad protocols. Figure 6-4 illustrates the ebxml registry ad repository architecture, i which ebxml messagig ad other messagig protocols access the mai registry by usig the service APIs. The mai registry maitais a access idex poitig to the repository or repositories i which cotet is stored. The service iterface also ca be used to map to UDDI whe UDDI is used as the repository. Registries ad repositories ca be remote, ad multiple repositories ca be liked Page 150

152 together. I the case of multiple repositories, the access idex i the primary repository the first oe iteracted with provides the locatio of the remote registry. Figure 6-4. The ebxml registry architecture separates the repository from the registry usig a access idex. Repositories store cotet; registries poit to repositories Registry services create, modify, ad delete registry items ad their metadata. The ebxml registry is desiged for tradig-parter commuities rather tha for use by the etire Web. The registry is desiged for tradig-parter commuities As with UDDI, each item stored i the ebxml registry must have a uique ID assiged to it, especially so that remote registries ca uambiguously locate the item. Registry items also must have a ame, a descriptio, admiistrative ad access status, persistece ad mutability characteristics, classificatio accordig to predefied schemes, file represetatio type, ad ame of the submittig ad resposible orgaizatio. Messagig The ebxml Messagig Service specificatio defies a secure, cosistet, ad reliable mechaism for exchagig messages amog users of ebxml-compliat software. Although ebxml messagig maps by default to SOAP with Attachmets, other trasports ca be used. SOAP with Attachmets defies a mechaism by which ay documet ca be attached to a SOAP message, Page 151

153 much as a Word or a PowerPoit documet ca be attached to a message. For ebxml, attachmets also are ofte large XML documets, egieerig drawigs, or illustratios related to a XML documet. ebxml messagig maps to SOAP with Attachmets Messagig i ebxml is desiged to trasport payloads of ay type over ay protocol, sequecig payloads i complex commuicatios ad supportig comprehesive security mechaisms, such as orepudiatio, while eforcig the rules of egagemet defied i the active CPA. The messagig specificatio is idepedet of either the payload or the commuicatio protocol used, although appedixes to the messagig specificatio describe mappigs to SOAP with Attachmets, HTTP, ad SMTP. Does Success Deped o the Registry? As the success of UDDI depeds o its use of meaigful categorizatio iformatio, the success of ebxml depeds o busiesses' registerig ad storig their busiess scearios i the repository. Istead of each idividual busiess modelig its view of how it thiks a particular busiess goal should be achieved, ebxml advocates that stadards orgaizatios, such as UN/CEFACT, ad idustry user groups will create the models. These models would cotai all possible activities that pertai to a particular busiess goal. This is a very importat poit, as it assumes that may of the models stored i the registry are commo to multiple busiesses. However, the ebxml registry, like UDDI, does ot costrai iformatio placed i it to esure uiformity. Both deped o the right thig happeig aturally or o someoe workig it out later, which is probably a lot to expect. The ebxml specificatios are supposed to provide oly the buildig blocks ad supportig ifrastructure for messages, but the developmet of stadard messages has bee left to idustry groups ad other stadards bodies, which may or may ot produce them. So, despite the geeral success of the ebxml iitiative i terms of creatig a comprehesive body of agreed-o specificatios, the reality of ebxml's adoptio is left largely to implemeters ad other stadards bodies, which may or may ot ed up completig the job. Meawhile, the W3C is advacig its family of Web services specificatios toward may, if ot all, of the same goals. The ebxml registry is eve more free-form tha UDDI. Work to fill i the gaps is ogoig, but so far, the success of the ebxml registry is far from esured. Without tighter defiitio of required cotet, reasoable ad successful searches ca't be performed. Ad without more cocrete API defiitios, implemetatios will vary. Ulike UDDI, o orgaizatio to host a cetral or commo registry has bee established. It's a classic chicke-ad-egg problem which UDDI also faces, of course i which success depeds o widespread adoptio ad use. The registry has to be populated to be useful ad has to be proved useful to be populated. The ebxml messagig specificatio adds several requiremets for such qualities of service as security, guarateed delivery, ad orepudiatio. The messagig specificatio also defies how commuicatio betwee two ebxml-compliat parties ca cofigure a coectio usig a agreed-o CPA; that is, how parties to a busiess trasactio ca start exchagig messages, give a active CPA. The messagig specificatio icludes additioal quality-of-service requiremets Page 152

154 Figure 6-5 illustrates the ebxml messagig specificatio's mappig to SOAP through the SOAP with Attachmets specificatio. SOAP with Attachmets allows a documet defied i a CPA to be attached to a SOAP message, usig a lik to the documet cotaied withi the body of the SOAP message. The SOAP body cotais a message maifest that lists all MIME parts ad attachmets that comprise the etire message. The message recipiet ca examie the maifest to determie whether all parts of the message arrived successfully. If they did ot, the recipiet sigals a error coditio, usig a SOAP fault message or other applicatio-defied message. The busiess data is fully cotaied withi the attachmet. The ebxml message ad trace headers are mapped to SOAP headers. Figure 6-5. The ebxml messagig specificatio's use of SOAP. The SOAP body cotais a maifest Core Compoets The ebxml Core Compoet specificatio idetifies the data items that are most ofte used across idustries, assigig them eutral ames ad uique idetifiers. Core compoets are iteded to provide iteroperability amog idustries ad busiess fuctios, but they, i fact, represet the way to defie a library of XML busiess documet parts out of which specific busiess documets ca be assembled for idividual trasactios. Core compoets idetify commo data items Page 153

155 Core compoets ca relate data used i oe idustry to data used i aother idustry or from oe XML vocabulary to aother, such as previously defied EDI trasactios. Core compoets, however, are still a work i progress. The EDI stadards bodies are i the process of mappig their data dictioaries to the ebxml core compoets, for example. Core Compoets capture iformatio about a real-world busiess object ad its relatioship to other busiess objects ad cotai descriptios of how a object may be used i a particular ebxml sceario. Core compoets are stored i the ebxml registry ad are required to cotai a miimum set of iformatio so they ca be joied appropriately with other core compoets. A busiess documet used i a ebxml-compliat busiess trasactio might therefore cosist of oe or more shared XML core compoet elemets perhaps a commo ship-to address defiitio ad custom XML elemets. Core compoets are therefore similar to a shared code library from which a programmer imports certai shared, reusable routies to accomplish geeral fuctios. A busiess documet might iclude oe or more core compoets Summary The ebxml specificatios are the result of a iitial eightee-moth iitiative by a large commuity of compaies ad idividuals who are dedicated to defiig a mechaism for Iteret commerce based o XML. The specificatios iclude a overall techical architecture, messagig ad trasport, registry, ad busiess process modelig. The ebxml approach starts by defiig a busiess process, which is modeled as a series of iteractios amog iterested tradig parters. Whe multiple busiess process defiitios are available i the registry, they ca be compared for compatibility. A egotiatio phase that follows establishes agreemet amog tradig parters to start executig oe or more of the predefied processes. The ebxml architecture does ot defie the documets to be exchaged but istead relies o the idetificatio of the iteractio patters to drive iformatio requiremets. May vedors are implemetig ebxml, typically startig with the message trasport, which is based o SOAP with Attachmets. Web services ad ebxml techologies are covergig i the areas of trasport ad registry ad overlap coceptually i may areas. The ebxml specificatios ca be cosidered as a potetial source of ehacemets to Web services techologies that would make them usable for a broader rage of busiess-critical applicatios. Page 154

156 Chapter 7. Web Services Architecture: Additioal Techologies After the core stadards are i place for data defiitio, service descriptio, message trasport, ad service discovery, additioal techologies are eeded to complete a Web services architecture that supports a broad variety of applicatios. Although the core stadards are sufficiet for may purposes, complex ad critical busiess applicatios require additioal features ad fuctios. SOAP, WSDL, ad UDDI supply the basic ifrastructure, like the tracks of a railroad. But a railroad also requires a system of sigals, switches, ad statios i order to ru effectively; Web services eed security, process flow, trasactios, guarateed messagig, ad so o to represet a complete computig eviromet. Additioal techologies are eeded to complete the Web services architecture This chapter describes some of the major proposed Web services specificatios ad techologies aimed at completig a Web services architecture: Security, for Web services cofidetiality, itegrity, autheticatio, ad authorizatio Process flow, for orchestratig the flow of executio across a series of Web services Trasactios, for coordiatig the results of multiple Web services Messagig, for cofigurig message paths ad routig messages reliably across multip le etwork hops, icludig itermediaries Security, process flow, trasactios, ad reliable messagig are major areas of work Microsoft ad IBM cotiue to play a major role i Web services research, draftig ad publishig specificatios for additioal techologies, ad proposig ideas for a comprehesive Web services architecture. Although the two compaies agree o may of the proposals, they disagree i other cases. Oe of the most difficult aspects of evaluatig proposals for additioal techologies is ascertaiig the potetial adoptio levels for them. As with the core stadards, these additioal techologies ad the requisite referece architecture proposals eed idepedet supervisio ad cotrol to become widely accepted. Microsoft ad IBM ofte, but ot always, collaborate This chapter also describes two semial techologies that predate Web services ad that cotiue to serve as a source of ispiratio for Web services: RosettaNet, a trailblazer i Web services, especially busiess-critical aspects of XML processig over the Iteret, icludig cotet maagemet, process flow, security, ad guarateed messagig XML-RPC, aother trailblazer for Web services, especially i the areas of simple RPCstyle iteractio Page 155

157 RosettaNet ad XML-RPC ispired Web services The specificatios described i this chapter are based maily o extesios to SOAP ad WSDL. Beyod this, however, is the eed for a architecture that puts the additioal services ad techologies ito their proper cotext. If you add security ad trasactio support to SOAP ad WSDL, do you check the security iformatio before processig the trasactio? Do trasactio cotrol attributes belog i WSDL, or is it sufficiet to icorporate them i SOAP headers? Ca the security mechaism be used to secure the trasactio cotext? Ad how does process flow relate to secure, trasactioal operatios? Do process flows automatically iitiate trasactios? Furthermore, how ca ayoe reasoably decide which additioal techologies are eeded to complete the referece architecture, ad which oes are out of scope or uecessary? A Web services referece architecture is eeded Because Web services are based o XML, they are fudametally extesible to iclude other specificatios ad techologies. However, this flexibility itroduces the problem of esurig that the participats i a Web services iteractio are usig the same set of additioal, compatible techologies ad services. Figure 7-1 illustrates a potetial Web services architecture based o the cotaier cocept. The cotaier is a deploymet vehicle for Web services, which are described ad advertised usig WSDL. Withi the cotaier is a dispatcher to ivoke the Web service implemetatios i C#, Java, or other programmig laguage, together with cofiguratio parameters detailig cotaier optios, such as automatic hadlig of security, trasactios, threadig, messagig, multiprotocol mappig, ad metadata hadlig. Additioal Web services techologies that provide these features ad fuctios are available to the cotaier, perhaps as local program libraries or as remote Web services implemetatios. Admiistratio ad maagemet services are also available for cofigurig, moitorig, ad cotrollig the executio eviromet for deployed Web services. Figure 7-1. This sample Web services architecture is based o the cotaier cocept. Page 156

158 Figure 7-1 idetifies the kids of additioal features ad fuctioality that are eeded to complete the Web services computig platform. The figure does ot represet idustry agreemet o the overall model or o the specific set of features ad fuctioality show. It's oe way, however, to gather together i a sigle diagram a represetatio of the types of additioal techology proposals that are uder cosideratio ad that might ed up i a comprehesive Web services architecture. Microsoft, IBM, ad others have preseted similar architectural proposals at a W3C forum o Web services, ad the papers submitted to that forum provide a good source of ideas for completig the picture. [1] The W3C Web Services Architecture Workig Group is cosiderig these papers ad other proposals as it defies such a referece architecture. [1] W3C Workshop o Web Services. April 2001 see Security Security is oe of the most importat ad most complex issues cofrotig the Iteret ad Web services. Security is somethig you ca't have eough of, but you have to draw a lie somewhere, or you would ever get aythig doe. Security is fudametal Basic security issues iclude data cofidetiality ad itegrity to esure that o oe steals your credit card umber, for example, or tampers with the cotet of your message ad autheticatio/authorizatio, which deals with the rights of idividuals or groups to access a certai resource, such as a give Web service iterface. For cofidetiality ad itegrity, the startig poit is SSL/TLS, [2] which is implemeted as HTTP over SSL (HTTPS). For autheticatio/authorizatio, the startig poit is the simple checkig of userame/password, commo to may Web sites, ad proprietary mechaisms developed by such security vedors as Netegrity ad Etrust. Aother critical ad fudametal aspect of Iteret security is the use of firewalls, which have a bearig o Web services because they ca be cofigured to ispect messages. [2] The leadig ecryptio techology, kow as Secure Sockets Layer (SSL v2/v3) see is based o the Trasport Layer Security (TLS) v1 stadard from IETF (see Basic security protects data Stadardizatio: A Log, Slow Road The stadardizatio process for Web services has followed a strage route ad is ot guarateed to succeed with respect to the basic Web services techologies, let aloe the additioal techologies eeded for idustrial-stregth Web services deploymet. Part of the reaso is that the W3C acts deliberately ad carefully ad therfore slowly. But, i additio, the W3C has ot always succeeded i establishig its specificatios i the marketplace. I particular, the HTTP-NG (ext geeratio) specificatio, iteded to provide much the same fuctioality as SOAP, fell flat, i part because of vedor competitio. The origial SOAP specificatio was developed outside of the W3C by a group of cooperatig vedors that later joied with several others to submit the specificatio to W3C. Most of these other additioal techologies have followed a Page 157

159 similar route. The W3C the iitiated the XML Protocols Workig Group, which resulted i SOAP v1.2. However, it took the workig group a log time to develop the SOAP specificatio, ad little substative chage resulted from the W3C process. True adoptio of Web services, especially the additioal techologies ad referece architecture required to make it useful techology for busiess, must follow a eve more difficult ad challegig route, as the techologies at this level are ofte oes o which compaies compete more itesely with oe aother. XML-based security stadards are still evolvig, but cosesus seems to be covergig o a proposed stadard for autheticatio ad authorizatio (SAML) ad a proposed stadard for public key maagemet (XKMS). Also, of course, ad fudametal to all Iteret security, are the firewalls that protect private etworks. Firewalls map a publicly kow IP address to aother IP address o the iteral etwork, thus establishig a maaged tuel ad prevetig uwated access. Additioal security restricts access A password ca be ecoded by usig base64 for miimal protectio o the wire, eve without SSL/TLS, but this does ot provide ay ecryptio ad is therefore ot very secure. HTTPS ca be used to esure a additioal level of protectio. HTTPS tuels HTTP messages over a secure etwork coectio protected by usig the SSL/TLS protocol. Browsers typically otify users whe such a protected coectio is beig used. SSL/TLS, ad therefore HTTPS, is supported by most of the popular Web services eabled applicatio servers, such as BEA's WebLogic, IBM's Websphere, ad IONA's J2EE Editio. Cosistet Security? May XML security stadards are beig proposed ad are still evolvig for use with Web services. Security is a complex problem ecompassig data cofidetiality ad itegrity, autheticatio, ad authorizatio, ad puttig all the pieces i place takes time. Meawhile, basic ecryptio stadards are available to secure trasmissios o the wire usig public keys, S/MIME, ad HTTPS. Past this poit, some of the security proposals start to diverge: Microsoft, for example, may go its ow way with security, which could lead to difficulties realizig the ed-to-ed security visio for Web services whe.net platforms are icluded. Other vedors that focus o security exclusively, such as Netegrity ad Etrust, may ed up with implemetatios of basic autheticatio ad authorizatio services available over the Web ad offer alteratives to Microsoft's Passport such as Liberty. As with ay stadardizatio effort, however, thigs are maagable whe there is a small eough umber of them. For example, Society of Automotive Egieers (SAE) ad metric measurig systems; these two are alterative stadards for automobile parts toolig. The market is able to support both. With security, a sigle stadard would be most effective, but two may be maagable as log as coversio or mappig betwee them is possible. SOAP over HTTPS with basic HTTP autheticatio will be the most commo form of secure messagig for Web services. But this is't sufficiet because Web services are essetially exposig access to programs ad data stores. Furthermore, with complex Web services, coversatios may spa multiple services that have bee discovered dyamically or composed ito a larger iteractio, such as a process flow. Web services will eed a ed-to-ed security model for the etire coversatio because sesitive iformatio could be passed from service to Page 158

160 service. A Web service iteractio also might ivolve multiple parties usig differet securityrelated techologies. These requiremets ca be met with a combiatio of HTTP basic autheticatio ad HTTPS, but a Web service may have to autheticate the request over ad over agai whe multiple parties are ivolved. SAML provides a way for a Web service to reuse a assertio made by a trusted etity, although the user still has to satisfy each idividual Web service's protocol. For example, if a service requires S/MIME formattig, the requester must adhere to S/MIME, eve with a valid SAML assertio. HTTPS is ot sufficiet SAML Security Assertios Markup Laguage (SAML), a OASIS iitiative, provides a stadard way to profile iformatio i XML documets ad to defie user idetificatio ad authorizatio iformatio. SAML implemetatios provide a iteroperable XML-based security solutio, whereby user iformatio ad correspodig authorizatio iformatio ca be exchaged by collaboratig services. SAML defies stadard XML formats for autheticatio ad authorizatio iformatio that ca be propagated alog a call chai, usig ay trasport techology. SAML eables sigle sig-o ad ed-to-ed security for Web services. Users ca travel across sites with their etitlemets so that compaies ad parters i a trusted relatioship ca deliver sigle sigo across sites. Here is a example. SAML Request: <?xml versio="1.0" ecodig="utf-8"?> < Request xmls=" draft-sstc-sch ema-protocol-19.xsd" xmls:ds=" xmls:saml=" draft-sstc-schema-assertio-19.xsd" xmls:xsi=" xsi:schemalocatio=" docs/draft-sstc-schema-protocol-19.xsd d:/platform/draft-sstc-schema-protocol-19.xsd" RequestID="Strig" MajorVersio="0" MiorVersio="0" > < AutheticatioQuery> <saml:subject> < saml:nameidetifier Name="admi" SecurityDomai="UserID"/> < saml:nameidetifier Name="admi" SecurityDomai="Password"/> < /saml:subject> < /AutheticatioQuery> </Request < Respose xmls=" draft-sstc-schema-protocol-19.xsd" xmls:ds=" xmls:saml=" draft-sstc-schema-assertio-19.xsd" xmls:xsi=" xsi:schemalocatio=" docs/draft-sstc-schema-protocol-19.xsd d:/platform/draft-sstc-schema-protocol-19.xsd" ResposeID="Strig" MajorVersio="0" MiorVersio="0" StatusCode="Success" IResposeTo="requestId"> < /Respose> Page 159

161 The example illustrates the use of SAML request ad respose. This format ca be propagated usig SOAP headers to esure that autheticatio iformatio is available whe a message is propagated from oe poit to aother alog a Web services call chai, so that the appropriate authorizatio checks ca be made at each poit. The respose idicates a successful match for the userame ad password submitted i the request. SAML propagates autheticatio iformatio XKMS The XML Key Maagemet Specificatio (XKMS) defies a protocol for distributig ad registerig public keys used i ecryptig ad decryptig messages trasmitted usig SOAP ad other trasports. XKMS is desiged for use with the W3C XML Sigature specificatio (XML- SIG), developed joitly by W3C ad IETF. XKMS icludes two major parts: the XML Key Iformatio Service Specificatio (X-KISS) ad the XML Key Registratio Service Specificatio (X-KRSS). XKMS mechaisms maage public key ecryptio X-KISS defies a mechaism to resolve public key iformatio cotaied i XML-SIG elemets. X-KISS allows a cliet to delegate part or all of the tasks required to process key iformatio elemets to a uderlyig service implemetatio. Applicatios thereby ca be abstracted from the uderlyig Public Key Ifrastructure (PKI) implemetatio used to establish trust relatioships. The uderlyig PKI may be based o ay oe of a umber of specificatios, icludig PKI for X.509 certificates (PKIX), Simple Public Key Ifrastructure (SPKI), ad Pretty Good Privacy (PGP). X-KRSS defies a Web service that accepts registratio of public key iformatio. Oce registered, the public key may be used with other Web services, icludig X-KISS. X-KISS defies a wrapper aroud a uderlyig PKI service, whereas X-KRSS defies a Web service for registerig PKI iformatio. Both protocols are defied usig XML schemas, SOAP, ad WSDL. Expressio of XKMS i other compatible object ecodig schemes is also possible. Trust services wrapped by X-KISS ca maage private/public key pairs for digital sigatures. The etire process of registerig, fetchig, ad revokig keys ca be delegated to the trust service. XKMS specifies a XML protocol to access the key maagemet fuctios of a trust service. Trust service fuctios iclude all the features ecessary to sig ad seal documets digitally, so that oly the iteded recipiet ca view ad maipulate the cotet. X-KISS exteds basic applicatio server fuctioality Applicatio servers, such as BEA's WebLogic ad IONA's J2EE Editio, typically store keys but do ot provide maagemet fuctios, such as key reewal ad revocatio checkig. Services hosted o such a server fetch keys from a local key store ad use them to sig a documet, usig Page 160

162 the sytax specified by the XML Digital Sigature specificatio. [3] fuctioality to iclude key registratio, fetchig, ad revokig. X-KISS exteds the basic [3] See Digital sigature helps protect cofidetiality A digital sigature is produced by usig a documet hash fuctio ad the private key so that the receiver ca idepedetly compute the hash ad compare it to the value produced via decryptio usig the public key. It is also possible to iclude the credetials i messages usig sytax other tha XML, over protocols other tha SOAP, ad through a defiitio laguage other tha WSDL, although such expressio is outside the scope of the specificatios. WS-Licese ad WS-Security The Web services licese laguage (WS-Licese) ad the WS-Security specificatios [4] are Microsoft proposals that are desiged to work together. The WS-Licese specificatio defies formats ad ecodigs for security credetials used by WS-Security for preservig message cofidetiality ad itegrity. A licese is a special type of credetial that cotais a set of related assertios siged by a authority, such as a public or private key. Both X.509 certificates ad Kerberos tickets are cosidered valid liceses. [4] These specificatios, alog with WS-Ispectio, WS-Referral, ad WS-Routig, comprise Microsoft's Global XML Web Services Specificatios (GXA), released i November See for WS-Licese ad for WS-Security. The mai purposes of WS-Licese are to defie a set of commoly used licese types ad to specify how they ca be icluded withi the WS-Security <credetials> tag. WS-Security provides credetial exchage, message itegrity, ad message cofidetiality for SOAP messages usig the credetials defied by WS-Licese. WS-Security associates liceses with messages for cofidetiality. Itegrity is provided by usig XML Sigature ad liceses to esure that messages are ot tampered with. Cofidetiality is esured by combiig XML ecryptio with liceses. WS-Licese ad WS-Security are desiged to be used with SOAP, but their relatioship to other, similar security efforts, such as SAML, is ot defied. WS-Licese defies security toke formats for WS-Security Process Flow Busiesses that start to iteract with oe aother by usig such Web services techologies as SOAP, WSDL, ad UDDI will eed to establish formal processes ad procedures for hadlig access to iformatio techology systems, as they already do for iteral operatios. Oce the formal processes ad procedures are i place, they ca be defied as Web services, ad a choreography, or busiess process flow defiitio, ca be placed aroud them to put them i a agreed o sequece for automatic executio over the Web. Oce program-to-program commuicatio is established usig Web services, the ext step is to implemet formal tradig-parter agreemets ad collaboratios as process flows, or orchestratios. Two proposals for defiig this sequece of messages ito a busiess process framework are XLANG from Microsoft ad Web Services Flow Laguage (WSFL) from IBM. Page 161

163 Orchestratio places Web services ito relatioships As show i Figure 7-2, a process flow puts ito a defied sequece tasks that ivoke Web services, JavaBeas, CORBA objects,.net classes, ad ERP adapters, amog others. Most process flow implemetatios allow callouts to ay type of program for exteral access. May such implemetatios are focused etirely o orchestratig a series of Web service ivocatios. I ay case, a process flow defiitio itself ca be exposed as a Web services iterface such that sedig a message to that iterface iitiates the automated flow of executio. A typical applicatio for a process flow is to automate a busiess trasactio, such as fillig a purchase order or processig a isurace claim. Figure 7-2. Process flow defiitio etails a sequece of tasks. XLANG The XLANG specificatio defies a message-cetric flow laguage similar to RosettaNet as a extesio to WSDL. RosettaNet process flow defiitios origiated Web-orieted busiess process ad protocol specificatios. Similarly, XLANG defies i WSDL terms a sequece of messages to implemet a busiess process. XLANG defies XML elemets for brachig ad switchig, exceptio hadlig, ad groupig WSDL operatios. The XLANG schema is iteded to be processed or executed i cojuctio with the WSDL it refereces. I other words, XLANG assumes the existece of WSDL for defiig the operatios it puts i sequece. XLANG is based o BizTalk XLANG also defies a way to carry cotext iformatio i WSDL-defied messages such that iformatio about the curret istace of a busiess process is idetified ad messages ca be related back to the right istace of a suspeded or active process flow whe the messages arrive Page 162

164 at a give tradig parter. XLANG assumes statically cofigured coversatios. Here is a example. <?xml versio="1.0"?> <defiitios ame="stockquoteprovider" targetnamespace=" xmls:ts=" xmls:xlag=" xmls=" <porttype ame="requestreceiveporttype"> <operatio ame="asklasttradeprice"> <iput message="..."/> </operatio> </porttype> <porttype ame="resposesedporttype"> <operatio ame="sedlasttradeprice"> <output message="..."/> </operatio> </porttype> <bidig ame="requestreceiveportbidig" type="ts:requestreceiveporttype"> <! details omitted > </bidig> <bidig ame="resposesedportbidig" type="ts:resposesedporttype"> <! details omitted > </bidig> <service ame="stockquoteproviderservice"> <port ame="pgetrequest" bidig="ts:requestreceiveportbidig"> <soap:address locatio="mailto:[email protected]"/> </port> <port ame="psedrespose" bidig="ts:resposesedportbidig"> <soap:address locatio="mailto:[email protected]"/> </port> <xlag:behavior> <xlag:body> <xlag:sequece> <xlag:actio operatio="asklasttradeprice" port="pgetrequest" activatio="true"/> <xlag:actio operatio="sedlasttradeprice" port="psedrespose"/> </xlag:sequece> </xlag:body> </xlag:behavior> </service> </defiitios> As show i the example, XLANG adds elemets ito the WSDL file to put previously defied port operatios ito a sequece. This is a simple example of a stock trade service, extracted from the specificatio, i which the AskLastTradePrice operatio defied for the Page 163

165 pgetrequest port is defied as part of a sequece with the SedLastTradePrice operatio defied for the psedrespose port. I this example, the ports are implemeted usig . WSFL The Web Services Flow Laguage (WSFL) specificatio [5] is a IBM proposal that describes process flows i terms of two types of Web service compositios: [5] See Iterally focused, or Web service aggregatio flows, puttig multiple iteral Web services ito relatioship Exterally focused, or flows betwee Web services exchagig messages betwee tradig parters I the first case, WSFL defies how Web services ca be aggregated to implemet a larger fuctio, such as a iteral busiess process for preparig a purchase order. For this type of flow model, WSFL defies the cotrol ad data flow betwee the associated Web services almost as if they were subrouties called from the same mai program. This type of flow is also sometimes called a micro-process flow. I the secod case, WSFL describes how a purchase order might be set from oe compay's Web servic e to aother. For this type of flow model, o executio sequece of Web services is specified. Rather, the iteractio betwee Web services is idetified i the flow ad is modeled as a lik betwee ed poits, almost as if they were adapters i a EAI type of itegratio flow. This type of flow is also sometimes called a macro-process flow. WSFL is derived from IBM's MQ Series product lie WSFL supports recursive compositio of Web services, meaig that the flows ca referece aother flow or a specific ed poit. I cotrast to XLANG, the WSFL defies its flows i a separate XML documet rather tha as extesios to WSDL. WSFL is layered o top of WSDL, which WSFL uses to describe the ed poits for busiess operatios, the descriptio of service iterfaces, ad their protocol bidigs. Here is a example. <flowmodel ame="totalsupplyflow" serviceprovidertype="totalsupply"> <serviceprovider ame="mysupplier" type="supplier"> <locator type="static" service="qualitysupply.com"/> </serviceprovider> <serviceprovider ame="myshipper" type="shipper"> <locator type="static" service="worldshipper.com"/> </serviceprovider> <activity ame="processpo"> <performedby serviceprovider="mysupplier"/> <implemet> <export> <target porttype="totalsupplypt" operatio="sedprocorder"/> Page 164

166 </export> </implemet> </activity> <cotrollik target="acceptshipmetrequest"/> <datalik source="processpo" source="processpo" target="acceptshipmetrequest"> <map sourcemessage="ainvadsr" targetmessage="asr"/> </datalik> </flowmodel> XLANG versus WSFL IBM ad Microsoft maage to agree o may Web services specificatios but ot o the process flow laguage. This may stem from the differet basis for the proposals i their respective products, which are ot compatible. From a purely Web services viewpoit, however, XLANG seems more atural, as it bears a relatioship to RosettaNet, oe of the major iflueces o Web services specificatios, ad is simpler, easier to implemet, ad more aturally a extesio of WSDL. But perhaps the real solutio will have to come from a completely ew ad idepedet source. This WSFL example depeds o a associated WSDL file cotaiig the port type ad operatio defiitios referred to as supplier ad shipper. The totalsupplyflow model specifies collaboratio with two service providers offerig their joit customers a complete busiess process. Each service provider is represeted usig a separate <serviceprovider> elemet. Oe service provider is of type supplier ad is referred to as mysupplier. The other service provider is of type shipper ad is called myshipper. The busiess process represeted by the totalsupplyflow flow model cosists of three busiess tasks, called activities, that have to be performed i the specified order to complete the busiess process successfully. A purchase order has to be processed, a shipmet request must be accepted, ad moey has to be received. Trasactio Coordiatio Whe multiple Web services are put ito relatioship for example, i a log-ruig automated busiess process flow results of related operatios may eed to be coordiated to esure that the desired outcome was achieved. A classic example of this sort of problem is the travel reservatio, i which multiple related operatios are executed to complete a itierary: hotel, flight, ad retal car reservatios. If oe of these operatios fails, the others should ot be completed, as travel is ot practical without all the reservatios beig made. I established distributed computig techologies, such as CORBA, DCOM, ad EJB, trasactio coordiatio services provide a all-or-othig protocol called two-phase commit, i which all operatios o data either succeed or fail as a uit. [6] Software-based trasactio coordiatio esures accurate recordig for busiess operatios ivolvig multiple operatios o data, despite hardware or software failures. However, remote executio of the existig trasactio coordiatio protocol depeds o the existece of a coectio-orieted trasport, which is ot the case for Web services, at least ot util or uless a reliable, sessio-orieted trasport is defied ad used i place of HTTP. [6] For a good itroductio to trasactio processig cocepts, see Priciples of Trasactio Processig (Berstei ad Newcomer, 1997). Page 165

167 Trasactios esure coordiated results Various suggestios ad proposals have bee cosidered to address this key problem. Oe is to use a coectio-orieted messagig protocol, such as HTTPR or BEEP, whe trasactio coordiatio is required, ad the to use a form of traditioal two-phase commit, such as the Trasactio Iteret Protocol (TIP). [7] Aother is to defie a alterative to the traditioal twophase commit protocol for use over curret, discoected Web trasports. [7] See BTP The Busiess Trasactio Protocol (BTP) [8] specificatio defies a XML protocol for placig log-ruig busiess-to-busiess (B2B) ad other similar trasactios ito a choreographed sequece. BTP is based o a multilevel trasactio model that provides idepedece from coordiatig the uderlyig resource maagers. I other words, BTP is a alterative to traditioal two-phase commit. [8] See -ope.org/committees/busiess-trasactios/idex.shtml. BTP is desiged to reliably maage the results success or failure of complex B2B trasactios ad to propagate those results to all applicatios ivolved i maagig the uderlyig resources: database systems, files, queues, ad so o. Ulike traditioal trasactio maagemet systems, BTP does ot coordiate or drive actios i respose to the results ad does ot coordiate recovery after failure. I the BTP model, iterpretig the results, icludig recovery from failure, remais the resposibility of the participats. BTP does ot specify the busiess protocol goverig the busiess trasactio but simply provides facilities ad sematics for a reliable termiatio mechaism to achieve a shared agreemet o the outcome of a busiess trasactio. BTP provides a alterative to traditioal two-phase commit Aloe, BTP caot provide the attributes of a ACID trasactio: atomic ity, cosistecy, isolatio, durability. Systems usig this protocol must decide separately ad idividually how to maage their local resources accordig to the propagated results. For example, o termiatio owig to failure, systems might execute a appropriate compesatig actio. BTP messages ca be trasmitted usig ay B2B protocol, icludig SOAP ad ebxml. A header ca be added to the ebxml message evelope, or a SOAP header ca be defied to carry the required trasactio propagatio cotext iformatio. Examples of BTP system messages iclude starttrasactio or termiatetrasactio ad ca be set usig stadard ebxml or SOAP messages. A J2EE,.NET, OMG Object Trasactio Service (OTS), or ative platform trasactio coordiator ca participate i a log-ruig trasactio as log as a mappig is created betwee the BTP messages ad the uderlyig trasactio coordiator. Of course, the mappig could also be performed directly oto the resource maager. However, BTP also itroduces the otio of a compesatig trasactio that ca be used by each participatig resource maager to compesate for the chages doe durig the trasactios if the outcome is a rollback. Web Services Ca't Use Traditioal TP Techology BTP evolved because covetioal ACID trasactios are ot well suited to Web services ad other B2B protocols. B2B trasactios ted to be log ruig ad Page 166

168 asychroous ad to use XML protocols over HTTP or SMTP, which are ot coectio-orieted protocols. Traditioal two-phase commit protocols assume the use of coectio-orieted protocols, ad the loss of a coectio is defied as a rollback. Clearly, i the ofte discoected world of the Iteret, triggerig a rollback o the loss of a coectio is ot possible. If the Web forced a rollback every time a coectio were lost, work would rarely get committed. Ad if database locks were held ope while waitig for two-phase commit messages over the Iteret, blockig would be a serious problem. Despite may efforts to solve the problem, othig has stuck. Eve BTP, which has a desig ad architecture appropriate to the Web, may well ot succeed for lack of widespread support. Gaiig cosesus o TP techology is much more difficult tha you might thik. Exteded Trasactios Work at the Object Maagemet Group (OMG) ad i the Java Commuity Process defied a exteded trasactio model suitable for log-ruig trasactios ad iteded for use i trasactio protocols other tha the established two-phase commit protocol. A example i the OMG specificatio describes a ope ested trasactio model that allows resources to commit idepedetly, much as participats i a BTP trasactio are allowed to do. The OMG exteded trasactio model is based o a geeric coordiatio state machie, however, which is capable of drivig ay protocol, icludig BTP ad traditioal two-phase commit. A geeric coordiatio mechaism such as this holds potetial as a Web services trasactio cotrol mechaism, also. The OMG exteded trasactio model may apply to Web services iteractios Messagig May proposals for additioal Web services techologies ceter o the messagig model, especially because qualities of service ca be associated with the uderlyig trasport. I traditioal distributed computig eviromets, additioal techologies, such as security ad trasactios, are ofte directly related to the trasport layer. Because Web services messages are fudametally oe-way asychroous messages that are potetially trasmitted over multihop Iteret etworks, icludig itermediaries that ca ispect ad process SOAP headers, additioal techologies i this area focus o improvig reliability ad esurig that the multihop messages are routed correctly. Messagig proposals defie routig ad reliability Figure 7-3 illustrates a simple example of a SOAP message path that icludes a origiator of a message ad two itermediaries, which process part of the message headers eroute to the ultimate receiver of the message. This simple example shows that a SOAP message ca be routed via multiple etwork hops i order to reach its ultimate destiatio. There-fore a mechaism is eeded to clearly idetify the etire route, to esure successful trasmissio of the message alog the etire route, ad to report failure or fault iformatio reliably to the origial seder. Figure 7-3. This sample SOAP message path icludes itermediaries. Page 167

169 Routig Iformatio i the Messages or Exteral to Them? I geeral, iformatio about the destiatio of a message ad the path it follows betwee seder ad receiver, icludig ay itermediary hops, ca be cotaied withi the message or described i associated routig tables. Whe the iformatio is cotaied withi the message, the problem arises of chagig the cotets of the message wheever the routig path for the message chages. Whe the iformatio is maitaied withi a idepedet table, eviromet variable ames or i URIs that associate the iformatio with the message, the routig iformatio ca be chaged idepedetly of the message cotets. Established distributed computig eviromets, such as CORBA ad DCOM, support the exteral traslatio of destiatio ames to addresses ad model itermediaries as forwardig agets trasparet to the seder ad receiver. Proposals for addig capabilities to the Web services messagig layer ted to focus o icorporatig additioal iformatio ito the message itself ad tryig to model or defie the roles of all etwork hops i the message path. However, exteral defiitio provides the applicatio with a cosistet, uiform view of a seder/receiver role, as the existece of itermediaries is trasparet to the message. Oce the existece of itermediaries is exposed to the applicatio layer of the protocol or i this case, exposed to the message defiitio specificatios eed to defie the behavior i sufficiet detail to esure that all implemetatios are cosistet. This applies to both ormal ad error cases. Thus Web services messagig extesios cotiue to struggle with the cocrete defiitios of the roles of seder, receiver, ad itermediary. WS-Ispectio The Web services ispectio laguage (WS-Ispectio) is a IBM/Microsoft proposal that defies a way to represet ad to retrieve a list of Web services published at a particular address. [9] That is, WS-Ispectio is desiged to be used whe the seder already kows the receiver's address ad wats to discover what services the seder offers ad obtai the service descriptio formats. WS- Ispectio provides a more focused discovery ad dowload capability for Web services metadata tha do the UDDI ad ebxml registries, which require a certai amout of browsig i order to obtai the iformatio. Furthermore, WS-Ispectio operatios are focused o a sigle target server. [9] See or WS-Ispectio retrieves Web services descriptios from a kow address Page 168

170 WS-Referral WS-Referral provides a dyamic defiitio of the SOAP odes i a message path, icludig itermediaries. The WS-Referral specificatio works i cojuctio with the attributes of SOAP headers to esure that the requisite odes are cofigured alog the message path to perform the roles idetified for them. I other words, the SOAP attributes idetify which odes are resposible for processig which headers. The WS-Referral specificatio provides a way to defie those odes withi the message path ad to delegate part or all of the resposibility for processig a give SOAP message to oe or more of them. WS-Referral defies itermediate odes that SOAP messages require WS-Referral uses SOAP messages ad headers to exchage routig etries amog message path odes ad ca chage routes idepedetly of the HTTP or other uderlyig trasport routig tables. WS-Referral messages ca establish ad modify a routig path for a message. SOAP routers i such a cofiguratio ca be set up to provide specialized applicatio services, such as load balacig, mirrorig, cachig, ad autheticatio. WS-Routig WS-Routig defies a complete message path for routig SOAP messages across a multihop etwork eviromet. The message path is defied withi the SOAP evelope. WS-Routig supports message iteractio patters for oe-way, request/respose, ad peer-to-peer coversatios. Although it defies the roles of the origial seder, the itermediary, ad the ultimate receiver, the SOAP specificatio does ot provide ay meas to specify a ordered path or route from oe to aother of these types of SOAP odes. Multiple istaces of SOAP odes i each role are possible. WS-Routig defies message path hops Delegate or Obfuscate? The otio of delegatig SOAP message header processig to specific odes that are cofigured to provide specific qualities of service for a message is itriguig, but the idea also teds toward cofusio. The iterest of a applicatio or a user i the cotets of a message is quite distict from the iterest of the same applicatio or user i the qualities of service applied to the cotets of the message. Therefore it's importat to ask whether splittig a message for processig at multiple odes alog a message path is helpful or harmful to the keep-it-simple teat of origial Web services specificatios. WS-Routig defies a SOAP header that cotais elemets idetifyig The message origiator The ultimate receiver The ext hop o the path to which to forward the message A idetificatio of the reverse message path alog which the respose, if ay, ca be set Page 169

171 The forward ad reverse elemets are redefied at each hop, elimiatig the requiremet for ay ode to kow the complete message path, although it might be cotaied withi a WS-Referral elemet. At each hop, the path back to the seder is dyamically refreshed, so that a message ca always retrace its steps through ay umber of itermediaries back to the origial seder. BEEP The Blocks Extesible Exchage Protocol (BEEP) is a IETF proposal for a geeric coectioorieted asychroous Iteret protocol. BEEP permits simultaeous ad idepedet exchages of messages betwee peers that have established a coectio. The coectio is defied i terms of a chael, which is a bidig to a applicatio providig a service, such as trasport, security, trasactio maagemet, or data exchage. BEEP is comparable to a coversatioal style of commuicatio protocol, such as those provided by LU6.2 ad Tuxedo. BEEP supports both text ad biary messages ad ca be used to help address ad resolve applicatio-level issues resultig from the coectioless ature of HTTP. I other words, certai qualities of service i Web services ad B2B message exchages ca rely o the features of the BEEP commuicatios protocol istead of beig dealt with by the applicatio. For example, BEEP coectios could be used to help esure that all parties to a busiess trasactio reliably receive otificatio of the trasactio outcome; with HTTP, by cotrast, this level of reliability has to be built withi the applicatio. BEEP is a coectio- orieted Iteret protocol proposal BEEP defies a framig mechaism for exchagig arbitrary MIME ad XML messages betwee peers. Profiles are defied for the chaels to help accomplish the commuicatio trasport goals. BEEP sessios are mapped to a uderlyig trasport, typically TCP. Oce a sessio is established, each peer advertises the profiles it supports. Whe a chael is created betwee peers, the cliet ad the server egotiate agreemet o oe or more mutually compatible profiles. Chaels the iitialize the sessio ad maitai the egotiated profiles ad the sessio characteristics for the duratio of the coectio. Data exchage profiles are usually created after the iitial tuig chaels have completed their egotiatios. Oly oe tuig chael ca be active at the same time, but multiple data exchage chaels ca be active at the same time. Whe a BEEP sessio is established, each peer is give either a listeig or a iitiatig role. Typically, the BEEP peer that iitiates the exchage is called the cliet, ad the listeig peer is called the server. But because BEEP is peer to peer, this relatioship is ot required. BEEP provides a peer-to-peer commuicatio model BEEP messages are grouped ito three styles of exchages: MSG/RPY, i which a cliet seds a message to the server ad the server returs a reply after performig a task MSG/ERR, i which the cliet seds a message but the server does ot perform ay task ad replies with a error message Page 170

172 MSG/ANS, i which the cliet seds a message ad the server performs a task durig the course of which it returs zero or more aswer messages followed by a ull termiatio message BEEP supports multiple message iteractio styles MSG/RPY ad MSG/ERR are called oe-to-oe positive ad egative exchages, respectively; MSG/ANS supports oe-to-may exchages. Messages are usually set i a sigle frame but ca be split across multiple frames if ecessary or coveiet, that is, if oly part of the message is ready. A frame comprises a header, a payload, ad a trailer. The header ad the trailer are defied usig ASCII characters, but the payload ca be aythig. The followig example illustrates a BEEP message cotaied i a sigle frame that cosists of a header, a trailer, ad a payload of 120 octets: C: MSG C: Cotet-Type: applicatio/beep+xml C: C: <start umber='1'> C: <profile uri=' /> C: </start> C: END A BEEP bidig to SOAP that shows how SOAP evelopes are trasmitted usig a BEEP profile has bee defied. [11] [11] See Reliable HTTP Reliable HTTP, or HTTPR, [12] is a IBM proposal that layers a coversatioal protocol o HTTP request/respose iteractios. HTTPR defies commads to push, pull, ad exchage a combiatio of push ad pull SOAP messages reliably betwee seder ad receiver pairs. HTTPR, like may of the Web services extesio proposals, works by isertig iformatio i SOAP headers, icludig a correlatio ID for matchig requests with replies. The reliable part of HTTPR persists iformatio about the message ad correlates ackowledgmets ad replies with the origial requests. Each party i the message path persistetly stores iformatio about the message alog with its uique correlatio IDs so that it's possible to trace the flow of a message ad to discover what happeed i the evet of failure. Similarly, persistece iformatio ca be used to retrasmit a message if the first attempt fails. Push ad pull commads ca be batched if the applicatio wats to trasmit bulk data. [12] See HTTPR defies how metadata ad applicatio messages are ecapsulated withi the payload of HTTP requests ad resposes, such as those used for SOAP messages. HTTPR ca also esure that each message is delivered to its destiatio applicatio exactly oce or is reliably reported as udeliverable. HTTPR specifies the commads, the state iformatio that eeds to be stored safely, ad whe to store the state iformatio i order to esure reliable message delivery. Page 171

173 Reliable HTTP defies persistece for SOAP message paths HTTPR requires HTTP v1.1. A seder iitiates a HTTPR iteractio by geeratig a HTTP POST request that icludes a HTTPR commad ad ay associated messages. The receiver replies usig a HTTP respose that icludes status iformatio about the message received ad, optioally, a batch of messages iteded for that seder. The seder assigs each message iteractio a idetifier, which is placed i stable storage alog with iformatio about the curret state of message processig. I the evet of a failure, this state iformatio is recovered from stable storage ad used to esure qualities of service, such as exactly-oce delivery, reliable trasfer followig iterruptios ad failures, or preservig the order of messages i a multihop commuicatio path. Additioal commads allow seders to iquire o the status of a message, give the uique ID, ad to report o the result of processig a message with a give ID. Web Services Foudatios RosettaNet ad XML-RPC are techologies that predate ad sigificatly iflueced Web services developmet. RosettaNet specificatios ad techologies also provided iput to ebxml ad cotiue to serve as a source of ispiratio for Web services proposals. It may help to uderstad a bit about these techologies to appreciate the desig ceter for Web services specificatios, the focus o keepig SOAP simple, ad what kids of additioal techologies make sese to add to a simple trasport layer. XML-RPC predates SOAP, ad it was used as a primary source for the origial SOAP specificatio. I geeral, SOAP ca be viewed as emergig from a combiatio of the cocepts behid these two origial XML protocols: oe as the source of the RPC-style iteractio ad the other as the ispiratio for the documet-orieted style of iteractio. Both techologies are i sigificat use today, which is likely to cotiue util Web services mature ad supersede them. XML-RPC pioeered the RPC-orieted Web service style RosettaNet The RosettaNet cosortium was lauched i Jue 1998, primarily as a orgaized respose i the electroics idustry to geeralize the success of such compaies as Dell Computer, which had begu efficietly maagig its supply chai by usig the Iteret. Persoal computer vedors are typical of electroics compaies that assemble fiished cosumer ad idustrial products usig stadard parts from a variety of suppliers. Closely trackig the availability of parts for specific products provides the best opportuity for just-i-time maufacturig o demad, as Dell has doe so successfully. RosettaNet is idepedet, self-fuded, ad oprofit. Its members comprise iformatio techology, electroic compoets, ad semicoductor maufacturig vedors. RosettaNet's goal is to develop ad to deploy electroic commerce stadards for busiess process automatio amog parters i the high-tech supply chai. RosettaNet pioeered XML-based stadards for B2B electroic commerce, ad its suite of specificatios, techologies, ad XML documets ecompass the etire high-tech supply chai. RosettaNet specifies commo busiess processes usig Parter Iterface Processes (PIPs) ad a XML protocol for etworked applicatio access: the RosettaNet Implemetatio Framework (RNIF). Page 172

174 RosettaNet pioeered the documet-orieted Web service style As show i Figure 7-4, which was captured from IONA's Orbix E2A Collaborate Developer Suite, a RosettaNet PIP defies a busiess trasactio flow, such as sedig a purchase order request ad receivig a ackowledgmet or sedig a purchase order chage request ad receivig a acceptace of the chage. The rule toward the middle of the diagram separates the flow betwee the purchaser ad the supplier. Figure 7-4. A RosettaNet PIP defies a busiess trasactio flow, such as this purchase order trasactio. The PIPs defie the documet types, such as specific purchase order forms, ackowledgmet ad error report forms, ivoicig ad shippig forms, ad so o, as well as the busiess processes required to complete the PIP. PIPs are completed by edig the chai of documet messages, or choreography of messages, defied for the PIP. RosettaNet implemetatios typically provide graphical displays of PIP iteractio flows. PIP implemetatios are iteroperable: As log as each vedor i the iteractio coforms to RosettaNet, the tradig parters ca exchage documets accordig to the steps defied for the agreed-o PIP. This exchage of documets amog tradig parters is also called busiess process choreography. Examples of busiess process choreography supported by PIPs iclude purchase order maagemet, distributio of ew-product iformatio, ad ivoice maagemet. A PIP specifies ot oly the XML busiess documet structure ad cotet format but also the time, security, autheticatio, ad performace qualities of service for a give type of documet-orieted iteractio. Page 173

175 PIPs represet publicly visible documet iteractios but do ot defie how the busiess processes ad documets are mapped to iteral IT systems or how the XML documets are mapped to ative data formats. However, PIP processig requiremets assume the existece of such iteral, or private, processes behid the public oes. RNIF defies the XML protocol evelope that carries withi its payload all documet exchages defied for a give PIP. RNIF's evelope format is idepedet of the specific trasfer protocol used to trasmit the message betwee parter odes, although most ofte it's implemeted over HTTP ad MIME. RNIF messages also iclude a header that carries iformatio about the PIP drivig the message iteractio sequece ad that cotais iformatio about the specific step withi that sequece that's active or ext. I this way, RNIF messages are self-describig ad provide iformatio ecessary for implemeters to maitai the proper order of steps i a orchestratio defied for a give PIP. RNIF features security mechaisms to digitally sig ad/or ecrypt all RosettaNet messages ad a reliable messagig mechaism based o ackowledgmets to esure that messages are set ad received securely ad surely. RNIF is a XML protocol for RosettaNet documets Like SOAP with Attachmets, RNIF v2 specifies the use of MIME multipart/related types for the basic evelopig costruct ad the S/MIME multipart/siged ad the applicatio/pkscs7-mime eveloped-data types for digitally sigig ad cotet evelopig purposes, respectively. The similarity of RNIF ad SOAP with Attachmets allowed RosettaNet to alig with ebxml as of RNIF v3. XML-RPC XML-RPC was developed by Dave Wier ad others at UserLad, [13] a Iteret publishig compay lookig for a more efficiet way of trasferrig XML documets across the Web ad developig iteractive Web sites. XML-RPC is a very simple ad straightforward defiitio of remote procedure call sematics i XML. As with SOAP, a XML-RPC message is carried as a HTTP POST request, ad the respose is carried as a ormal HTTP respose. The XML-RPC sytax represets a simple mappig to the RPC method ad argumet ame format ad is relatively ucomplicated compared to SOAP, without headers, complex serializatio formats, or abstractios suitable for documet-orieted iteractio. The XML-RPC specificatio simply requires that the XML message carried i the HTTP POST be mapped oto a procedure executio at the target host ad that the remote procedure be executed; the XML message the returs its results o the HTTP respose message. Procedure argumets ca be formatted usig simple data types, such as scalars, umbers, strigs, ad dates or ca use complex record ad list structures. For example: [13] See Programmig Web Services with XML-RPC (St. Lauret, Dumbill, ad Johsto, 2001). XML-RPC: More Real Tha SOAP? XML-RPC is much simpler tha SOAP ad, without WSDL ad associated specificatios, much easier to uderstad. More tha 30 implemetatios of XML-RPC are i use. It's a bit like the RosettaNet versus ebxml issue; oe is real, implemeted, ad used withi its world, but the other holds greater promise. POST /RPC2 HTTP/1.0 User-Aget: Frotier/5.1.2 (WiNT) Host: betty.userlad.com Page 174

176 Cotet-Type: text/xml Cotet-legth: 181 <?xml versio="1.0"?> <methodcall> <methodname>examples.getstatename</methodname> <params> <param> <value><i4>41</i4></value> </param> </params> </methodcall> The URI i the HTTP header show i the example icludes /RPC2, which ca be used to tell the server to route the request to the RPC2 respoder, thereby bypassig the Web server, or goig straight to the RPC mapper. The message payload, which is a simple XML documet, is cotaied usig a top-level <methodcall> elemet. The <methodcall> elemet cotais a simple <methodname> elemet to idetify the procedure to call ad a <params> elemet to cotai the data for the procedure argumets. XML-RPC messages map to methods XML-RPC does ot defie how to map the <methodname> to a actual method or procedure; that's up to the implemetatio. As log as a implemetatio is capable of acceptig a XML- RPC message, mappig it to a procedure or method, ad returig the result correctly formatted as a XML-RPC respose, the remaider of the details ca be implemetatio specific. The methodname could be the ame of a file cotaiig a script that executes o a icomig request, the ame of a cell i a database table, or a path to a file cotaied withi a hierarchy of folders ad files. For example: HTTP/ OK Coectio: close Cotet-Legth: 158 Cotet-Type: text/xml Date: Fri, 17 Jul :55:08 GMT Server: UserLad Frotier/5.1.2-WiNT <?xml versio="1.0"?> <methodrespose> <params> <param> <value><strig>south Dakota</strig></value> </param> </params> </methodrespose> The example illustrates the respose to a XML-RPC message. As i SOAP, the HTTP 200 OK i the respose message idicates success. Page 175

177 If ay kid of error occurred i executig the procedure or hadlig the message, the respose must cotai a <fault> elemet to idetify the problem. The body of a respose ca cotai either a <params> elemet or the <fault> elemet but ot both. For example: HTTP/ OK Coectio: close Cotet-Legth: 426 Cotet-Type: text/xml Date: Fri, 17 Jul :55:02 GMT Server: UserLad Frotier/5.1.2-WiNT <?xml versio="1.0"?> <methodrespose> <fault> <value> <struct> <member> <ame>faultcode</ame> <value><it>4</it></value> </member> <member> <ame>faultstrig</ame> <value><strig> Too may parameters. </strig></value> </member> </struct> </value> </fault> </methodrespose> The example illustrates a possible fault message respose. This type of error reflects a applicatio-level error rather tha a protocol-level error, which would be retured as a HTTP error 400 or 500. Note the use of embedded XML elemets for a data type defiitio. Summary May additioal techologies are eeded to complemet the core Web services specificatios for use i complex ad demadig busiess applicatios. To be viable, Web services specificatios eed security, process flow, trasactios, messagig improvemets, ad other qualities of service. A referece architecture for additioal Web services techologies is eeded to guide the developmet of these additioal techologies with respect to clearly defiig what's eeded ad what is't ad how additioal techologies iteract with oe aother ad with the core specificatios. Efforts are uder way to defie security stadards to protect documet cofidetiality ad itegrity ad to create mechaisms to cotrol who is allowed to access which Web service iterfaces. Sample specificatios ad proposals are available o the Iteret for security techologies, referece architectures, process flow, trasactio coordiatio, message routig, ad reliable messagig. A combiatio of these ad perhaps other, as yet udefied, specificatios will emerge to provide the ext layer of fuctioality for Web services techologies, makig them suitable for more ad more types of missio-critical applicatios. Some sese of where Web services came from ad where they are goig ca be gleaed from studyig RosettaNet ad XML- RPC, two widely used techologies that predate Web services. Page 176

178 Chapter 8. Implemetig Web Services To be useful, SOAP, WSDL, UDDI, ad ebxml eed to be widely implemeted ad available i software products. Oly the ca the goal of achievig iteroperability ad itegratig disparate software systems be attaied. May software vedors have already begu to implemet these ad other key Web services specificatios, ad may more of the vedors have pledged to provide more complete implemetatios i the future. Web services techologies eed wide adoptio to be useful Implemetatio efforts ted to fall ito two major categories, leavig Web services developers ad deployers with a choice. I the software idustry, oe large commuity revolves aroud the Microsoft eviromet, ad aother revolves aroud the Java eviromet. Both eviromets provide support for Web services developmet ad deploymet, ad therefore developers ad Web services users i geeral have a choice to make. Of course, because Web services are all about iteroperability ad itegratio, these two eviromets are compatible, at least to the extet that they both implemet the same specificatios ad iterpret them the same way. Developers have a choice Microsoft is focusig its implemetatio withi its.net iitiative, whereas Su Mircrosystems ad other Java vedors are focusig their implemetatios withi the Java 2 Platform, Eterprise Editio (J2EE) iitiative. As the leader of the Java iitiative, Su Microsystems has published its Ope Network Eviromet architecture (SuONE) as a blueprit for the evolutio of Web services. Microsoft has defied its Global XML Architecture for extedig Web services support i the.net Framework ad i geeral through stadardizatio. Now that the core techologies have bee established as widely adopted specificatios, the ext step is to defie a comprehesive architecture for additioal techologies, such as security, process flow, reliable messagig, ad trasactios. The W3C Web Services Architecture Workig Group is doig just that (see Both.NET ad J2EE support Web services Because Web services solve eterprise itegratio problems, itegratio broker vedors support Web services via adapters ad itegratio compoets, or buildig blocks. Database vedors support Web services iterfaces directly to database maagemet systems. Eterprise resource plaig (ERP) ad customer resource maagemet (CRM) packaged applicatios support Web services iterfaces for itegratio with other packages ad software products. Fially, a umber of vedors are producig products aimed purely at implemetig a Web services layer. Itegratio brokers, packaged applicatios, ad database products also support Web services The mai categories of Web services implemetatio activities therefore are Microsoft's.NET Framework: Widows is well established as the most popular desktop eviromet, ad may developers use Microsoft tools for both cliet-ad server-side applicatios. Microsoft is addig Web services support throughout its.net platform, i Page 177

179 which every program is potetially a Web service, ad all trasports ca use XML protocols. Applicatio servers: The J2EE commuity, comprised of applicatio server vedors, is addig Web services applicatio programmig iterfaces (APIs) to Java servlets, classes, ad beas, makig XML itegratio ad Web services part of the core applicatio server defiitio. Itegratio brokers: Vedors i this middleware market segmet are usig Web services for eterprise applicatio ad busiess-to-busiess (B2B) itegratio, bridgig Web services applicatios iside ad outside the firewall. Database vedors: Vedors i this group are focusig o the use of Web services to provide a meas of accessig database tables ad stored procedures. ERP, CRM, ad others: These packaged applicatio vedors are addig Web services iterfaces for itegratig those packages with other packages ad software systems. Web services platform: Vedors i this market segmet are developig ad supplyig Web services ifrastructure products as idepedet, or self-cotaied, products. Web services implemetatios fall ito six categories Some vedors offer products i more tha oe category. IONA, for example, provides a Web services platform product, a applicatio server product with Web services support, ad a itegratio broker product with Web services support. If othig else, the diversity of implemetatio highlights the flexibility ad extesibility of Web services. Web services are defied at a sufficietly high level of abstractio to allow multiple applicatios for a broad variety of products. Vedors, whether focused o.net, J2EE, or itegratio broker middleware, however, ted to follow a umber of basic architectures for Web services implemetatio. Vedors offer products, i multiple categories Implemetatio Architectures Implemetatio architectures vary accordig to the degree to which the Web services layer is apportioed value i the overall solutio. I providig a Web services iterface to a database maagemet system, for example, the primary value of the solutio remais apportioed withi the database layer rather tha i the Web services layer. The Web services layer becomes oe of may optios for iteractig with the data i the database. O the other had, the Microsoft My Services iitiative apportios sigificat value to the ability of multiple Web services to iteract i combiatio ad to create applicatios differetly or more quickly by usig them. Implemetatios vary i the value assiged to the Web services layer Because Web services are ot executable, much of the value i the developmet eviromet, such as J2EE ad the.net Framework, remais withi the programmig laguages beeath the Web services. Web services represet aother meas of exchagig iformatio with the applicatio server, which still performs the mai job of applicatio developmet ad itegratio. A certai value exists i the Web services layer itself, primarily for itegratig, or orchestratig, multiple Web services compoets, which are implemeted usig a variety of laguages, middleware systems, database maagemet systems, ad packaged applicatios. Web services map messages to server objects Figure 8-1 illustrates the Web services implemetatio architecture i which.net ad J2EE applicatio servers expose programs ad classes as Web service compoets. The programs ad classes represet a variety of back-ed techologies accessed usig the applicatio server, icludig Eterprise JavaBeas,.NET classes, message queues, ad CORBA objects, to ame a few. Page 178

180 Figure 8-1. A applicatio server exposes back-ed techologies usig a Web services iterface. Figure 8-2 illustrates the Web services implemetatio architecture i which a Web services iterface is used to access a database table or a stored procedure. This type of access ca be thought of as a two-tier architecture, ulike the applicatio server architecture, which icludes a middle tier for busiess logic that is developed ad maaged idepedetly of the back tier for data access. Figure 8-2. A Web Services iterface is used to access database tables ad stored procedures. Web services map messages to databases Page 179

181 Figure 8-3 illustrates the Web services implemetatio architecture i which a Web services iterface maps directly to a queued message system, such as Java Messagig Service (JMS) or MQSeries, or to a B2B server, such as IONA's Orbix E2A Collaborate. I both cases, the SOAP message is treated as iput to a asychroous commuicatio system for processig. The message is stored i a persistet queue or database ad is forwarded to aother queue for processig. Fially, results are writte to a reply queue. I this way, Web services represet aother way ito ad out of existig B2B ad applicatio-to-applicatio (A2A) itegratio broker products. For a itegratio broker vedor, the mai value remais withi the adapters, trasformers, routers, ad other parts of the toolkit. Figure 8-3. I a itegratio broker architecture, a Web services iterface maps to A2A ad B2B products. Web services map messages to queues Figure 8-4 illustrates the Web services implemetatio architecture for packaged applicatio software such as ERP, CRM, ad accoutig/billig systems. For a ERP or a CRM system, the primary value of the applicatio remais i the features ad fuctios of the software package as related to busiess operatio support. Web services, therefore, basically represet aother meas of gettig data i ad out, albeit a widely adopted ad supported meas. Packaged-applicatio software vedors, such as Baa, PeopleSoft, SAP, Siebel, ad others, also are startig to offer itegratio products usig Web services techology. Page 180

182 Figure 8-4. A Web services iterface ca be implemeted for a packaged applicatio architecture. Web services map messages to packaged applicatios Figure 8-5 illustrates the Web services implemetatio architecture that focuses o the value iheret i the Web services layer. A busiess process flow egie or other meas of orchestratio lies at the ceter of the value propositio i this architecture, which depeds o the relatioship amog Web services to achieve or to create ew applicatios at a higher level of abstractio. I other words, Web services have value because they are widely adopted ad implemeted, allowig multiple disparate software domais to be itegrated. The process of itegratig such domais requires certai fuctioality above the core Web services stadards, such as process flow, security, reliable messagig, trasactios, ad so o. Web services brokers, such as IONA's Orbix E2A XMLBus Editio, are built to provide this value. I this way, disparate software domais are bridged, multiple vedor Web services implemetatios are joied, ad ew applicatios are created from a combiatio of old oes. Figure 8-5. A Web services broker focuses o value i the Web services layer. Page 181

183 Web services brokers itegrate them all The Major Implemetatio Streams The variety of vedor views ad implemetatio architectures is uderstadable, as established vedors ted to view Web services i terms of additios or extesios to existig, successful product lies. Web services techologies are desiged to be extesible, meaig that differet vedors are goig to have differet iterpretatios, ad may differet types of products are goig to emerge. Vedors represet a variety of views Oe key aspect of Web services therefore is achievig ad maitaiig iteroperability ad compatibility. For Web services truly to succeed, vedor products must become ad remai as compatible with oe aother as today's browsers, Web servers, ad HTML tools. This cocept is beig applied to Web services proposals ad must be adhered to for Web services to succeed as widely as HTML ad Web servers have. Iteroperability eeds to be maitaied May uresolved problems remai withi the Web services commuity, as show by the additioal proposals i Chapter 7 ad i the cotiuig work to complete ebxml. Differet vedors focus o differet value propositios ad are therefore likely to implemet differet sets of additioal Web services techologies. Page 182

184 Uresolved issues exist maily at the level of additioal techology Util a comprehesive Web services architecture is available, like that created to guide the Object Maagemet Group's success with CORBA, the vedor commuity will stay divided by differeces of opiio ad iterpretatio. Meawhile, the two most sigificat ad ifluetial threads of activity aroud Web services remai.net ad J2EE..NET ad J2EE represet sigificat implemetatio activities Microsoft's.NET It's fair to say Microsoft iitiated idustry focus o Web services, ad Web services support is perhaps the most sigificat aspect of.net, a broad-based iitiative through which a variety of products is beig developed ad delivered to market. This effort also icludes ehacemets to Widows, COM+, ad a variety of specialized server products. Web services are a sigificat part of.net Like previous geeratios of Microsoft techology for applicatio developmet ad deploymet,.net icludes programmig tools desiged for optimal use of Widows operatig system features ad fuctioality. The Visual Studio.NET itegrated developmet eviromet (IDE) is tightly itegrated with Widows, automatically geerates code for.net servers, ad takes full advatage of sigificat Widows features..net makes optimal use of Widows Although.NET icludes Web services, it is also a brad that applies to a group of techologies. Some of these techologies are ew; other techologies have bee updated to provide a ew approach to creatig Widows applicatios. Still other parts of.net are rereleases of existig techologies. [1] [1] See Uderstadig.NET by David Chappell (Addiso-Wesley, 2002)..NET is a brad applied to a rage of techologies.net ad the Web Although.NET defiitely supports Web services ad is perhaps best kow for that, it also supports other thigs, such as developig ew applicatios ad deployig them o a variety of servers. Most other approaches to Web services simply wrap applicatios with Page 183

185 mappigs to ad from XML data structures ad formats. The.NET iitiative goes further, perhaps because it's iteded to represet the ext geeratio of VB ad Widows ad adds to the.net framework thigs eeded for Web services. Microsoft has to be sure to avoid gettig ito the busiess of requrig its software to be at each ed of the commuicatio, which would be atagoistic to the Web's origis as a free, ope, ad completely stadard place. To Microsoft's credit, however, it has remaied pretty sicere about helpig to stadardize the base protocol, ad cotiues to be very active at W3C. The followig are the major parts of.net:.net Framework: Icludes the Commo Laguage Rutime (CLR) ad the uified class library. The CLR is a stadard foudatio for buildig a rage of ew applicatios, whereas the uified class library provides may ew applicatio services. Amog the techologies i the library are ASP.NET, which is the ext geeratio of Active Server Pages (ASPs); ADO.NET, the ext geeratio of ActiveX Data Objects; support for implemetig Web services; ad much more. Microsoft is also releasig a trimmed-dow versio called the.net Compact Framework, iteded for use i smaller devices, such as set-top boxes, persoal digital assistats (PDAs), ad wireless phoes. Visual Studio.NET: Provides a visual programmig eviromet for the programmig laguages that ca be used with the.net Framework: Visual Basic, a ehaced versio of C++, ad a ew laguage called C#, which was desiged explicitly for use i the.net Framework..NET Eterprise Servers: Host the server applicatios that the.net Framework typically ivokes, although they do't all ecessarily make use of it. These servers iclude BizTalk Server 2000, Applicatio Ceter 2000, Commerce Server 2000, Host Itegratio Server 2000, SQL Server 2000, Exchage Server 2000, Mobile Iformatio Server 2001, ad Iteret Security ad Acceleratio Server These products are largely idepedet of the other.net techologies listed here..net has three major parts ASP.NET is the recommeded techology for implemetig Web services based o the.net Framework. ASP.NET Web services process service requests usig SOAP over HTTP, as well as HTTP GET or POST. ASP.NET Web services automatically geerate WSDL ad Disco (precursor of WS-Ispectio) files for Web servic es. You ca use ASP.NET Web services to implemet a Web service listeer that accesses a busiess façade implemeted as a COM compoet or maaged class, typically hosted o a.net server. The.NET Framework developmet kit also provides tools to geerate proxy classes that cliet applicatios ca use to access Web services. ASP.NET is the recommeded techology for Web services Note that ASP.NET Web services like ay Web services do ot expose the server-side data types to cliet applicatios. These are completely hidde iside the Web service. The.NET Web services tools assume a stateless programmig model that is, each icomig request is hadled idepedetly. The oly state maitaied betwee requests is aythig persisted i a data store. Web services are stateless Page 184

186 .NET remotig, however, supports a more tightly coupled, object-based programmig model betwee cliet ad server, which provides remote access to server-side objects with full data type fidelity. Cliets ca also obtai refereces to server-side objects ad cotrol the lifetime of those objects for stateful iteractio. If you use these object lifetime services, however, cliet applicatios will also eed to be implemeted usig.net Remotig..NET Remotig supports stateful iteractios I additio to the features provided by the.net Framework, Visual Studio.NET provides tools to help you build, deploy, ad cosume Web services. For example, the IDE supports UDDI ad Disco for locatig Web services ad uderstads how to geerate cliet-side proxies from WSDL files. Visual Studio.NET also icludes the Active Template Library (ATL) server, which C++ developers ca use to costruct Web service listeers that coect to a busiess façade implemeted as a C++ class. ATL Server supports SOAP over HTTP, will automatically geerate WSDL files for your Web services, ad also provides tools to geerate C++ proxy classes that cliet applicatios ca use to access Web services. Visual Studio supports UDDI, WSDL Off-Platform.NET Microsoft has bee backig several iitiatives desiged to make.net more ope ad more acceptable to customers cocered about the potetial lock-i o Widows platforms. Off-platform versios of.net are uderway, although it must be oted that previous efforts to deliver off-platform implemetatios of COM ad COM+ were ot commercially successful. Ximia [2] is sposorig a project to build a Ope Source versio of.net. I additio,.net specificatios have bee submitted to the Europea Computer Maufacturers Associatio (ECMA), which also egaged i COM API stadardizatio. The submitted specificatios iclude the Commo Laguage Rutime, the Microsoft Itermediate Laguage (MSIL), ad may of the.net Framework classes. Still, it remais to be see whether idepedet implemetatios ad stadardizatio of.net will ever get off the groud ad whether reimplemetatios of.net, such as the Ximia ope source versio, will ever succeed. It's traditioally bee very difficult to "me-too" Microsoft ad to keep off-platform implemetatios up to date. Also, may of the.net features rely o Widows features, especially those for the cliet side ad developmet eviromet. Will off-platform.net be able to succeed without those features? No oe imagies that ayoe else will be able to supplat or eve to duplicate Microsoft's presece o the desktop. Perhaps iteroperability solutios will be eough, however, to allay fears of lock-i. [2] A vedor of ope source desktop software, icludig GNOME. The.NET project is called Moo see Page 185

187 Does.NET Mea a Iteret Operatig System? Bill Gates's aoucemet of.net icluded a descriptio of.net as the equivalet of Widows for the Iteret. If you had a service you relied o withi the Widows operatig system i the past, he said, i the future you would rely o the equivalet service over the Iteret. If you eeded to store a file, set a date i your caledar, sed e- mail, or ivoke ay type of programmatic service, you would do so usig.net or Web services istead of usig a operatig system service. This visio is as broad ad compellig as it is fatastic. Imagie depedig o the Iteret or a Web service the way you'd rely o a desktop operatig system service! Still, the idea of assemblig applicatios ad computig platforms out of stadard compoets, the way you'd put together a PC, sigifies great potetial chage i software developmet ad deploymet. Microsoft's visio of Web services is that they will itegrate services typically thought of as desktop, or local operatig system, services with services accessed over the Web. Therefore.NET supports, or will support, all types of Web services iteractio styles. Multiple vedors, such as IONA, Metratech, ad Satra, are also providig geeric Web services, or Web services buildig blocks..net will support all types of Web services iteractio styles J2EE ad Applicatio Servers Applicatio server vedors are extedig their products with Web services capabilities, i much the same way that may ew tec hologies ted to get icorporated ito J2EE, as ew APIs. J2EE vedors are supportig Web services As show i Figure 8-6, Web services ca be itegrated with applicatio servers, such as WebLogic, WebSphere, ad Orbix E2A J2EE Editio, to provide access to a variety of back-ed systems, icludig.net classes ad COM objects, Eterprise JavaBeas, CORBA objects, MQSeries, MSMQ, ad Java Messagig System queues. The SOAP messages arrive via the Web server itegrated with the applicatio server's servlet egie, i which is deployed a Java class represetig, or wrappig, the back-ed system to be itegrated. Web services toolkits, such as IONA's XMLBus ad those itegrated directly with WebLogic ad WebSphere, traslate this Java class ito a correspodig WSDL file, which ca be stored i a UDDI or a ebxml registry. The SOAP cliet ca fid the locatio of the WSDL file from the registry or directly, usig its URL, ad ivoke the Web service. Figure 8-6. Web services ca be itegrated with applicatio server eviromets. Page 186

188 Microsoft Support for Web Services Stadards Microsoft has pledged to support a commo set of Web services stadards or the railroad tracks o top of which ru the trais carryig XML data. Microsoft believes, correctly, that a basic or miiumum set of agreed-o XML stadards will be ecessary for Web services adoptio. However, a sigificat challege will be to figure out where to draw the lie betwee the miimum set ad a larger set of potetially useful stadards. This is a bit like the questio of where to draw the lie betwee the Web services movemet ad the ebxml iitiative. The latter seeks to establish stadards at a higher level of abstractio from the core techologies, focusig o the busiess process model. Microsoft is bettig, of course, that if the appropriate level of Web services techologies gais acceptace as stadards, the compay will be able to fid a good way of makig a profitable busiess out of techologies ad tools layered o them, or perhaps out of supplyig cotet for them, just as the steel idustry profited from the establishmet of a atioal rail system (Drucker, 1999). Microsoft has led the way with may W3C submissios for this reaso. Applicatio Server Vedor View Su Microsystems iitiated ad has bee at the forefrot of a developer commuity ad executio eviromet set of techologies based o the Java programmig laguage ad its various editios. The Java 2 Platform, Eterprise Editio (J2EE) has become the focus for Web services techologies for the Java commuity, icludig the leadig applicatio server vedors. Su Microsystems has provided cosistet leadership for this commuity ad is extedig the leadership with respect to Web services. Su Microsystems views Java as the most suitable laguage for Web services developmet, ad the Java commuity has already produced may products. Su Microsystems provides leadership for the J2EE commuity process J2EE vedors essetially view Web services as aother type of applicatio server cliet. All the requisite qualities of service are defied i J2EE ad implemeted i applicatio servers. Ulike.NET, the idea of creatig J2EE applicatios usig Web services buildig blocks is ot yet prevalet. The J2EE commuity views Java classes ad beas as the buildig blocks, with Web Page 187

189 services a type of iterface ito ad out of them. Web services may evetually support a level of quality of service equivalet to that of J2EE-based applicatio servers, but Web services may eed to take their ow directio, especially whe multiple, disparate software domais are to be bridged across the Iteret. Ad, it is likely to be a log time before Web services ca match the qualities of service already available i J2EE-based applicatio servers. Web services are cliets to applicatio servers Some of the Java-orieted views toward Web services iclude the followig ideas: J2EE applicatios expose EJBs ad JMS destiatios as Web services. Exposed services ca use WSDL as the service descriptio laguage ad ca provide access to compoets usig SOAP over a HTTP trasport. Services are published ad distributed through ad hoc meas. Private registries, possibly based o UDDI, are used to itegrate with parters by some applicatios. Web services will ot chage existig tradig-parter policy ad covetio agreemets. Applicatio servers use Web services for a variety of iteractios Applicatio Server Vedor Positio While Microsoft is placig its bet o reivetig its core services based o XML, BEA Systems, IBM, Su Microsystems, ad others are bettig that the Java platform established today i products such as WebSphere, WebLogic, ad iplaet will cotiue to evolve as the developmet eviromet of choice for Web services. Most of the Web services work i the applicatio server market is focused o iitiatives to exted J2EE with APIs supportig Web services stadards ad techologies. Web services are i may ways a atural fit for applicatio servers, as show i Figure 8.6. Java APIs for Web Services The J2EE stadard defies Java APIs for eterprise services, such as security, messagig, trasactio maagemet, ad directory lookup. The J2EE APIs are provided i applicatio server vedor products from BEA Systems, HP, IBM, IONA, Oracle, Su Microsystems, ad others. Several efforts are uder way to exted J2EE APIs for use with Web services. These APIs facilitate parsig ad maipulatig XML from withi J2EE servers ad provide access from J2EE servers to exteral Web services techologies, such as UDDI. J2EE icludes ew APIs for Web services Table 8-1 shows the Java Commuity Process (JCP) iitiatives, led by Su Microsystems, that are relevat to Web services. The JCP iitiatives show i Table 8-2 related to Web services are led by other vedors. JCP members defie the APIs Page 188

190 J2EE Iitiatives for Additioal Techologies Sigificat work is already uder way withi the JCP for Web services security ad trasactios. Additioal techologies, which are show i Table 8-3, will provide the basis for secure, reliable, robust, ad complex busiess applicatios for J2EE-hosted Web services. APIs are uder way for security ad trasactioig Reliable Eterprise Web Services Already i ebxml Eterprise qualities of service specificatios such as routig ad reliable messagig already exist withi ebxml. May large vertical stadards orgaizatios have said that they will adopt ebxml for these purposes sice ebxml already defies routig ad reliable messagig o top of SOAP. The relatioship betwee ebxml's reliable messagig ad the reliable messagig specificatios created for the Microsoft GXA are udefied, however. Covergece o a sigle solutio is always better but, i this case, by o meas guarateed. Table 8-1. Su Microsystems-Led JCP Iitiatives Iitiative Descriptio Java API for XML Provides users with pluggable APIs for XML parsig ad Parsig (JAXP) trasformatio. For parsig, for example, a applicatio could use either a DOM or a SAX parser through JAXP. I either case, the developer ca choose to use ay amog may compatible DOM or SAX parsers. Java API for XML This specificatio defies Java APIs for exchagig busiess Messagig (JAXM) documets XML documets ad other arbitrary data amog tradig parters. JAXM implemetatios are expected to package the documets, usig SOAP with Attachmets, ebxml Trasport, RosettaNet, or BizTalk, ad to deliver the documets to the iteded destiatio. JAXM defies a low-level Java API for costructig ad routig SOAP messages ad APIs for emergig messagig stadards, such as ebxml. Java APIs for XMLbased This specificatio defies Java APIs for SOAP ad potetially other RPC (JAX RPC) XML-based RPC-orieted protocols. The APIs iclude those for Marshalig ad umarshalig argumets Trasmittig ad receivig calls, icludig portable stubs ad proxies Mappig SOAP RPC-style iteractios oto Java iterfaces, classes, ad methods Mappig Java iterfaces, classes, ad methods oto SOAP RPC-style iteractios JAX RPC defies APIs to map SOAP oto Java classes ad vice versa, that is, Java APIs that perform the mappig to ad from XML i the form of SOAP messages. Java APIs for XML This specificatio defies Java APIs for access to UDDI ad ebxml Registries (JAXR) registries for storig ad retrievig iformatio about a busiess's Web services ad other iterfaces. Ideally, JAXR will provide oe set of Page 189

191 Table 8-1. Su Microsystems-Led JCP Iitiatives Iitiative Descriptio APIs that ca be used idepedetly of the uderlyig registry implemetatio, much the way curret Java Namig ad Directory Iterface (JNDI) APIs ca be mapped to ay uderlyig directory service. JAXR provides a abstractio for XML registries so that it has pluggable support for curret registry stadards such as the ebxml Registry/Repository ad UDDI, ad also for future registry stadards that may emerge. By usig JAXR, developers ca build cliets that ca work with diverse registry implemetatios. JAXR supports the full life-cycle spectrum for maagig objects ad services i a registry, such as registerig, updatig, queryig, ad deletig objects or services i the registry. The Java Web Provides a complete set of techologies for tools vedors to Services Pack Developer icorporate support for Web services i their products. The pack combies all of the Java XML APIs ad techologies with other key techologies. Cosequetly, developers have all the tools they eed to start developig robust web services. Services developed usig the Java Web Services Developer Pack ca the also be deployed ito a secure, reliable, ad scalable J2EE eviromet. SourceForge ebxml Su Microsystems doated a iteral implemetatio of the Registry/Repository ebxml registry ad repository to the ope source commuity at Ope Source Project SourceForge. A growig developer commuity from may compaies ad coutries is workig o this project (see Table 8-2. JCP Iitiatives Led by Other Vedors Iitiative Descriptio Java APIs for This JSR provides a stadard set of APIs for represetig ad WSDL maipulatig services described by WSDL documets. These APIs defie a way to costruct ad to maipulate models of service descriptios. ebxml CPP/A This JSR provides a stadard set of applicatio programmig iterfaces APIs for Java for represetig ad maipulatig iformatio described by ebxml CPP ad CPA documets. Implemetig Eterprise WebServices This specificatio defies, comprehesively withi the J2EE platform, a architecture for developig ad executig Web services, icludig JAXM, JAXR, ad JAX RPC. This specificatio also refereces Java APIs uder developmet for XML Data Bidig (JAXB). JAXB bids XML documets to Java objects, usig XML schemas, ad provides a bidig framework API for accessig the geerated Java objects (see Uderstadig.NET versus J2EE The mai differece betwee Microsoft's.NET ad the various forms of Web services toolkits associated with applicatio servers is that Microsoft views Web services as the thig you develop. By cotrast, applicatio server vedors view Java classes ad Java beas as the thig you develop, eve whe you are ostesibly developig Web services. With the.net approach, developmet ad deploymet of a Web service occur i a sigle stage. Oce you write a program i ay oe of the.net laguages, you have oly to push a butto to create ad deploy it as a Web service. Every program is a Web service to.net, or at least potetially so. Page 190

192 Table 8-3. JCP Security ad Trasactio Web Services Techologies Techology Descriptio Java Specificatio This specificatio defies a stadard set of APIs ad a protocol for Request (JSR) 104: a trust service. A key objective of the protocol desig is to XML Trust Service miimize the complexity of applicatios usig XML Sigature. By APIs becomig a cliet of the trust service, the applicatio is relieved of the complexity ad sytax of the uderlyig PKI used to establish trust relatioships, which may be based o a differet specificatio such as X.509/PKIX, SPKI, or PGP. JSR 105: XML Digital Sigature APIs JSR 106: XML Digital Ecryptio APIs This specificatio defies a stadard set of APIs for XML digital sigatures services. The XML Digital Sigature specificatio is defied by the W3C. This proposal is to defie ad to icorporate the high-level implemetatio-idepedet Java APIs. This specificatio defies a stadard set of APIs for XML digital ecryptio services. This proposal is to defie ad to icorporate the high-level implemetatio-idepedet Java APIs. JSR 155: Web This specificatio provides a set of APIs, exchage patters, ad Services Security implemetatios to exchage assertios securely with itegrity Assertios ad cofidetiality betwee Web services based o OASIS SAML. JSR 156: XML The specificatio provides a API for packagig ad trasportig Trasactioig API ACID trasactios ad exteded trasactios, such as the BTP for Java (JAXTX) from OASIS, usig the protocols beig defied by OASIS ad W3C. I the Java world, Web services are a two-step process i which programmers develop classes ad beas ad the decide as a secod step which of them, if ay, are to be created ad deployed as Web services. Applicatio server developers ofte desig ew classes ad beas for the specific purpose of exposig busiess logic as a Web service, as existig classes ad beas are writte at a level of graularity more appropriate to use withi a tightly coupled biary protocol ruig i a LAN eviromet. Some tools also geerate Java classes from Web services, but creatig a Web service from a Java program is ot the default assumptio, as it is for the.net developers. Applicatio server "tiers" still commuicate usig RMI or RMI/IIOP, whereas.net tiers commuicate usig XML protocols. I short,.net is a thorough, fudametal rearchitectig of a distributed computig platform based o Web services, while applicatio server support for Web services teds to be desiged more as aother cliet, or presetatio tier for the back-ed system. This may chage, however, as more of the JCP-defied APIs for Web services get adopted. Vedor Views o Adoptio of Web Services Techologies A brief questioaire was set to leadig Web services vedors to obtai their views o the curret state of adoptio for the basic Web services techologies SOAP, WSDL, ad UDDI ad for ebxml, ad o the future directio of Web services. Support is uaimous for SOAP ad the idea of Web services, but some questios remai about the adoptio for WSDL, UDDI, ad ebxml, i that order. All the vedors agreed that followig the adoptio ad implemetatio of the core stadards, the ext step is to stadardize the additioal techologies required for more complex ad robust busiess applicatios. Vedors provided their ow views Page 191

193 This sectio summarizes the resposes ad lists these vedors' curret types of products that provide Web services, ad what type. The statemets about curret products ad future directios are take from their replies to the questioaire. I additio, some of the vedors took advatage of the opportuity to submit a brief aalysis. The Questioaire A questioaire was set to BEA Systems, Cape Clear, HP, IBM, IONA, Microsoft, Oracle, Su Microsystems, ad Systiet. The iformatio i this sectio represets the views of the vedors as they respoded to the questios. The first questio was aimed at discoverig the extet of support for the core Web services techologies covered i this book SOAP, WSDL, UDDI, ad ebxml especially i terms of product implemetatio. The secod questio gave the vedors a chace to discuss ext steps for Web services, either i terms of their product roadmaps or i relatioship to the idustry as a whole. Questioaire set to major vedors Followig a brief itroductio, the origial text was preserved wherever possible because the replies were ot cosistet with respect to format or cotet. I some cases, the replies were almost etirely i the form of aalysis. I all cases, the views stated are those of the respective compaies. Iformatio preseted as received The Questios 1. Basic iformatio: Widespread adoptio ad implemetatio seem esured for the core Web services stadards SOAP, WSDL, ad UDDI ad, to some extet, ebxml specifically the trasport, CPP, ad CPA subsets. Please idicate ay opposig views; otherwise, the book will state agreemet o this poit. Could you please provide a list for iclusio i the book of the products that implemet these stadards? Provide a brief descriptio of each product's major features ad beefits; that is, what would your customers use them for ad how had-built, geerated, combiatio of the two, ad so o. 2. Next steps: Followig the adoptio ad implemetatio of the core stadards, the ext step is to stadardize the additioal techologies required for more complex ad robust busiess applicatios. Please idicate ay opposig views; otherwise the book will state agreemet o this poit. Which of the various proposed additioal techologies security, trasactios, routig, reliable messagig, process flow, ad so o are the most importat? Ad which oes, if ay, are most likely to achieve a level of adoptio comparable to the core stadards? Which oes, if ay, do you ited to implemet? Page 192

194 I summary, it appears that SOAP is widely supported, adopted, ad implemeted withi products. WSDL also is very widely supported, ad may products already provide implemetatios. However, some questios remai with respect to its evolutio ad the extet to which it may chage durig formal stadardizatio. UDDI ad ebxml raised the most questio marks amog the respodets; however, the cosesus i favor of UDDI remais strog. Several vedors are implemetig parts of ebxml, but the extet to which the complete ebxml architecture will be adopted remais uclear. Uaimous o SOAP, early so o WSDL Vedors showed less agreemet about ext steps ad the adoptio of additioal techologies. However, all vedors metioed commo themes i recogizig the eed for these additioal techologies, idetifyig security, reliable messagig, trasactio processig, ad process flow as importat, although i varyig priorities ad orders. Su Microsystems, for example, poited to ebxml for may of the additioal techologies, while Microsoft poited to their GXA istead. Differece of opiio strogest o ebxml BEA Systems BEA, like HP, was workig o XML-based protocols ad products of its ow whe Web services hit. Like Su Microsystems, BEA atteded the Jue 2000 W3C Workshop o XML Protocols i Amsterdam to help evaluate whether to support SOAP. By the time of the WSDL submissio to W3C later that year, BEA had joied the effort as a cosubmitter, clearly idicatig its support for Web services. Sice the, BEA has become very active i the Web services commuity ad, like other applicatio server vedors, has begu shippig Web services support i its products. BEA is active at W3C ad i the JCP efforts to defie Java APIs for Web services techologies. BEA's Web service implemetatio ceters o its WebLogic flagship applicatio server product. Web Services for the J2EE Professioal WebLogic Server has two ways to create ad to cosume Web services. Each approach is targeted at a differet developer audiece. For the J2EE professioal developer, WebLogic Server provides a ituitive way to expose J2EE compoets as Web services. For developers who are ot comfortable with the complexity of the J2EE programmig model, a ew IDE ad framework, amed WebLogic Workshop, provides a higher level of programmig abstractio that shields the developer from the complexities of J2EE ad object-orieted programmig. Web services for the J2EE professioal are implemeted usig three types of compoets: Back-ed J2EE compoets Hadlers, for preprocessig ad postprocessig SOAP requests Serializers ad deserializers, for covertig data betwee a XML represetatio ad Java objects These compoets are liked together i a pipelie model of processig. The pipelie allows developers greater cotrol over the hadlig ad orderig of processig of SOAP messages. Page 193

195 Back-ed compoets ca be oe or more stateless sessio EJBs for RPC calls or message-drive beas for asychroous messagig. WebLogic Server provides a simple mechaism for exposig the appropriate EJB methods as operatios of a Web service ad geerates the associated WSDL file automatically. Hadlers are optioal compoets that provide access to the SOAP message before ad after ivokig the back-ed compoet. They typically are used for processig ad maipulatig SOAP header iformatio. WebLogic Server provides a framework for automatically covertig data betwee XML ad Java. The Web services ca therefore be desiged oly i Java without havig to process XML directly. Support for the simple data types defied i the SOAP specificatio are built i. Complex or user-defied data types ca be coverted by usig optioal serializer/deserializer objects. The WebLogic Autotyper utility ca be used to geerate a serializer ad a deserializer that will hadle the coversio at rutime. As iput, WebLogic Autotyper will accept a XML or a Java represetatio of the types ad will geerate the equivalet Java or XML represetatio alog with the serializer/deserializer. The hadlers ad the serializers ad deserializers make use of a iovative ew XML parser, called a pull parser. A pull parser, sometimes kow as a tokeizig parser, eables a developer to extract a subset of the XML documet i a very high performat maer. WebLogic Workshop WebLogic Workshop is a IDE that is targeted at the developer who prefers a GUI-based approach to applicatio developmet. Borrowig from the Visual Basic paradigm WebLogic Workshop allows developers to defie a Web service ad its iteractio with system resources, usig visual metaphors. The developer ca the drop dow i the code view ad defie the procedural logic for the Web service. WebLogic Workshop developers work withi a higher level of programmig abstractio that shields them from the complexities of J2EE ad object-orieted programmig. This exposes the power of Web services, J2EE, ad WebLogic Server to a ew class of developer. Web Services Stadards WebLogic Server supports the most commo Web services stadards, otably, SOAP, XML schema, WSDL, ad UDDI. I additio, support for coversatioal Web services is icluded. Cape Clear Former IONA employees started Cape Clear i Dubli i 1999 to focus o XML. Iitially, they worked o the itegratio of XML ad CORBA ad the later switched to Web services. The compay's two products are CapeCoect, a Web services platform ad itegratio; ad CapeStudio, a Web service developmet toolset. The CapeCoect toolkit for the Widows platform geerates Web services cliets that iteroperate with Java classes ad CORBA objects o the server side. Amog other thigs, CapeCoect coects Web services cliets o Widows ad other platforms with Java ad CORBA servers o Widows ad other platforms. Curret Situatio Cape Clear agrees with the adoptio of core stadards but believes that ebxml adoptio will take up to a year loger tha ebxml vedors are predictig. The Web services commuity is much wider tha the CORBA or J2EE commuities, ad ebxml is possibly too complex for a lot of Web services users. Right ow, most users are cocetratig o gettig the essetials right. Cape Page 194

196 Clear believes that oly whe there is a critical mass of commercial experiece aroud these core stadards will a lot of people start movig up to more complex stadards. Next Steps Security, trasactios, routig, reliable messagig, ad process flow are all importat, as are automated data trasformatio, rules processig, asychroous messagig, ad systems maagemet. Cape Clear suggests the followig order of importace ad order for roll-out ad/or adoptio: Security: This is essetial, ad everybody wats this ow. Reliable messagig/asychroous messagig: This is essetial for solvig real-world problems. Systems maagemet: So far, this topic has received far too little discussio, which is a sig of the immaturity of the techology, despite the iterest i it. Routig: Today, early all developmet is fixed, peer-to-peer, but asychroous messagig will require routig. However, a drawback of the proposed SOAP routig specificatio is that it requires kowig all the routig hops i advace of sedig the message, which is sort of like the old UUCP mail where you had to kow the physical layout of the etwork to sed a message. Automated data trasformatio: XSLT provides a great way of mappig other XML dialects ito SOAP/WSDL, which will become more ad more importat, especially i idustries with a lot of XML adoptio, such as fiace; as well as a way of doig object trasformatios WSDL WSDL. Trasactios: This area is ot as importat as some people thik, as most of the Webbased applicatios will ot expose trasactios, which will lie ecapsulated uder a more abstract Web service iterface. It's also difficult to see people itegratig trasactios with a asychroous model, ad there is ot eough iteroperability betwee trasactio egies to make it work portably, particularly give that ot all vedors support ested trasactios. Rules processig: The Web services platform is a atural place to add platform-eutral busiess logic; Cape Clear believes that the easiest way to do this is via a rules-based approach, whereby busiess logic will be executed based o the cotet of icomig messages. Rules processig also ties ito routig for cotet-based addressig or message rewritig. Process flow: This area will remai very importat to some people, possibly icreasig i importace i terms of Web service assembly. However, that will deped o a large umber of available Web services that have bee desiged for easy assembly ad sufficietly advaced tools to make it easy to assemble them. If it's difficult to do, it will alieate both the people without the skill ad patiece to use the tools as well as the skilled users who will just code the applicatios by had. Hewlett-Packard Hewlett-Packard (HP) bega early i the Web services market with its espeak iitiative. Although espeak icorporated may, if ot all, of the core cocepts ad techologies i Web services, espeak bega before the emergece of the core Web services stadards; espeak was based o proprietary formats that did ot coform to SOAP, WSDL, ad UDDI. HP's ewer products do, however, ad the compay is brigig its experiece gaied with espeak to bear o stadards iitiatives as well as products. HP is very active at W3C, JCP, ad OASIS. espeak was a early implemetatio of Web services cocepts Page 195

197 Products HP markets several stadards-based Web services products, icludig the oes described i Table 8-4. Next Steps Although simple Web services ca provide sigificat beefit for may busiesses, complex Web services capabilities are required for true B2B collaboratio ad hece require complex Web services, which typically ivolves XML documet exchage or a series of documet exchages. Thus busiesses will require a flexible ad customizable platform that eables them to plug i emergig stadards-based solutios for supportig log-duratio trasactios, message ad seder autheticatio, asychroous messagig, support for multiple busiess protocols, maageability, ad the ability to combie services ad applicatios ito busiess processes easily. Such a solutio also eeds to support multiple platforms ad to deliver true iteroperability betwee programmig eviromets. HP's product directio ecompasses all of these areas. For example, Security: Budled with the HP Web Services Platform is a XML Digital Sigature pack that eables you to esure message itegrity ad message autheticatio. The Digital Sigature pack describes the XML sytax for represetig digital sigatures ad provides the flexibility to sig specific portios of a XML documet. SSL ca be used to esure seder autheticatio. Asychroous messagig ad support for multiple protocols: I additio to SOAP- RPC support, the HP Web Services Platform will support virtually ay XML protocol ad therefore will participate i multiple tradig eviromets. Icluded i the HP Web Services Platform architecture is a listeer framework for receivig both sychroous ad asychroous messages over a variety of trasport protocols ad a pipelie for preprocessig ad routig XML documets. This framework eables the HP Web Services Platform to receive, process, ad retur XML documets based o requiremets detailed i such busiess protocols as RosettaNet, ebxml, or BizTalk. Maagemet: Via a itegratio with Hewlett-Parkard's market-leadig maagemet platform, OpeView, busiesses will be able to exted their maagemet view ad cotrol to iclude Web services. Busiess process maagemet: HP will offer itegratio with Process Maager ad Process Maager, Iteractive Editio, two busiess process maagemet ad graphical workflow platforms. Itegratig the HP Web Services Platform ito these or similar busiess process maagemet platforms eables both busiess ad techical resources to reuse busiess logic applicatios, services, processes to create or to modify busiess processes. Platform-eutral iteroperability: HP is dedicated to providig middleware products that are platform-ad applicatio-server eutral. HP's Web services compoets will be able to operate withi ay J2EE-compliat applicatio server, icludig HP-AS, WebLogic, ad WebSphere. I additio, sigificat testig by HP will esure true iteroperability betwee Java- ad.net-deployed services. Complex Web services capabilities are required Table 8-4. Hewlett-Packard's Web Services Products Product Descriptio HP Web This is a complete, stadards -based architecture for developig, itegratig, Services deployig, ad cosumig Web services. This product supports today's key Platform Web services stadards such as WSDL, SOAP, ad UDDI ad icludes the ability to easily plug i future busiess ad techology stadards. The platform has a umber of key compoets, icludig HP-SOAP server, HP Service Page 196

198 Table 8-4. Hewlett-Packard's Web Services Products Product Descriptio Composer, HP Registry Composer, ad trail map tutorials. HP-SOAP provides a stadards-based commuicatios platform for sedig, receivig, ad processig SOAP-based messages. HP-SOAP delivers a pipelie-processig model based o Cocoo2, a Apache ope source framework, ad icludes a listeer framework (HTTP, HTTPS, SMTP), evelope processig, ad routig capabilities. HP- SOAP operates withi a J2EE applicatio framework i order to take advatage of the performace, reliability, ad scalability aspects of J2EE. HP Service Composer supports the full life cycle of Web services developmet ad eables you to create, view, ad modify ew ad existig WSDL defiitios; create, view, ad modify XML schema defiitios; geerate Web services defiitios from existig Java code bases; ad geerate Web services cliet proxies, server skeletos, ad deploymet descriptors. HP Registry Composer is a graphical tool that simplifies the process of registerig ad searchig for Web services i either public or private UDDI registries. HP Registry Composer supports the latest UDDI specificatios, as well as UDDI4J, the prevailig Java API for accessig UDDI registries. HP Services Registry HP Services Trasactios IBM Web This is a implemetatio of the UDDI specificatio that eables you to set up private registries with cotrolled access to available Web services. Similar to public UDDI registries, HP Web Services Registry provides both Web-based ad programmatic iterfaces for registerig ad searchig for available busiesses ad services. The programmatic iterface is based o UDDI4J, a Java API for accessig UDDI registries. Also budled with HP Web Services Registry is the HP Registry Composer tool. Web This product provides ed-to-ed trasactioal itegrity for Web services. Based o BTP (see Chapter 7), HP Web Services Trasactios eables reliable trasactioig betwee Web services outside the firewall ad betwee disparate platforms, such as betwee Java-ad.NET-deployed Web services. Supported are log-duratio trasactios, ested trasactios, ad two-phase commit capability. The product icludes class libraries for migratig ew or existig Web services to trasactio-capable Web services. Whe IBM decided to get ivolved i Web services by joiig Microsoft as authors ad propoets of the SOAP specificatio, it was big ews ad put the iitiative o the map i a way that IONA's earlier support could ot. Ay sigificat collaboratio betwee Microsoft ad IBM carries a lot of weight. At the time, Microsoft ad IBM also had bee workig o the proposal that became UDDI ad later collaborated to produce WSDL. IBM is also a major cotributor to ebxml ad sposors a major Web services developer site. IBM's edorsemet put SOAP o the map Page 197

199 IBM products either already support Web services or are rapidly movig to support them, startig with the core techologies: SOAP, WSDL, ad UDDI. Product support is movig quickly Basic Iformatio I respose to questio 1 o the basic questioaire set to all vedors, IBM made the followig commets: IBM would agree with this statemet; however, we would like to modify the list i two ways. First, we would like to add XML Ecryptio ad Digital Sigature; secod, we would like to emphasize that the most importat of these three stadards is WSDL. The descriptio is what creates the iteroperability. We are i but the first step of a rapidly emergig foudatio for busiess SOAP ad UDDI are where we start. The future is bright for additioal protocols ad publicatio techologies. Certaily SOAP is critical to Web services, ad we do't see this role dimiishig. SOAP is the first, best-defied, ad tested WSDL bidig available. It is the protocol of choice for doig cross-eterprise B2B commuicatio. However, it will ot be the oly WSDL bidig i use iside or outside the eterprise. We see potetial for other bidigs, which are ot SOAPbased, to emerge i the future ad be very importat as well. IBM is still fully behid UDDI both i its role as the public busiess ad service registry ad as a private, itraeterprise registry. IBM also sees the value of additioal publicatio methodologies such as WS-Ispectio. IBM sees Web services i the future as beig built aroud WSDL with support for SOAP, UDDI, XML Ecryptio, Digital Sigature, ad other core Web services stadards yet to be iveted. Ad, yes, IBM recogizes that WSDL itself is a first step ad requires evolutio to meet the demads of e-busiess. This evolutio is already uder way for security ad XML Ecryptio ad Digital Sigature. IBM looks forward to cotiuig to help guide that evolutio with the W3C ad OASIS. IBM believes that ebxml is comig from the busiess side ad offers a holistic solutio. Web services is comig bottom-up ad offers icremetal parts that are easier ad cheaper to adopt. IBM believes there will be covergece of the two stacks with the busiess-level cocers of ebxml aroud busiess agreemets ad busiess process iteractio, layered o top of the Web services base of SOAP, WSDL, UDDI, Security, ad Workflow. AlphaWorks Iformatio IBM hosts a developer Web site called AlphaWorks ( ad offers a variety of techology previews. The techologies available from IBM's AlphaWorks Web site are ot official IBM products. However, the Web site offers IBM customers ad developers a view of the techologies, such as SOAP, WSDL, ad UDDI, that IBM believes may prove to be importat i the future. Techology previews are available at AlphaWorks Page 198

200 The AlphaWorks site allows customers ad developers to commet o these techologies ad improve them durig this Alpha stage. I the case of Web services, IBM has previewed key Web services techologies o AlphaWorks ad has show how these techologies could be used via techology demostratios. The available AlphaWorks techologies iclude the oes that are show i Table 8-5. Table 8-5. IBM's AlphaWorks Techologies Techology Descriptio Web Services ToolKit A software developmet kit that icludes a lightweight rutime (WSTK) eviromet, a demo, ad examples to aid i desigig ad executig Web services applicatios that ca use SOAP, UDDI, ad WSDL to fid oe aother automatically ad collaborate i busiess trasactios without additioal programmig or huma itervetio. SOAPCoect, which is a LotusScript library ad Java aget, is icluded; it facilitates cosumig Web services from a Domio applicatio. Web Services Hostig A set of techologies that eables hostig support for Web Techology services withi a WSTK eviromet. Web Services A tool that provides a stadard applicatio programmig Ivocatio Framework iterface (API) for ivokig services described i WSDL, o matter how or where the services are provided. Web Services Gateway A middleware compoet that provides a itermediary framework betwee Iteret ad itraet eviromets durig Web services ivocatios. It offers a gateway fuctio at the protocol level from SOAP to other protocols. Busiess Explorer for A XML-based UDDI explorig egie that provides stadard Web Services iterfaces for efficietly searchig busiess ad service iformatio i UDDI registries. Web Services Process A tool that allows you to compose Web services ad to iclude Maagemet Toolkit them i a busiess process to achieve a defied busiess goal. It is the Web services eablig for MQ Workflow. Lotus Web Services This techology is a blueprit, icludig demostratio, samples, Eablemet Kit ad source code, for ehacig Lotus products with Web (WSEK) services. XML Registry/Repository (XRR) Products This product is a database for storig WSDL ad other XML artifacts. Table 8-6 describes the official IBM products with Web services implemetatios. WebSphere ad DB2 support Web services Table 8-6. IBM's Official Products Product Descriptio WebSphere This flagship applicatio server offerig is aimed at professioal Java Applicatio Server 4.0 techology developers who require J2EE ad Web services fuctioality. It is Web services eabled with support for XML, SOAP, WSDL, ad UDDI. (More iformatio is available at WebSphere A easy-to-use, itegrated developmet eviromet for buildig, testig, ad Page 199

201 Table 8-6. IBM's Official Products Product Descriptio Studio deployig J2EE applicatios. This applicatio developmet eviromet, equipped Applicatio to support Web services developmet, icludes Developer A powerful Java developmet eviromet with wizards, cotet assist, debugger, refactorig, scrapbook, uit test eviromet, ad pluggable JRE Complete EJB developmet ad test eviromet with EJB v1.1 support Web services itegratio to create, build, test, publish, ad discover Web service-based applicatios, supportig UDDI, SOAP, WSDL, ad XML XML developmet eviromet to geerate DTDs, schemas, XML documets, ad XSL style sheets Wizards for servlet ad JSP creatio Relatioal Schema Ceter for advaced database applicatio support Profilig ad tracig tools for optimizig applicatio performace Collaborative team developmet support WebSphere UDDI Registry A UDDI-compliat registry for Web services i a private itraet eviromet. With the IBM WebSphere UDDI Registry, Web services developers ca publish ad test their iteral e-busiess applicatios i a secure, private eviromet. The product supports multiple users i various departmet or compaywide scearios ad also supports the SOAP-based APIs defied by either the UDDI v1 or v2 specificatios ad provides persistece for published etities through a relatioal database. A Webbased graphical user iterface supports publishig ad queryig of busiesses, services, ad other UDDI-compliat etities without programmig (available from the WebSphere Developer Domai at DB2 7.2 Eables Web services applicatios to access data stored i DB2 as a XML XML structured documet, providig busiesses with greater ease ad efficiecy Exteder i developig ew dyamic e-busiess applicatios usig XML iterfaces oly. Three kids of Web services operatios are supported: retrieve ad store XML, SQL-based, query ad update, ad stored procedure ivocatios. Web Services Object Rutime Framework Provides Web services access to SQL queries, stored procedures, ad XMLExteder fuctios, ad eables XML Exteder trasform capabilities ad DB2/XML to/from Web services (DADX). A DADX documet specifies a Web (WORF) service usig a set of operatios defied by XML Exteder DAD documets or SQL statemets. Web services specified i a DADX file are called DADX Web services. The framework provides the followig features: Resource-based deploymet ad ivocatio Automatic service redeploymet, at developmet time, whe defiig resource chages HTTP GET ad POST bidigs, i additio to SOAP Automatic WSDL ad schema geeratio, icludig support for UDDI best practices Automatic documetatio ad test page geeratio WORF is dowloadable from the IBM XML Exteder Web site ad is shipped with WebSphere Studio Applicatio Developer ad WebSphere Studio Site Developer (WSSD) Techology Preview. Next Steps Page 200

202 I additio to advacig core techologies for Web services, IBM sees sigificat value i the area of eablig services, or those that a applicatio developer, service developer, or busiess process developer would wat to use. The Web Services ToolKit cotais a few of these: otificatio, meterig ad accoutig, persistece, ad idetificatio. The Web Services Hostig Techology illustrates how to use these eablig services i a solutio for service provisioig. IBM hopes to see the WSDLs for a set of useful servic es stadardized i the future to promote iteroperability, availability, profitability, ad reusability of Web services. As far as the future goes, IBM believes security is the most critical fuctioality eeded for Web services. Digital Sigature ad XML Ecryptio are the ext two techologies to be added to the core. Additioal security techology is beig worked o to create a ed-to-ed security solutio for Web services. Busiess process choreography would be IBM's ext step, ad it already has a proposal i this space (WSFL see Chapter 7); however, there is o idustrywide stadard as yet. Alog with choreography comes the eed to address quality-of-service aspects, icludig reliability, agreemets, trasactios, ad maagemet. IBM believes that the core stadards list will expad to iclude ot oly security, but also those techologies created ad adopted for choreography, quality of service, ad reliable messagig as these are the poits where iteroperability is crucial. There may also be a set of techologies for Web services, which are just as importat but ot part of the core, specifically maagemet provisioig ad parter agreemets. Of course, IBM is also makig progress with these techologies for Web services simultaeously. IBM views Web services as the critical ext step for middleware. As such, its products are rapidly movig to (or already do) support Web services. Iitial support has bee for WSDL for describig services, SOAP for accessig services, ad UDDI for discoverig services. IBM's focus for Web services is that it is a stadards -based, uified framework for both B2B ad Eterprise Applicatio Itegratio (EAI). WSDL serves the most critical role for IBM, as it's the ligua fraca for describig services. I fact, IBM defies Web services as "software compoets described via WSDL [that] are capable of beig accessed via stadard etwork protocols, such as SOAP over HTTP." From the busiess poit of view, IBM sees Web services as allowig oe to lower the cost of iteractio to almost othig betwee two applicatios or parties as the applicatio describes its iterfaces for ayoe to coect with. From a base techology poit of view, IBM feels that WSDL eables the whole area of service-orieted architectures ad that SOAP/HTTP is critical whe such models are used for B2B scearios. IONA IONA joied Microsoft i support of SOAP i early 2000, implemetig early versios of the specificatio ad demostratig iteroperability betwee SOAP ad CORBA. IONA also has bee very active i support of ebxml ad provides a implemetatio of ebxml i additio to comprehesive support for Web services throughout its product lie, which icludes the Orbix Ed 2 Aywhere (E2A) platforms. IONA cotiues to focus o iteroperability, Web services creatio, security, ad orchestratio. IONA demostrated iteroperability i early 2000 Products Orbix E2A Web Services Itegratio Platform Page 201

203 This platform uses Web services stadards, icludig SOAP, WSDL, ad UDDI, to simplify busiess process automatio ad iformatio exchage for customers, tradig parters, ad iteral departmets. The Orbix E2A Web Services Itegratio Platform cosists of the three editios described i Table 8-7. The etire product lie supports Web services Orbix E2A Applicatio Server Platform The platform is the most widely deployed developmet platform for the most demadig distributed applicatios i the world, combiig the scalability of CORBA ad the productivity of J2EE. The Applicatio Server Platform supports all of the major compoet architectures ad Web services ad cosists of the three editios described i Table 8-7. Next Steps Web services are very appropriately used for wrappig busiess process flows. Everyoe asks what they should use Web services for today, ad the right aswer is to help automate busiess process iteractios. So establishig a realistic, simple, ad appropriate busiess process flow stadard is very importat. Microsoft ad IBM appear to be far apart o this critical techology, which may impede progress. Focus should be o security ad process flow I the Web services world, a busiess process flow is the equivalet of a busiess trasactio, ad therefore Web services trasactios should focus o iteractios with process flows rather tha o iteractios with data resource maagers. It should be sufficiet to otify a busiess process flow of a cacellatio or a chage i the evet of failure or iability to successfully coordiate the executio of multiple busiess process flows or of multiple steps withi a sigle flow. Therefore oce a busiess process flow specificatio is adopted, a trasactio coordiatio specificatio that fits well with it will be eeded. Table 8-7. The IONA E2A Platforms Product Descriptio Web Services Itegratio Platform Collaborate A sigle platform for total busiess itegratio provides a comprehesive Editio set of itegratio solutios for process collaboratio both iside ad outside the eterprise, icludig Web services ad ebxml. Parter Editio This product provides a low-cost, easy-to-deploy Web services coector that eables customers to iteract seamlessly with each other ad with tradig parters that have deployed the Collaborate Editio or other Web services itegratio techologies. XMLBus Editio A comprehesive visual eviromet for buildig, deployig, itegratig, ad maagig Web services, icludig Web services itegratio broker optios. Applicatio Server Platform Eterprise This product delivers a complete eterprise deploymet platform for Editio J2EE, CORBA, Web services, maiframe eviromets, ad Microsoft's.NET. Page 202

204 Table 8-7. The IONA E2A Platforms Product Descriptio Stadard This product combies the scalability ad robustess of CORBA, the Editio developer productivity of J2EE, ad the ope access of Web services. J2EE This product combies a extremely reliable ad scalable, fully certified Techology J2EE applicatio server with itegrated Web Services support. Editio Beyod these fuctioal areas, the qualities of security ad reliable messagig are critical ad should be settled as soo as possible. Work o these areas ca progress i parallel with the work o process flow ad trasactio coordiatio, because both security ad trasactios are ecessary for successful process-flow deploymet. Security, trasactios, ad reliable messagig are also importat Strategy E2A is drive by two simple but profoud ideas. First, ay applicatio, whether firmly etreched or ewly developed, should be able to iteract with ay other relevat applicatio, o matter where it resides or how it was developed. Secod, applicatio developmet ad applicatio itegratio should ot be treated as separate processes. I a fully coected world, they must be part of the same process. E2A moves far beyod ed-to-ed the idea that busiess processes would progress uimpeded betwee iteral applicatios ad exteral busiess parters, regardless of platform, laguage, database, applicatio, trasport mechaism or aythig else. For most orgaizatios, ed-to-ed meat poit-to-poit, with a lot of poits joied by too may hard-wired, iflexible coectios. Each coectio took too log to build, cost too much to maitai, ad was too iflexible to allow for busiess process chages. I the ed, it did't accout for how quickly the world chages. Edto-ed has failed to deliver o the promise of total busiess itegratio. Web services stadards represet a breakthrough that has markedly chaged this equatio. Web services stadards are makig the process of total busiess itegratio far more cost-effective ad far more flexible. May vedors have take tetative iitial steps toward addressig the potetial of Web services. IONA is goig much further, combiig Web services stadards with its extesive itegratio techology. IONA delivers a solutio, Orbix E2A, that revolutioizes eterprise itegratio by leveragig Web services at its core. Microsoft Much was covered i the.net sectio, ad.net is broader tha Web services. Microsoft's approach is to make Web services a fudametal platform techology used by multiple products. (Microsoft products are built assumig the existece of Web services, ad Microsoft is i the middle of this process; some products have bee adapted, ad some have ot.) Like may previous Microsoft iitiatives,.net has see strog uptake, with millios of developers ad thousads of customers jumpig o board. Web services are fudametal Page 203

205 Products The curret products that provide implemetatios of the core Web services techologies SOAP, WSDL, ad UDDI are.net, the.net Framework, ad Visual Studio.NET, as described i Table 8-8. Web services products are part of.net Next Steps The Global XML Web Services Architecture (GXA; specificatios are covered i Chapter 7) is the framework for the future of XML Web services. SOAP, WSDL, ad UDDI costitute a set of baselie specificatios for applicatio itegratio ad aggregatio. From these baselie specificatios, compaies are buildig real solutios ad gettig real value. But as they develop XML Web services, compaies' solutios have become more complex ad the eed for stadards beyod this baselie are readily apparet. The baselie specificatios leave a gap that requires Web services developers to implemet higher-level fuctioality, such as security, routig, reliable messagig, ad trasactios i proprietary ad ofte oiteroperable ways. Microsoft's GXA proposal At the W3C Workshop o Web Services i April 2001, Microsoft ad IBM preseted a architectural sketch for the evolutio of Web services that builds o the baselie specificatios. This sketch (available at was the foreruer of Microsoft's GXA, which provides priciples, specificatios, ad guidelies for advacig the protocols of today's XML Web services stadards to address more complex ad sophisticated tasks i stadard ways, allowig XML Web services to cotiue to meet customer eeds as the fabric of applicatio iteretworkig. Table 8-8. Microsoft's Curret Web Services Products Product Descriptio.NET Microsoft.NET is a platform for buildig, ruig, ad experiecig the ext geeratio of distributed applicatios. It spas cliets, servers ad services ad cosists of: A programmig model that eables developers to build XML Web services ad applicatios A set of XML Web services, such as Microsoft.NET My Services that helps developers deliver a simple ad itegrated user experiece A set of servers, icludig Widows 2000, SQL Server, ad BizTalk Server, that itegrates, rus, operates, ad maages XML Web services ad applicatios Cliet software, such as Widows XP ad Widows CE, that helps developers deliver a deep ad compellig user experiece across a family of devices Tools, such as Visual Studio.NET, to develop XML Web services ad applicatios for Widows ad the Web for a rich ad compellig user experiece Page 204

206 Table 8-8. Microsoft's Curret Web Services Products Product Descriptio.NET This Microsoft framework is a platform for buildig, deployig, ad ruig Framework Web services ad applicatios. It provides a highly productive, stadardsbased, multilaguage eviromet for itegratig existig ivestmets with ext-geeratio applicatios ad services ad the agility to solve the challeges of deploymet ad operatio of Iteret-scale applicatios. The.NET Framework cosists of three mai parts: (1) the commo laguage rutime, (2) a hierarchical set of uified class libraries, ad (3) a compoetized versio of Active Server Pages called ASP.NET. Visual Studio.NET Future View This product eables developers to write robust ad depedable software quickly ad delivers o the promise to address the fudametal challeges facig developers ad their orgaizatios today. A powerful, highly productive, ad extesible programmig eviromet, Visual Studio.NET ulocks the potetial for applicatio developmet. It provides the tools ad techologies required to build applicatios that will power today's orgaizatios ad drive the ext geeratio of XML Web service-based software. The demads of today's dyamic busiess eviromet have pushed the limits of the curret computig paradigm. Remaiig competitive ad imble requires that iformatio ad processes be more coected ad tailored to people ad systems, both iside ad outside the orgaizatio. The most pressig techical challege facig compaies today lies i the itegratio of busiess applicatios ad electroic processes so that they work well to meet busiess eeds: streamlied operatios, more accurate ad timely iformatio, ad better-served customers ad busiess parters. The global adoptio of the Iteret provides us with the etwork that we eed to coect our systems, both iside idividual busiesses ad amog busiesses, their suppliers, ad their customers. The Iteret has the potetial to act as a uiversal, iexpesive etwork that ca coect the applicatios withi the busiess process ad i people's everyday lives. Merely havig the etwork i place is ot sufficiet, however, if the software o which we build our busiesses does ot utilize the etwork's power ad potetial. Although the etwork is available, the challege of itegratio remais. Today's stadaloe systems, applicatios, ad Web sites create "islads" of data ad fuctioality typically locked iside cetralized databases. Itegratig these islads of iformatio with existig systems, as well as with those of parters ad customers, has traditioally bee difficult, expesive, ad iflexible. I respose to these challeges, the computig idustry is covergig o a ew model for buildig software to make this itegrated world of applicatios for busiesses ad idividuals much more achievable. The model eables a stadard way to coect applicatios ad exchage iformatio usig the Iteret. This ew, Iteret-based itegratio methodology, called XML Web services, eables applicatios, machies, ad busiess processes to work together i ways ever previously possible. XML Web services, i cojuctio with the Iteret, provide the foudatio to overcome these challeges. The baselie of XML Web services is i place, with wide vedor adoptio ad a high level of iteroperability. The challege we ow face is buildig out the ehaced capabilities of XML Web services demaded by busiess i a way that keeps XML Web services iteroperable ad ope. Microsoft's Global XML Web Services architecture provides the visio for that evolutio. Page 205

207 Oracle Oracle is primarily a database vedor but is also eterig ad competig i the applicatio server market ad will be offerig Web service products based o its applicatio server ad its database. This view revives the old debate betwee cliet/server ad three-tier database access; oetheless, may developers will fid directly coectig Web services to the database to be a good fit for simple, data-cetric applicatios. Oracle was amog several vedors that edorsed SOAP ad the other specificatios aroud the same time Su Microsystems did. Oracle offers predefied Web services types to make it easier to build ad produce high-performace Web services applicatios. A fudametal applicatio of Web services is to provide a stadard iterface to database maagemet systems, ad Oracle provides this. Both the database ad the applicatio server support Web services Basic Iformatio Oracle9i Applicatio Server (AS) Web Services, Oracle's J2EE-based Web services offerig, has five distiguishig features, as show ad described i Table 8-9. Next Steps These followig techologies will play importat roles: reliable messagig, security, process flow, ad trasactios. I the foreseeable future, Oracle9iAS Web Services plas to fully support ad implemet the fial specificatios of the followig JSRs (see also J2EE Applicatio Servers sectio) or their replacemets: JSR 109: Implemetig Eterprise Web Services JSR 101: JAX RPC Additioal techologies are adopted through JSRs Table 8-9. Oracle's J2EE-Based Web Services Service Descriptio Service Oracle9iAS Web Services are implemeted as ay of the followig: Implemetatio Java classes, both stateless ad stateful Eterprise JavaBeas (EJBs), curretly stateless sessio beas Message-drive beas (MDBs) PL/SQL stored procedures or fuctios Service Packagig Oracle9iAS Web Services are packaged as stadard J2EE Eterprise Archive (EAR) files, icludig the service implemetatio ad a servlet adapter correspodig to the specific implemetatio type. For scalability, Oracle9iAS supplies the followig five servlet classes, oe for each supported implemetatio type: Java class (stateless) the object implemetig the Web service is ay arbitrary Java class. Java class (stateful) the object implemetig the Web service is ay Page 206

208 Table 8-9. Oracle's J2EE-Based Web Services Service Descriptio arbitrary Java class; a servlet HttpSessio maitais the object state betwee requests from the same cliet. EJBs the object implemetig the Web service is a stateless sessio EJB; the Web service is cosidered to be stateless. PL/SQL stored procedure or fuctio the object implemetig the Web service is a Java class that accesses the PL/SQL stored procedure or fuctio; the Web service is cosidered to be stateless. The Oracle9iAS Web Services developmet commads geerate the Java access class. MDB the object implemetig the Web service is a message-drive bea; the Web service is cosidered to be stateless. Publishig This service provides automatic geeratio of a WSDL file ad WSDLcompliat stubs. Oracle Eterprise Maager allows you to register the specific Web service ad to publish its WSDL to the UDDI registry ad to discover published Web services. UDDI Registry This service is implemeted o top of Oracle9i Database ad uses the Streamig followig three stadard classificatio taxoomies: North America Idustry Classificatio System (NAICS) Uiversal Stadard Products ad Services Codes (UNSPSC) ISO 3166 Geographic Taxoomy (ISO 3166) HTML/XML This service allows HTML/XML streams via HTTP for Access to a XML ews feed through a static URL Programmatic access to a dyamic stream accessed through a HTML form EJB methods for accessig ad processig the XML or HTML streams JSR 110: JWSDL JSR 67: JAX M JSR 93: JAX R JSR 151: J2EE v1.4 JSR 153: EJB v2.1 Su Microsystems Su Microsystems joied Web services iitiatives later tha IBM ad IONA ad was iitially more focused o ebxml. Su participated i the W3C forum o XML Protocols i Jue 2000 ad edorsed SOAP soo afterward, which made idustry support for SOAP early uaimous. The compay the supported several Web services-related submissios to W3C, bega work o its SuONE architecture, ad remais very active at both ebxml ad W3C. Su Microsystems is also leadig may of the Java Commuity Process iitiatives for Web services. Su Microsystems's edorsemet removed fial doubts about SOAP Page 207

209 SuONE The Su Microsystems's Ope Network Eviromet (SuONE) provides a framework for all the elemets ecessary for defiig, buildig, deployig, ad operatig sophisticated busiess services, icludig, but ot limited to, Web services. SuONE is a architecture for Web services ad more SuONE addresses the etire rage of etwork-drive services ad services o demad, regardless of which etworks the service uses phoe etwork, Iteret, wireless either aloe or i combiatio. The SuONE architecture is stadards-based, affordig customers iteroperability with other vedors' products that support the same stadards. SuONE products are based o the Java programmig laguages techology. The Java Commuity Process is ope ad based o stadards. It therefore egeders a competitive, compatible market where multiple vedors vie to produce the best implemetatios. History clearly shows that competitive markets produce better products. The key elemet is that choice creates competitio ad that a competitive, compatible market gives vedors the icetive to build superior products. Java ad stadards-based solutios promote choice I order to build complex ad robust busiess applicatios, you must have all of the elemets i the SuONE architecture: service creatio ad assembly, service delivery, applicatios ad Web services, a service cotaier, service itegratio, idetity ad policy, ad a foudatio platform o which to ru it all. SuONE supports complex ad robust applicatios For service creatio ad assembly, Forte ad iplaet tools are available. For service delivery, the iplaet portal server (Collaboratio, Mobile Access, Persoalized Kowledge, Secure Remote Acess Packs) is popular. For ready-to-use applicatios ad Web services, various products from the iplaet e- commerce (BillerXpert, BuyerXpert, MarketMaker, SellerXpert, Trustbase) ad commuicatio portpolios (Caledar, Messagig, Mail) ca be used. For the cotaier, iplaet also has a Web server ad a idustrial-stregth applicatio server. For service itegratio, a iplaet itegratio server ca be used to commucate with back-ed systems. For idetity ad policy, there is the iplaet Certficatio Maagemet System, Directory Server, Proxy Server, Policy Server, ad Liberty Alliace Project. All these elemets ru over the prove, scalable, ad reliable Solaris OS o a SPARC platform. Future Directio To date, much of the discussio at Su Microsystems has focused o the low-level protocols ad techology for implemetig Web services. But, over the ext two to three years, the lower level will fade ito the backgroud, ad the upper level will take its rightful promiece. The upper level is focused o busiess processes ad solutios that use Web services to provide icreased value to the stakeholders ivolved i those systems. What customers are icreasigly ad Page 208

210 uequivocally sayig is that they are iterested i solutios that help them to provide value to their stakeholders while achievig a retur o their techology ivestmets. Cosequetly, the emphasis will icreasigly be o iitiatives that provide these kids of busiess solutios. Two kids of itiatives directly address busiess solutios of iterest to customers: explicit busiess implemetatio techology ad formal frameworks for busiess techology solutios. A example of the former is the OASIS Uiversal Busiess Laguage (UBL) effort to defie a commo XML busiess documet library (see UBL will provide a set of XML buildig blocks that will eable tradig parters to uambiguously idetify ad exchage busiess documets i specific cotexts. A example of the latter is the SuONE architecture ad products. Systiet Systiet, formerly Idoox, is a software compay that was fouded by Roma Staek, formerly of NetBeas. Systiet was a early adopter of Web services ad has bee very active at W3C, JCP, UDDI, ad o OASIS committees. Systiet focuses etirely o Web services ad has o other product lie. Adoptio of Core Techologies There's o doubt that SOAP ad WSDL will be widely accepted ad adopted. UDDI is takig a little loger to garer support but will evetually succeed. Systiet does ot see very much iterest i ebxml but expects SAML ad XKMS to gai adoptio. Curret Products The Systiet Web Applicatios ad Services Platform (WASP) product lie supports SOAP, WSDL, ad UDDI. Table 8-10 describes the four families of the Systiet product lie. Next Steps Security is the most critical ext step. Security requires iteroperability at the applicatio level, so stadards are ecessary. SAML is key ad is likely to experiece rapid adoptio. Systiet is already implemetig support for SAML i WASP Security. It also eeds a ope, stadardized, federated idetity system for uiversal sigle sig-o probably that will be Liberty. Reliable messagig is very importat, but it does't require stadardizatio because it ca be implemeted at the trasport protocol level. Systiet supports reliable messagig today by usig a reliable trasport protocol: for example, JMS or a reliable etwork provider such as Grad Cetral or Slam Duk. It might be useful to have a stadard mechaism or laguage to express reliability requiremets so that cosumers of the service could discover these requiremets from a Web service descriptio. But it's ot a critical eed at this time; or has the idustry reached cosesus o ay potetial stadard. IBM's HTTPR fell pretty flat. (Besides, a reliability stadard should't be depedet o the trasport protocol layer; we already have that.) Routig is pretty importat ad will become more so as people try to do more iterestig applicatios with Web services. Routig ad itermediaries will be used to implemet meterig, billig, etitlemet, auditig, reliability, security, trascodig, filterig, optimizatio, ad so o. Stadardizatio is't makig much progress i this area, however. Table The Systiet WASP Products Product Descriptio WASP Provides a itegrated Web services developmet eviromet implemeted Developer as a plug-i to popular Java IDEs. The plug-i adds tools, wizards, ad Page 209

211 Table The Systiet WASP Products Product Descriptio geerators to make Web services developmet a atural part of applicatio developmet ad is available for Forte, Jbuilder, ad Eclipse. The tools ca geerate WSDL from Java ad Java from WSDL. They fully automate the developmet of SOAP iterfaces ad of deploymet packages. Developers ca deploy Web services from withi their IDE, to either a local or a remote server. A itegrated admiistratio cosole rus withi the IDE. The tools iclude a distributed debugger ad a SOAP message moitor. The tools ca also query ad publish to UDDI. WASP Provides Java ad C++ rutime Web services cotaiers that ca be Server deployed i a variety of Web servers ad applicatio servers (Apache, Tomcat, WebLogic, WebSphere, iplaet, Orio, JBoss, ad so o). The framework provides umerous typed iterceptio poits that eable easy customizatio to support multiple trasport protocols HTTPS, SMTP, JMS, ad so o as well as custom message trascodig, evelope processig, header processig, ecodig, ad serializatio. Both cotaiers support a advaced security framework that provides ed-to-ed security protectio. It supports multiple autheticatio mechaisms, trusted domais, ad credetial delegatio ad eables service- ad method-level authorizatio. Both cotaiers support remote refereces ad a asychroous API for solicit/respose ad otificatio behaviors. WASP Server for Java supports tight itegratio with J2EE. The J2EE framework eables SOAP itegratio with ay JNDI-registered resource. The cotaiers iclude cliet ad server libraries, a cliet library for JavaScript, ad a set of commad-lie tools for all those Sparta developers who isist o developig with vi/emacs/notepad. WASP UDDI WASP Security A UDDI registry service implemetatio iteded for use as a private registry withi a corporatio or a commuity. WASP UDDI, developed usig WASP Server for Java ad Tomcat, supports a variety of registry data stores, icludig Oracle, DB2, Sybase, SQL Server, PostgreSQL, PoitBase, ad Cloudscape. WASP UDDI is available as either a WASP UDDI Stadard, a straight implemetatio of the UDDI v2 specificatio or WASP UDDI Eterprise, which exteds the UDDI v2 specificatio, addig advaced security ad query features. WASP UDDI icludes a Java cliet library that simplifies programmatic access to ay UDDI registry. The cliet library maps the UDDI data structures ad SOAP messages to Java objects ad provides a simple RMI-style programmig iterface. (This library is also icluded i WASP Developer ad WASP Server.) Provides sigle sig-o autheticatio ad authorizatio services. These servers will evetually be budled with WASP Server. WASP Card is a sigle sig-o service that supports a variety of autheticatio methods, such as certificates, Kerberos, LDAP, ad so o). Oce autheticated, a user receives a autheticatio toke that ca be used to access ay Web service that supports the authorizatio toke. Systiet's pla is to make WASP Card compliat with Liberty oce the specificatios have bee published. WASP Guard is a authorizatio service. Both services are accessed through ope SOAP APIs. All security iformatio is exchaged usig SAML. Process flow will take much loger. All process flow (orchestratio) efforts, such as XLANG, WSFL, Busiess Process Modelig Laguage (BPML, from BPMI at ad so o, are so complex that few people will use them, although ebxml choreography has a chace. It's all about establishig the rules of egagemet betwee two compaies, ad it does't attempt to use workflow egies to automatically execute a log-term process. Accordig to Systiet, o process flow stadard will happe for at least a couple of years. Page 210

212 Systiet believes that loosely coupled trasactio maagemet will follow a path similar to that of process flow. Fortuately, there appears to be oly oe stadard effort i this space: BTP. Ayoe who wats to implemet loosely coupled trasactios will use BTP; but Systiet thiks very few people will implemet loosely coupled trasactios i the ear future. Others May compaies i the Web services space, somewhat similar to Microsoft's.NET iitiative, view Web services as a importat techology i its ow right. These compaies create products based o Web services, either startig with the Web service itself ad geeratig stubs ad proxies for adaptatio to existig systems or derivig Web service iterfaces from existig systems. The market for these products remais to be validated, as part of the value propositio of Web services is that they are based o ope stadards that ayoe ca implemet. Microsoft, for oe, is providig the basic Web services ifrastructure as a commodity part of its operatig system. Assumig that Web services go the way of the Web browser ad are accepted ad adopted as widely, compaies focusig solely o Web services may have a tough road. Also, Web services o their ow are ot executable ad to be useful, deped o uderlyig ifrastructure. The ifrastructure vedors are providig Web service-eabled versios of their products, so why buy the Web services layer from someoe else? Shika Systems, for example, takes the view that Web services defiitios are a startig poit rather tha a existig program or database. Its tools defie data types ad messages for Web services, map them to WSDL, ad geerate stubs ad proxies from the WSDL files. Programs are the fit to the stubs ad proxies to provide the implemetatios behid the Web service defiitios. Implemetatios of ebxml Several vedors, icludig BEA, HP, IBM, IONA, Oracle, ad Su Microsystems, are offerig ebxml implemetatios. The typical progressio of implemetatio is to provide the trasport first, usig SOAP with Attachmets; the to provide the registry, followed by the BPSS, CPP ad CPA support; ad, fially, to provide the core specificatios ad modelig tools. However, some vedors are startig at differet poits i the architecture. Most ebxml implemetatios will be delivered over time. Microsoft has clearly stated that it does ot ited to implemet ebxml. A Web services iterface ca easily be created for ebxml, ad several of the vedors are providig this capability. A list of vedors providig ebxml solutios ca be foud at Summary Software vedors provide Web services implemetatios i a variety of architectures, typically depedig o how they apportio value to Web services relative to existig products. Web services provide iterfaces to applicatio servers,.net servers, object request brokers, messageorieted middleware, database maagemet systems, ad packaged applicatios. I additio, some vedors' products are focused o the value of the Web services stadards themselves, providig iteroperability across various software domais, ew mechaisms for assemblig applicatios, ad orchestratios for placig multiple Web services iterfaces ito differet combiatios. Vedors are early uaimous i their support for the core stadards SOAP, WSDL, ad UDDI but vary i their support for additioal techologies. It is agreed that security is a essetial ext step, but opiios vary regardig the relative priority of trasactios, process flow, ad reliable messagig proposals. Page 211

213 With respect to ebxml, some vedors provide implemetatios ad others do ot, although, ofte, it is't clear what a vedor meas by ebxml support whether it's just the trasport (that is, SOAP with Attachmets) or ay of the specified additioal qualities of service, registry, ad metadata techologies. Opiio amog vedors regardig additioal techologies ad ebxml is likely to be iflueced by commercial iterests, iasmuch as vedors ted to support techologies closely related to their products. A wide variety of products is available from large ad small vedors, providig cosiderable choice to cosumers. The basic developmet ad deploymet choice, however, remais betwee Microsoft's.NET ad the Java commuity's J2EE platforms. Visios of the future directio vary also by vedor, with some vedors providig very forwardlookig statemets i terms of the impact of Web services o electroic commerce, ad others stickig to more of a techology-cetric view of where thigs are goig. I ay case, it is certaily clear that software products are sigificatly impacted by Web services implemetatios, ad that Web services hold tremedous potetial for chage. Page 212

214 Bibliography Because Web services techologies ad ebxml are relatively ew, most primary sources of iformatio for this book were specificatios, which ca be foud at the various Web sites listed here. Books Berstei, Philip A., ad Eric Newcomer Priciples of Trasactio Processig New York: Morga Kaufma, 1997 Box, Do, Aaro Skoard, ad Joh Lam Essetial XML: Beyod Markup (The DevelopMetor Series) Bosto: Addiso-Wesley, 2000 Castro, Elizabeth XML for the World Wide Web: Visual QuickStart Guide Bosto: Peachpit Press, 2000 Chappel, David Uderstadig.NET: A Tutorial ad Aalysis Bosto: Addiso-Wesley, 2002 Harold, Elliotte Rusty, ad W. Scott Meas XML i a Nutshell: A Desktop Quick Referece Sebastapol, CA: O'Reilly & Associates, 2000 Kay, Michael H.. XSLT Programmer's Referece, Secod Editio Chicago: Wrox Press, 2001 St. Lauret, Simo, Edd Dumbill, ad Joe Johsto Programmig Web Services with XML-RPC (O'Reilly Iteret Series) Sebastapol, CA: O'Reilly & Associates, 2001 Articles ad White Papers Berers-Lee, Tim "A Roadmap to the Sematic Web" (September 1998,) ad other whitepapers Cepokus, Alex "XML Web Services" Greater Bosto Chapter ACM Professioal Developmet Semiar (March 2001) Cokli, Peter, ad Eric Newcomer, "The Key to the Highway," i The Future of Software by Derek Leebaert (Editor) Cambridge: MIT Press, 1996 Curbera, Fracisco, ad David Ehebuske, IBM; ad Da Rogers, Microsoft "Usig WSDL i a UDDI Registry 1.05" UDDI Workig Draft Best Practices Documet (Jue 25, 2001) -V1.05-Ope pdf Drucker, Peter F."Beyod the Iformatio Revolutio" Atlatic Mothly Olie editio (October 1999) Forum 2000 "Remarks by Bill Gates" Redmod, WA (Jue 22, 2000) Gudgi, Marti, ad Timothy Ewald (December 19, 2001) "All We Wat for Christmas Is a WSDL Workig Group" IONA Techologies PLC (Jauary 2002) "Orbix E2A XMLBus Editio Techology Overview" Page 213

215 Kirtlad, Mary "A Platform for Web Services" Microsoft Developer Network (MSDN) site (Jauary 2001) Shohoud, Yasser "Itroductio to WSDL" Sell, James, Software Egieer, IBM Emergig Techologies (April 2001) "The Web Services Isider, Part 2: A Summary of the W3C Web Services Workshop" ibm.com/developerworks/webservices/library/ws-ref2/ Specificatios ebxml Specificatios: Techical Architecture Busiess Process ad Iformatio Modelig Collaboratio-Protocol Profile ad Agreemet Specificatio Registry ad Repository Services Messagig Service Core Compoets ad Core Library Usig UDDI with ebxml: IBM Specificatios: WSFL: WS-Ispectio: HTTPR: IETF Specificatios: SSL/TLS: TIP: BEEP: Java Specificatios: Microsoft Specificatios: WS-Licese: WS-Security: WS-Ispectio: XLANG: Miscellaeous: SOAP over BEEP: Ope source.net: IONA Web services iformatio: OASIS Specificatios: BTP: OASIS/ebXML Registry Services (RS) Specificatio v2.0: OASIS/ebXML Registry Iformatio Model (RIM) v2.0: ebxml Messagig: ebxml Collaboratio Protocol Profile ad Agreemet (CPA): extesible Access Cotrol Markup Laguage: Page 214

216 OMG Specificatios: Additioal Structurig Mechaisms for the OTS Specificatio (September 2000), documet orbos/ RosettaNet Specificatios: UDDI Specificatios: UDDI Versio 2.0 Programmer's API Specificatio UDDI Versio 2.0 Data Structure Specificatio UDDI Versio 2.0 XML Schema UDDI Versio 2.0 Replicatio Specificatio UDDI Versio 2.0 XML Replicatio Schema UDDI Versio 2.0 XML Custody Schema UDDI Versio 2.0 Operator's Specificatio W3C Specificatios (icludig XML, SOAP, ad WSDL) Mai page: The geeric XML homepage: Extesible Markup Laguage 1.0: XML Base: XML Names: DOM: XML Schema: ad XML Path Laguage: XML Poiter Laguage: XML Likig Laguage: XSL Trasformatio: Caoical XML: XML Iformatio Set: XML Iclusios: XML Query: XML i 10 poits: Clarificatio o URIs ad URLs: WSDL: SOAP v1.2: /12-part1, ad /12-part2 for updates, see also SOAP v1.1: SOAP with Attachmets: XKMS: W3C Workshop o Web Services (April 2001): XML Digital Sigature: Page 215