Building Web Services with Java™: Making Sense of XML,
SOAP, WSDL, and UDDI
By Steve Graham, Simeon Simeonov, Toufic Boubez,
Doug Davis, Glen Daniels, Yuichi Nakamura, Ryo Neyama
Publisher
: Sams Publishing
Pub Date
: December 12, 2001
ISBN
: 0-672-32181-5
Pages
: 600
Slots
:
1
The Web services approach is t he next st ep in t he evolut ion of dist ribut ed com put ing. Based on open indust ry st andards, Web services enable your soft w are t o int egrat e w it h part ners and client s in a fashion t hat is loosely coupled, sim ple, and plat form
-independent . Building Web Services w it h Java: Making Sense of XML, SOAP, WSDL, and UDDI present s t he concept of Web services and explains how t o incorporat e Web services int o your business. The book addresses em erging st andards associat ed wit h Web
services, such as Sim ple Obj ect Access Prot ocol ( SOAP) , Web Services Descript ion Language ( WSDL) , and Universal Descript ion Discovery and I nt egrat ion ( UDDI ) .
All right s reserved. No part of t his book shall be reproduced, st ored in a ret rieval syst em , or t ransm it t ed by any m eans, elect ronic, m echanical, phot ocopying, recording, or
ot herw ise, w it hout w rit t en perm ission from t he publisher. No pat ent liabilit y is assum ed w it h respect t o t he use of t he inform at ion cont ained herein. Alt hough every precaut ion has been t aken in t he preparat ion of t his book, t he publisher and aut hor assum e no responsibilit y for errors or om issions. Nor is any liabilit y assum ed for dam ages result ing from t he use of t he inform at ion cont ained herein.
Library of Congress Cat alog Card Num ber: 2001090920 Print ed in t he Unit ed St at es of Am erica
First Print ing: Decem ber 2001 04 03 02 01 4 3 2 1
All t erm s m ent ioned in t his book t hat are know n t o be t radem arks or service m arks have been appropriat ely capit alized. Sam s Publishing cannot at t est t o t he accuracy of t his inform at ion. Use of a t erm in t his book should not be regarded as affect ing t he validit y of any t radem ark or service m ark.
St eve Graham is an archit ect in t he Em erging Technologies division of I BM Soft w are Group. He has spent t he last several years working on service- orient ed archit ect ures, m ost recent ly as part of t he I BM Web Services I nit iat ive. Prior t o t his, St eve w orked as a t echnologist and consult ant on various em erging t echnologies such as Java and XML, and before t hat he w as an archit ect and consult ant w it h t he I BM Sm allt alk consult ing
organizat ion.
Before j oining I BM, St eve w as a developer w it h Sybase, a consult ant , and a facult y m em ber in t he Depart m ent of Com put er Science at t he Universit y of Wat erloo. St eve holds a BMat h and MMAt h in com put er science from t he Universit y of Wat erloo. You can reach him at sggraham @us.ibm .com.
Sim eon ( Sim ) Sim eonov has been developing soft ware for m ore t han 15 years. Sim 's areas of expert ise encom pass obj ect - orient ed t echnology, com piler t heory, I nt ernet t ools, ent erprise com put ing, and t he broad spect rum of XML t echnologies. As chief archit ect at Macrom edia I nc., Sim provides direct ion for t he evolut ion of t he com pany's t echnology and product st rat egy as w ell as t he archit ect ure of it s server- side plat form product s. Previously, Sim w as chief archit ect at Allaire Corporat ion, w here his init iat ives brought about num erous innovat ions t o t he core product lines.
Process in t he areas of I nt ernet applicat ions, XML, and Web Services. Sim also represent s Macrom edia on t he W3C w orking group on XML Prot ocol. He is a regular speaker at conferences and a m ont hly colum nist for XML Journal. Sim holds a B.A. in Com put er Science, Econom ics, and Mat hem at ics and a MSc in Com put er Science. Toufic Boubez is t he chief t echnology officer of Saffron Technology. Prior t o j oining Saffron, he w as a senior t echnologist in I BM's Em erging Technologies group, and lead archit ect of I BM's Web services init iat ive. He w as I BM's t echnical represent at ive t o t he UDDI Web Services Consort ium w it h Microsoft and Ariba and co- aut hored t he UDDI API specificat ion. He w as also t he I BM t echnical lead on t he UN/ CEFACT/ OASI S ebXML init iat ive and helped drive I BM's early XML and Web services st rat egies.
Dr. Boubez has m ore t han 15 years of experience in I T and has published and present ed on Web services, XML, obj ect t echnology, dist ribut ed com put ing, int elligent agent s, B2B, business m odeling, sim ulat ion, neural net w orks, and w avelet analysis. He holds a
doct orat e in Biom edical Engineering from Rut gers Universit y.
Doug Davis w orks in t he Em erging Technology organizat ion of I BM, w orking on I BM's Web Services Toolkit , and he is one of I BM's represent at ives in t he W3C XML Prot ocol w orking group. Previous proj ect s include WebSphere's Machine Translat ion proj ect , Team Connect ion, and I BM's FORTRAN 90 com piler. Doug has a Bachelor of Science degree from t he Universit y of California at Davis and a Mast er's degree in Com put er Science from Michigan St at e Universit y.
Glen Daniels, in his 13 years in t he soft ware indust ry, has run t he gam ut from device drivers and net w ork st acks up t hrough user int erface and Web sit e w ork, in everyt hing from assem bly language t o C+ + t o Lisp. Dist ribut ed com put ing has alw ays been a passion, and as such he is current ly t echnical lead for t he JRun Web Services t eam at Macrom edia. Glen is an act ive m em ber of t he W3C XML Prot ocol group as w ell as one of t he lead developers of Axis. When not coding, he can oft en be found playing bass or harm onica, hanging out w it h his m any crazy friends in t he Bost on area, or relaxing w it h his cat s.
Yuichi Nakam ura is an advisory researcher at t he I BM Tokyo Research Laborat ory. His research int erest s are Web services including SOAP and XML securit y, obj ect - orient ed syst em s, J2EE, m ult iagent syst em s, B2B e- com m erce, and knowledge engineering. He received an MSc and a PhD in Applied Physics from Osaka Universit y in 1987 and 1990, respect ively.
Ryo Neyam a is a researcher at t he I BM Tokyo Research Laborat ory. His research
int erest s are dist ribut ed obj ect syst em s including Web services, obj ect request brokers, and securit y. He received an MSc in I nform at ion and Com put er Science from Waseda Universit y in 1999.
To Karen, Erin and Jessie, m y fam ily, m y inspirat ion. For all t he m om ent s sacrificed t o creat e t his book, m y m ost heart felt t hanks for your underst anding.
My t hanks t o m y cow orkers at I BM, and in part icular t he WSTK t eam for doing such an out st anding j ob. My t hanks also t o Rod Sm it h for fost ering an excellent environm ent for creat ive work.
My t hanks also t o t he st aff at Sam s, part icularly Tiffany Taylor and Michael St ephens, for t he hard w ork t hat w ent int o m aking t his proj ect a realit y.
I t is m uch easier t o w rit e a book w hen ot hers believe you can. My deepest t hanks t o Pyrra: m y t rue love and a const ant source of inspirat ion. Thanks also t o all m y friends and co- w orkers w ho never st opped being int erest ed in Web services and t he progress of t he book. See? I t 's done.
—Sim Sim eonov
To Lucy and Yasm ine: Thank you for your pat ience, love, and underst anding. This was a m aj or undert aking for a new dad w it h anot her full- t im e j ob. To m y old I BM t eam , Sam Adam s, St eve Burbeck, Jay Casler, St eve Graham , Maryann Hondo, and Rod Sm it h, t hank you for t he great , challenging, and recept ive w ork environm ent . I seriously don't t hink t he concept of Web services w ould have evolved t o w here it is t oday in a different environm ent . To m y new t eam at Saffron, t hank you for replicat ing t hat environm ent ! —Toufic Boubez
Lin—I ow e so m any t hings t o your pat ience, support , and m ost of all your sense of hum or. I can never say it enough, but t hank you.
—Doug Davis
For all m y friends and fam ily w ho so pat ient ly cont inue t o be t here for m e t hrough even t he busiest t im es—love and t hanks t o all of you.
—Glen Daniels
To Michiyo: Thank you for your underst anding and pat ience during t his w ork. Thanks t o m y kids, Arisa and Ryot aro: You alw ays m ade m e happy w it h your lovely sm iles.
My t hanks t o all XML and Securit y t eam m em bers at I BM Tokyo Research Laborat ory. —Yuichi Nakam ura
My t hanks t o m y parent s, Jun and Sachie, for bringing m e up and alw ays support ing m e. My t hanks also t o Takako and m y friends for t heir encouragem ent and underst anding. My t hanks t o m y cow orkers at I BM Tokyo Research Laborat ory for t heir deep insight s on Web services and relat ed t echnologies.
—Ryo Neyam a
As t he reader of t his book, you are our m ost im port ant crit ic and com m ent at or. We value your opinion and w ant t o know w hat w e're doing right , w hat w e could do bet t er, w hat areas you'd like t o see us publish in, and any ot her w ords of w isdom you're w illing t o pass our way.
As an Execut ive Edit or for Sam s Publishing, I w elcom e your com m ent s. You can fax, e-m ail, or w rit e e-m e direct ly t o let e-m e know w hat you did or didn't like about t his book—as w ell as w hat w e can do t o m ake our books st ronger.
Please not e t hat I cannot help you w it h t echnical problem s relat ed t o t he t opic of t his book, and t hat due t o t he high volum e of m ail I receive, I m ight not be able t o reply t o every m essage.
When you w rit e, please be sure t o include t his book's t it le and aut hors' nam es as w ell as your nam e and phone or fax num ber. I w ill carefully review your com m ent s and share t hem w it h t he aut hors and edit ors w ho w orked on t he book.
E-mail:
Mail:
Michael St ephensExecut ive Edit or Sam s Publishing 201 West 103rd St reet I ndianapolis, I N 46290 USA
Welcom e t o t he w orld of Web services! This is a rapidly evolving set of st andards and im plem ent at ion t echnologies t hat have great prom ise for t he w orld of applicat ion int egrat ion and dist ribut ed com put ing.
Before w e get going, w e need t o clarify som e t hings about t he purpose and st ruct ure of t he book. Let 's t alk about t hem now .
The overall goal of t his book is t o fam iliarize you w it h t he concept of Web services and w hat it w ill t ake t o incorporat e Web services as part of your business.
We w ill int roduce t he concept of Web services and give you a fram ew ork t hat describes how you can posit ion t he various em erging st andards t hat are associat ed w it h Web services, such as Sim ple Obj ect Access Prot ocol ( SOAP) , Web Services Descript ion Language ( WSDL) , and Universal Descript ion Discovery and I nt egrat ion ( UDDI ) .
We w ill help posit ion Web services from a business and t echnical perspect ive, explaining and dem onst rat ing how Web services can be used t o address various business problem s, part icularly relat ed t o applicat ion int egrat ion.
Anot her goal of t his book is t o help developers underst and t he issues and det ails relat ed t o building Web services using t he t echniques covered by t his book. What pieces are required w hen you're planning a Web services st rat egy? What t hings do you need t o t ake care of w hen developing Web services? We provide lot s of exam ples and running code t o dem onst rat e t hese approaches. We also review in det ail t he Apache Axis Web services infrast ruct ure w it h our running exam ples. Ot her t ools and Web services infrast ruct ures are discussed as w ell, but not in t he sam e det ail as Axis.
This book is m eant for com put ing t echnical professionals w it h som e experience building Web applicat ions and dist ribut ed com put ing syst em s. You don't need t o be a seasoned vet eran of t he dist ribut ed obj ect w ars t o appreciat e t his book, but som e fam iliarit y w it h Web- based archit ect ures and t echniques such as HTTP and HTML is assum ed. I f you do not have any experience w it h t hese t echniques, som e of t he m at erial could be a lit t le confusing—part icularly som e of t he code exam ples—but you should st ill be able t o get a lot out of t his book.
You w ill also discover t hat t he Ext ensible Markup Language ( XML) is at t he core of all t hings dealing w it h Web service. Alt hough w e devot e an ent ire chapt er t o explaining t he core pieces of XML needed t o build Web services, t he m ore underst anding of XML you have, t he m ore successful you w ill be in building Web services.
I t is difficult t o st ruct ure a book on Web services. The concept s and st andards are very m uch int erdependent . I t is hard t o cover each t opic in isolat ion, because it is t he com binat ion of t hese concept s and st andards t hat m ake Web services im port ant t o dist ribut ed com put ing.
The philosophy of t his book can be sum m arized by four point s: pragm at ics, progressive disclosure, a running exam ple, and a service- orient ed archit ect ure fram ew ork.
I n t his book, w e t ry t o get t o program m ing exam ples and running code as quickly as possible. I n part icular, w e focus on building and consum ing SOAP- based Web services using t he Apache Axis Web services infrast ruct ure. This is a Java- cent ric approach t o building Web services. Whereas w e em phasize t hat Web services are fundam ent ally program m ing language neut ral, ult im at ely, any given Web service is im plem ent ed in som e program m ing language t echnology. I n t he case of t his book, w e have chosen Java. Where issues of int eroperabilit y w it h Web services w rit t en in ot her program m ing
languages m ight appear, w e not e t hem . Det ailed coverage of ot her Web services im plem ent at ion approaches, such as Microsoft 's .NET, is beyond t he scope of t his book, alt hough w e do give som e basic exam ples of .NET and ot her environm ent s in Chapt er 8, " I nt eroperabilit y, Tools, and Middlew are Product s."
Aft er t he overview of Web services, w e st art w it h t he fundam ent als of XML, and t hen layer on new concept s, m ot ivat ed by a business com put ing problem . These layers produce a series of Web services t echnology " st acks." For each of t he t echnologies and st andards in t he Web services arena, w e focus on underst anding t he t echnology from t he perspect ive of w hat problem s it solves, balancing t he explanat ion of t he t echnology it self.
The t echnologies and st andards t hat m ake up t he Web services concept are each exam ined in t he cont ext of a running exam ple ( w hich w e discuss lat er in t his
int roduct ion) . The use of t he running exam ple adds insight t o t he explanat ion of t he concept in t he t ext of t he book and support s t he progressive disclosure approach as w e follow t he exam ple, adding t he layers of Web services t echnology t o t he solut ion. This approach helps posit ion various best - pract ices approaches t o Web service developm ent and deploym ent . You can dow nload t he source code for t hese running exam ples from
w w w .sam spublishing.com. When you reach t hat page, ent er t his book's I SBN num ber ( 0672321815) in t he search box t o access inform at ion about t he book and a Source Code link.
Chapt er 1 begins t he book w it h an explanat ion of w hat t he Web services approach is all about . We describe w hat a Web service is, w hat st andards and t echnologies are
associat ed w it h Web services, and w hat problem s can be solved using Web services. We use t his chapt er t o int roduce t he SOA concept ual fram ew ork and begin t o explain how t he various Web services st andards such as SOAP, WSDL, and UDDI fit t oget her. This chapt er w ill give you a solid concept ual basis for t he rest of t he book.
Before w e can get int o t he core Web services st andards, w e t ake a brief side t rip t o explain XML in Chapt er 2, " XML Prim er." Because XML is at t he heart of all t he Web services st andards and t echniques, it is im port ant you underst and it w ell. XML is a huge t opic, but w e focus our exam inat ion of XML on w hat you w ill need t o know in order t o underst and t he rest of t he Web services t opics.
Aft er t he review of XML, Chapt er 3, " Sim ple Obj ect Access Prot ocol ( SOAP) ," dives in t o t he core problem of invoking a Web service. We review t he t opic of XML m essaging in a dist ribut ed com put ing environm ent , focusing on t he SOAP m essage enveloping st andard. SOAP form s t he core basis of com m unicat ion bet w een a service request or and a service provider in a Web services environm ent .
Chapt er 4, " Creat ing Web Services," refines your underst anding of SOAP in t he cont ext of a part icular SOAP infrast ruct ure: t he Apache Axis proj ect . Chapt er 4 dives int o t he det ails of how Axis w orks and how you can use it t o m ake it easy t o deploy Web services and have your applicat ions consum e Web services.
At t his point , you w ill have a great background underst anding of SOAP and at least one w ay t o m ake SOAP real: Axis. But SOAP alone is not enough t o do m ore t han very sim ple Web services. Chapt er 5, " Using SOAP for e- Business," adds det ail t o t he concept s
int roduced in Chapt ers 3 and 4 by explaining how you can build Web services for com plet e business com put ing problem s. Chapt er 5 discusses how Web services
addresses m any dist ribut ed com put ing problem s including securit y, perform ance, qualit y of service, reliabilit y, and so on.
Chapt er 6, " Describing Web Services," int roduces t he im port ant not ion of service descript ion, w hich is key t o m aking Web services t he great applicat ion int egrat ion t echnology for building loosely coupled syst em s. Chapt er 6 discusses how Web services uses service descript ion t o address t he problem of com m unicat ing w hat det ails t he service request or needs t o know about t he Web service in order t o properly underst and how ( and why) t o invoke it .
Now , you need t o underst and how t he service request or got t he service descript ion in t he first place. Chapt er 7, " Discovering Web Services," picks up where Chapt er 6 left off, discussing t he various t echniques for Web service discovery. This chapt er exam ines t he st andards relat ed t o finding w hat Web services are provided by businesses w it h w hich a com pany m ight w ant t o collaborat e.
Chapt er 8, " I nt eroperabilit y, Tools, and Middlew are Product s," fills out your
underst anding of best pract ices in t he Web services arena by exam ining various ot her Web services infrast ruct ure and t ooling environm ent s.
The book concludes w it h a forw ard- looking Chapt er 9, " Fut ure Concept s," w hich
speculat es on som e possible fut ure uses of Web services t echnologies t o address ot her problem s in dist ribut ed com put ing.
This book int roduces quit e a few t erm s w it h w hich you m ight not be fam iliar. We have included a glossary at t he back of t his book t hat act s as a great reference guide t o t he t erm inology used in t he book. We w ill annot at e t he first use of each t erm appearing in t he glossary using t he
So, before w e get st art ed, let 's int roduce t he fict ional com pany w e'll use for our
exam ples t hroughout t his book: Skat esTow n. We w ill follow Skat esTow n as t he com pany exploit s Web services t o im prove it s business.
Skat esTow n is a sm all but grow ing business in New York founded by t hree m echanically inclined friends w it h a passion for cars and skat eboards. They st art ed by designing and selling cust om pre- built boards out of Dean Carroll's garage, and w ord soon spread about t he qualit y of t heir w ork. They cam e up w it h som e innovat ive new const ruct ion
t echniques, and w it hin m ont hs t hey had orders piling up. Now Skat esTow n has a sm all m anufact uring operat ion in Brooklyn, and t he com pany is selling boards, clot hing, and equipm ent t o st ores around t he cit y. Dean, Frank St em kow ski, and Chad Washingt on couldn't be happier about how t heir business has grow n.
Of t he t hree, Chad is t he real gearhead, and he has been responsible for m ost of t he daring const ruct ion and design choices t hat have helped Skat esTow n get w here it is t oday. He's t he president and head of t he t eam . Frank, gregarious and a sm oot h t alker ever since childhood, now handles m arket ing and sales. Dean has t ight ly t racked t he com put er revolut ion over t he years, and is chief t echnical officer for t he com pany. A few years back, Dean realized t hat net w orking t echnology w as going t o be big, and he w ant ed t o m ake sure t hat Skat esTow n could cat ch t he w ave and ut ilize dist ribut ed com put ing t o leverage it s business. This focus t urned out t o be a great m ove.
Dean set up a Web presence so Skat esTow n could help it s cust om ers st ay up- t o- dat e w it hout requiring a large st aff t o answ er phones and quest ions. He also built an online order- processing syst em t o help st ream line t he act ual flow of t he business w it h net w ork-enabled client s. I n recent m ont hs, m ore and m ore st ores w ho carry Skat esTow n product s have been using t he syst em t o great effect .
At present , Dean is pret t y happy w it h t he w ay t hings are w orking w it h Skat esTow n's elect ronic com m erce syst em s. But t here have been a few problem s, and Dean is sure t hat t hings could be even bet t er. He realizes t hat as t he business grow s, t he m anual t asks associat ed w it h order gat hering and invent ory resupply w ill lim it t he com pany's success. Alw ays one t o w at ch t he horizon, Dean has heard t he buzz about Web services, and w ant s t o know m ore. At t he urging of a friend, he got in t ouch w it h Al Rosen, a cont ract or for Silver Bullet Consult ing. Silver Bullet specializes in Web services solut ions, and aft er a couple of m eet ings w it h Al, Dean w as convinced—he hired SBC t o com e in, evaluat e Skat esTow n's syst em s, and help t he com pany grow int o a Web service–enabled business.
As w e m ove t hrough t he rest of t he book, w e'll keep an eye on how Skat esTow n uses t echnologies like XML and, lat er, SOAP, WSDL, and UDDI t o increase efficiency, product ivit y, and est ablish new and valuable relat ionships w it h it s cust om ers and business part ners. Silver Bullet , as w e'll see, usually lives up t o it s nam e.
I N THI S CHAPTER
•
•
•
•
•
I n t his chapt er, w e w ill provide t he basic t erm inology and set of concept s t hat put t he rem ainder of t he book int o cont ext . We w ill define w hat w e m ean by a Web service and describe sit uat ions in w hich Web services w ill play an im port ant role. We w ill describe a sim ple fram ew ork, called service- orient ed archit ect ure , t hat helps
st ruct ure t he applicat ion of Web services t echnologies. We w ill also provide a fram ew ork, in t he form of t hree " int eroperabilit y" st acks t hat posit ion how t he various Web services t echnologies such as Sim ple Obj ect Access Prot ocol ( SOAP) , Web Services Descript ion Language ( WSDL) , and Universal Descript ion Discovery and I nt egrat ion ( UDDI ) relat e.
The rest of t he book, t hen, is an elaborat ion of t he basic concept s present ed here.
This is a book about building Web services. We cannot describe how t o build a Web service w it hout first clarifying w hat w e m ean by a Web service.
The t erm Web services has gained a lot of m om ent um in t he last year. Many soft w are vendors ( large and sm all) are announcing Web services init iat ives and adopt ion ( see t he sidebar "Web Services Market Dynam ics" ) . Many organizat ions are involved in t he refinem ent of Web services st andards. Alt hough t here seem s t o be a slow convergence t ow ards a com m on underst anding of w hat t he t erm m eans, t here is no single, universally adopt ed definit ion of w hat is m eant by t he t erm Web service. This sit uat ion is
rem iniscent of t he early days of obj ect - orient ed program m ing: Not unt il t he concept s of inherit ance, encapsulat ion, and polym orphism w ere w ell defined did obj ect - orient ed program m ing becom e accept ed int o t he m ainst ream of developm ent m et hodologies. Several m aj or Web services infrast ruct ure providers have published t heir definit ions for a Web service:
I BM offers t his definit ion at
ht t p: / / w w w 4.ibm .com / soft w are/ solut ions/ Webservices/ pdf/ WSCA.pdf:
A Web service is an int erface t hat describes a collect ion of operat ions t hat are net w ork accessible t hrough st andardized XML m essaging. Web services fulfill a specific t ask or a set of t asks. A Web service is described using a st andard, form al XML not ion, called it s service descript ion, t hat provides all of t he det ails necessary t o int eract w it h t he service, including m essage form at s ( t hat det ail t he operat ions) , t ransport prot ocols, and locat ion. The nat ure of t he int erface hides t he im plem ent at ion det ails of t he service so t hat it can be used independent ly of t he hardw are or soft w are plat form on w hich it is im plem ent ed and independent ly of t he program m ing
cross-t echnology im plem encross-t across-t ions. Web services can be used alone or in
conj unct ion w it h ot her Web services t o carry out a com plex aggregat ion or a business t ransact ion.
Microsoft has a couple of definit ions for Web service. The first is at ht t p: / /
m sdn.m icrosoft .com / library/ default .asp?url= / nhp/ Default .asp?cont ent id= 28000442: A Web service is a unit of applicat ion logic providing dat a and services t o ot her applicat ions. Applicat ions access Web services via ubiquit ous Web prot ocols and dat a form at s such as HTTP, XML, and SOAP, w it h no need t o w orry about how each Web service is im plem ent ed. Web services com bine t he best aspect s of com ponent - based developm ent and t he Web, and are a cornerst one of t he Microsoft .NET program m ing m odel.
The ot her Microsoft definit ion is at
ht t p: / / m sdn.m icrosoft .com / library/ default .asp?url= / library/ en-us/ dnWebsrv/ ht m l/ Websvcs_plat form .asp:
A Web service is program m able applicat ion logic accessible using st andard I nt ernet prot ocols. Web services com bine t he best aspect s of com ponent -based developm ent and t he Web. Like com ponent s, Web services
represent black- box funct ionalit y t hat can be reused w it hout w orrying about how t he service is im plem ent ed. Unlike current com ponent t echnologies, Web services are not accessed via obj ect - m odel- specific prot ocols, such as t he dist ribut ed Com ponent Obj ect Model ( DCOM) , Rem ot e Met hod I nvocat ion ( RMI ) , or I nt ernet I nt er- ORB Prot ocol ( I I OP) . I nst ead, Web services are accessed via ubiquit ous Web prot ocols and dat a form at s, such as Hypert ext Transfer Prot ocol ( HTTP) and Ext ensible
Markup Language ( XML) . Furt herm ore, a Web service int erface is defined st rict ly in t erm s of t he m essages t he Web service accept s and generat es. Consum ers of t he Web service can be im plem ent ed on any plat form in any program m ing language, as long as t hey can creat e and consum e t he m essages defined for t he Web service int erface.
Sun provides t he follow ing definit ion at
ht t p: / / w w w .sun.com / soft w are/ sunone/ faq.ht m l# 2:
Web services are soft ware com ponent s t hat can be spont aneously
discovered, com bined, and recom bined t o provide a solut ion t o t he user's problem / request . The Java™ language and XML are t he prom inent
t echnologies for Web services.
As you can see, t here is broad agreem ent on w hat a Web service m ight be, but no single agreed- upon definit ion. Many developers w ill claim t hey cannot define w hat a Web service is, but t hey know one w hen t hey see one.
From t he perspect ive of t his book, a Web service is a plat form and im plem ent at ion independent soft w are com ponent t hat can be:
•
•
•
•
One im port ant point is t hat a Web service need not necessarily exist on t he World Wide Web. This is an unfort unat e hist orical nam ing issue. A Web service can live anyw here on t he net w ork, I nt er- or int ranet ; som e Web services can be invoked by a sim ple m et hod invocat ion in t he sam e operat ing syst em process, or perhaps using shared m em ory bet w een t ight ly coupled processes running on t he sam e m achine. I n fact , Web services have lit t le t o do w it h t he brow ser- cent ric, HTML- focused World Wide Web. Som et im es, t he nam es w e choose in t he inform at ion t echnology ( I T) indust ry don't m ake a lot of sense; t hey sim ply t ake on a life of t heir ow n.
Anot her im port ant point is t hat a Web service's im plem ent at ion and deploym ent plat form det ails are not relevant t o a program t hat is invoking t he service. A Web service is
available t hrough it s declared API and invocat ion m echanism ( net w ork prot ocol, dat a encoding schem es, and so on) . This is analogous t o t he relat ionship bet w een a Web brow ser and a Web applicat ion server: Very lit t le shared underst anding exist s bet w een t he t w o com ponent s. The Web brow ser doesn't part icularly care if t he Web applicat ion server is Apache Tom cat , Microsoft I I S, or I BM Websphere. The shared underst anding is t hat t hey bot h speak HTTP and converse in HTML or a very lim it ed set of MI ME t ypes. Sim ilarly, t he Web applicat ion server really doesn't care w hat kind of client is using it — various brands of Web browsers or even non- browser client s. This m inim al shared underst anding bet w een com ponent s allow s Web services t o form a syst em of loosely coupled com ponent s.
To a business person, t he Web services approach is all about int egrat ion: int egrat ing applicat ion funct ionalit y w it hin an organizat ion or int egrat ing applicat ions bet w een business part ners ( in a supply chain, for exam ple) . The scenario in t his book illust rat es t his approach, part icularly in Chapt er 7, " Discovering Web Services." This applicat ion int egrat ion allow s t im e and cost efficiencies for receiving purchase orders, answ ering st at us inquiries, processing shipm ent request s, and so on. The im port ant point is t hat applicat ion int egrat ion is enabled w it hout t ight lock- in t o any part icular business part ner. I f anot her supplier has a bet t er price, shipping t erm s, or qualit y assurance, t hen a
com pany's reorder syst em s can be easily reposit ioned t o use t hat supplier; doing so is as easy as point ing a Web brow ser at a different Web sit e. Wit h a broader adopt ion of Web services and XML docum ent form at st andards, t his st yle of dynam ic business part ner int egrat ion w ill becom e m ore broadly used.
When syst em s are t his easy t o int egrat e, an organizat ion's reach t o suppliers, cust om ers, and ot her business part ners is ext ended, yielding cost savings, flexible business m odels, bet t er cust om er service, higher cust om er ret ent ion, and so on. Just as I T is fundam ent al t o t he efficient operat ions of an organizat ion, Web services- based syst em s int egrat ion w ill be fundam ent al t o flexible, light w eight syst em s int egrat ion—for int ernal applicat ion int egrat ion w it hin an organizat ion over an int ranet and ext ernal part ner int egrat ion over t he I nt ranet or ext ended virt ual privat e net w ork.
So, from a business perspect ive, a Web service is a business process or st ep wit hin a business process t hat is m ade available over a net w ork t o int ernal and/ or ext ernal business part ners t o achieve som e business goal.
evolut ion of t he SOAP and WSDL specificat ions) . Furt her, t he approach oft en t aken w it h Web services uses capabilit ies- based lookup , w here t he kind of service is searched for, as opposed t o a service of a part icular nam e or obj ect ident ifier.
The Web services approach is an applicat ion int egrat ion concept ; it is a set of t echnologies t hat provides access t o business funct ionalit y, such as purchase order processing. Oft en, t he business funct ionalit y already exist s in t he form of legacy
t ransact ion processing syst em s, exist ing Web applicat ions, Ent erprise Java Beans, and so on. Web services t echnology is about access and applicat ion int egrat ion; it is not an im plem ent at ion t echnology.
Organizat ions use Web services t echnology in t w o broad cat egories: Ent erprise
Applicat ion I nt egrat ion ( EAI ) and business- t o- business ( B2B) part ner int egrat ion over t he I nt ernet . I n eit her of t hese cat egories, Web services can range in sophist icat ion from sim ple request response funct ions such as a credit card check t o very com plicat ed m ult i- part y, m ult i- st age long- running business t ransact ions such as a supply
configurat ion and order syst em . Web services can be invoked by PC- based program s, m ainfram e syst em s, Web browsers, or even sm all m obile devices such as cell phones or personal digit al assist ant s ( PDAs) .
Regardless of t he applicat ion, Web services w ill be used for syst em s int egrat ion: flexible, loosely- coupled syst em s int egrat ion yielding syst em s t hat can be decom posed and recom posed t o reflect changes in t he business.
Ent erprise Applicat ion I nt egrat ion is st ill a field w here large consult ing com panies com m and m ult im illion dollar cont ract s t o help t heir client s deal w it h a m ess of applicat ions t hat w ere never m eant t o int eroperat e.
The st at e of t he art wit hin m any ent erprise syst em s rem ains t hat of large, m onolit hic applicat ion " silos." These syst em s are oft en ext rem ely difficult t o change, let alone int egrat e w it h ot her syst em s. These applicat ions oft en define unique dat a form at s, and som et im es ( for hist orical, oft en perform ance- relat ed reasons) even define t heir ow n com m unicat ions prot ocols. Furt herm ore, m any syst em s, part icularly in large
organizat ions, can exist on m ult iple different plat form t echnologies. I nt eroperabilit y bet w een syst em s is a significant challenge. I n m any organizat ions, part icularly organizat ions t hat result from a m erger of t w o previously independent com panies, I T int egrat ion cost s can seriously im pact t he financial healt h of t he com pany.
The Web services approach offers an at t ract ive set of t echnologies by w hich exist ing legacy syst em s can be w rappered as Web services and m ade available for int egrat ion w it h ot her syst em s w it hin t he organizat ion. Applicat ions exposed as Web services are accessible by ot her applicat ions running on different hardw are plat form s and w rit t en in different program m ing languages. Using t his approach, t he com plexit y of t hese syst em s can be encapsulat ed behind indust ry- st andard XML prot ocols. Pair- w ise syst em
int egrat ion proj ect s can be replaced w it h one- t o- m any syst em s int eract ions based on Web services. The prom ise of higher- level int eroperabilit y init iat ives is t hat over t im e w e w ill be able t o develop t he set of st andards, t echnologies, and t ools t hat w ill enable sm all and large businesses all over t he w orld t o easily int egrat e syst em s int ernally, and t hen m ix and m at ch t he im plem ent at ion of various act ivit ies w it hin a business process,
m aint aining t he opt ion t o, at any t im e, choose t o out source any or all of t hese act ivit ies if doing so m akes business sense.
w it h I T. Flexible syst em s w ill yield flexible business m odels. Flexible business m odels w ill yield organizat ions bet t er able t o adapt t o changes in t he business environm ent .
Anot her key driver behind t he rise of Web services is t he cont inuing evolut ion of B2B com put ing. B2B com put ing is about int egrat ing t he business syst em s of t w o or m ore com panies t o support cross- ent erprise business processes such as supply chain
m anagem ent . Som e indust ry pundit s claim t hat supply chain int egrat ion w ill be t he killer applicat ion of Web services, part icularly as a result of t he st andardizat ion of com m on indust ry form at s for XML and Web services relat ed t o supply chain business processes. B2B applicat ions can be as sim ple as aut om at ed credit card validat ion or as com plex as t he full aut om at ion of t he m ult i- billion- dollar supply chain of a Fort une 100 com pany. The challenges of building B2B applicat ions com bined w it h t heir huge m arket pot ent ial drove rapid innovat ion t hat has t aken t he indust ry from sim ple business- t o- consum er ( B2C) applicat ions t o SOAP- enabled Web services in a m at t er of five years.
Online HTML- based applicat ions are consum er- orient ed. The classic exam ple of a B2C Web applicat ion is t he Am azon book search. To access t his funct ionalit y, a hum an being needs t o use a Web brow ser t o navigat e t he com pany's sit e t hrough m ult iple page t ransit ions, input inform at ion using Web form s, subm it t hem , and get t he result s back in hum an- readable form . The only w ay t o aut om at e t his process is t o sim ulat e how a hum an uses t he syst em . Doing so involves reverse- engineering t he Web applicat ion t o see how it m oves dat a bet w een pages, passing t he dat a aut om at ically from page t o page, and, finally, parsing any dat a cont ained in t he response HTML of pages. This
screen- scraping approach w as popular in t he early years of t he Web ( 1995–97) . I t is very error prone. Any changes in t he Web applicat ion—even changes t hat are com plet ely UI -cent ric and do not change t he dat a being passed back and fort h—can break screen-scraping applicat ions. These problem s are com pounded because m ost of t hese
applicat ions do not properly separat e present at ion from applicat ion processing logic. The only t rue w ay t o int egrat e applicat ions on t he Web is t o use a B2B- focused solut ion. Because B2B applicat ions are designed t o have ot her applicat ions as t heir client s, t hey are fundam ent ally different from B2C applicat ions. Table 1.1 sum m arizes som e of t hese differences for Java applicat ions. Bot h t ypes of applicat ion are unrest rict ed as t o t he t ype of backend t hey can use—t ypically, Java classes or Ent erprise Java Beans ( EJBs) . ( We discuss how Web services w ork w it h EJBs in m ore det ail in Chapt er 5, " Using SOAP for e-Business." ) This is where t he sim ilarit ies end, however. To cust om ize backend logic, B2C applicat ions use servlet s or Java Server Pages ( JSPs) t hat are host ed in a servlet engine. B2B applicat ions cust om ize t heir backends using st raight Java code ( oft en EJBs) t hat is host ed inside a Web service engine. B2C applicat ions com m unicat e w it h a brow ser over HTTP. B2B applicat ions can use any of t he open I nt ernet prot ocols such as HTTP, SMTP, or FTP, or propriet ary net w orks such as EDI . B2C applicat ions handle dat a over t he st raight HTTP prot ocol. I nput com es as GET param et ers ( on t he URL/ query st ring) or as POST param et ers from Web form s. Only st rings can be exchanged. Any ot her dat at ypes, even num bers, need t o be encoded as st rings. For out put , dat a is m ixed t oget her w it h form at t ing rules inside HTML pages. This is in m arked cont rast w it h B2B applicat ions t hat use XML for bot h dat a input and out put . XML is perfect for B2B com put ing because it is program m ing language- and plat form - neut ral, it can represent arbit rary dat a st ruct ures, it is easy t o process, and it can be validat ed independent ly of it s processing. B2C
Area
B2C application
B2B application
Backend logic
Java classes and EJBs Java classes and EJBs
Custom logic
Servlets and JSPs
Web service engine
Communication
protocol
HTTP
HTTP, SMTP, FTP, TCP/IP, EDI,
JMS, RMI/IIOP…
Data input
HTTP GET/POST
parameters
XML
Data output
HTML
XML
UI
HTML + script
N/A
Client
Human behind a
browser
Software application
I t is clear t hat t he net w ork econom y is current ly driving t he evolut ion of business. Businesses m ust respond t o increasingly dynam ic m arket places. Wit hin corporat e depart m ent s, applicat ion int egrat ion has been a m aj or issue in t he last few years. Tradit ional archit ect ures are brit t le, and t his brit t leness is being exposed as t he scale, dem and level, t ransact ion volum e, and rat e of change of t ransact ion volum e increases. I nt eroperabilit y, part icularly bet w een het erogeneous dist ribut ed syst em s com ponent s, has been one of t he m aj or t hem es in soft w are engineering in general, and EAI in
part icular, for t he last decade. I t 's unfort unat e t hat t he seam less int eroperabilit y vision is st ill a dream . Brit t leness in all current archit ect ures is prevent ing soft w are from achieving t his vision. Brit t leness com es from t ight ly coupled syst em s t hat generat e dependencies at every level in t he syst em . One of t he m ost im port ant lessons w e learned as developers and archit ect s is t hat syst em s need t o be able t o find resources ( soft w are or ot herwise) aut om at ically, w hen and as needed, w it hout hum an int ervent ion. This abilit y frees business people t o concent rat e on t heir business and cust om ers rat her t han w orry about I T com plexit ies. At t he sam e t im e, it frees syst em developers t o concent rat e on enabling t heir business and t heir cust om ers rat her t han deal w it h int eroperabilit y headaches by w rit ing glue code and pat ching syst em s t oget her. More t han any t echnical considerat ion, t his concept of im plicit , seam less int egrat ion as a m aj or business benefit is one of t he m ain drivers for service orient at ion. I n ot her w ords, t he t im e has com e for " j ust in t im e" int egrat ion!
Trends in applicat ion design are m oving from rigid st ruct ures t o flexible archit ect ures. Trends in business part ner int eract ions are m oving from st at ic agreem ent s t o m ore dynam ic agreem ent s. Trends in B2B int egrat ion are m oving from t echnology- based int egrat ion t o business process- based int egrat ion. There is a corresponding shift in program m ing and archit ect ure m odels t o enable t hese t rends: from t ight ly coupled applicat ions t o loosely coupled services.
One aspect of m ore loosely coupled syst em s is reflect ed in t he m ove from Rem ot e Procedure Call ( RPC) int erfaces t ow ards a m essaging or docum ent - cent ric m odel of dist ribut ed com put ing int erface. Wit h a docum ent - cent ric approach, t he int erface t o t he Web service becom es m uch m ore sim ple and flexible. An RPC int erface present ing a fixed set of param et ers in a fixed order is quit e brit t le. Sm all changes t o inform at ion required— for exam ple, a new requirem ent for an expirat ion dat e on a credit card—require a new int erface t o be creat ed, published, and underst ood by t he service request or. Wit h a docum ent - cent ric approach, t he new inform at ion can be added t o t he docum ent schem a defined in t he Web service int erface. Program s t hat use t he older schem a don't
necessarily break w hen t he new XML elem ent is added ( t his is a propert y of XML nam espaces t hat you w ill see in Chapt er 2, " XML Prim er" ) . This approach yields Web services int erfaces t hat are m uch m ore flexible, result ing in syst em s t hat are m uch m ore adapt ive.
Most m aj or soft ware com panies and m any sm aller soft ware vendors have em braced t he concept of Web services in one form or anot her. Som e m ight j ust be giving it lip service, hedging on whet her it 's j ust anot her fad, or using it as a buzzw ord t o generat e m arket ing fodder. Ot hers have st aked t heir fut ure on it . Here is a brief exam inat ion of t he Web services init iat ives from a few m aj or players:
•
•
• Oracle: Oracle 9i Web Services Broker— The Oracle approach t o Web services also follow s t he t radit ional SOAP, WSDL, UDDI perspect ive. Oracle em phasizes t he role of it s dat abase t echnology as a service regist ry ( broker) providing securit y and ot her value added services as an int erm ediary bet w een service request or and service provider.
• Macrom edia: Macrom edia plat form — Macrom edia has em braced Web services t hroughout it s m ass- ent erprise plat form . I t s rich client s can display inform at ion ret rieved t hrough Web services, it s applicat ion servers m ake building Web services possible for developers at all skill levels, and it s t ools provide high- level support for building applicat ions t hat leverage Web services.
I t is excit ing t o see so m any soft ware vendors act ive in Web services. Wit h m ult iple vendors, t here is a risk of incom pat ibilit y of im plem ent at ions. Unless Web services from different vendors can int eroperat e, Web services w ill fail t o at t ain crit ical m ass of adopt ion. Happily, t here is significant focus am ong t he various Web services im plem ent at ions t o develop and m aint ain int eroperabilit y.
Chapt er 8 w ill look at a collect ion of Web services im plem ent at ions in t he indust ry, from large soft w are vendors t o sm aller bout ique Web services infrast ruct ure providers.
The beginning of t his chapt er explained t he m ot ivat ion for applicat ion- t o- applicat ion com m unicat ion over t he I nt ernet t o address t he current challenges of dist ribut ed
com put ing and B2B int egrat ion in part icular. Since 1999, t he soft w are indust ry has been rapidly evolving XML- based Web services t echnologies as t he approach t o t hese
problem s. I n t he m aelst rom of press hype, product releases, and st andards
announcem ent s, m any people have been left w ondering w het her t his is a good in w hich direct ion t o go. Aft er all, w e already have m any different m echanism s for dist ribut ed com put ing. Surely, som e of t hem w ould be able t o rise t o m eet t he challenges of e-business. Why build a com plet ely new dist ribut ed com put ing st ack based on Web services?
This is a very good quest ion and one t hat is hard t o give a short answ er t o. " Because Web services use XML" is not t he right answ er. I t is a correct observat ion, but it doesn't answ er t he crucial quest ion as t o w hy using XML m akes such a big difference. At a basic level, t here are t hree key reasons w hy exist ing dist ribut ed com put ing approaches are inferior t o Web services for solving t he problem s of e- business:
•
•
Tradit ional dist ribut ed com put ing m echanism s have t ypically evolved around t echnical archit ect ures rat her t han broader problem s of applicat ion int egrat ion. For exam ple, CORBA evolved as a solut ion t o t he problem of im plem ent ing rich dist ribut ed obj ect archit ect ures. At t he t im e, it w as im plicit ly assum ed t hat t his w as t he right approach t o get t ing applicat ions t o com m unicat e w it h one anot her. As w e discussed earlier,
experience has show n t hat RPCs are not alw ays t he best archit ect ure for t his
requirem ent . The need for loosely coupled applicat ions and business process aut om at ion has clearly shown t he benefit s of sim ply exchanging m essages cont aining dat a ( t ypically a business docum ent ) bet w een t he part icipant s of e- business int eract ions, a so- called docum ent - cent ric approach. Dist ribut ed com put ing specificat ions address m essaging as a com put ing archit ect ure; how ever, t here has been no unifying approach t hat brings RPCs and m essaging t o t he sam e level of im port ance—unt il Web services, t hat is.
Web services have evolved not around pre- defined archit ect ures but around t he problem of applicat ion int egrat ion. This is a very im port ant dist inct ion. The choice of problem scope defines t he focus of a t echnology init iat ive. Web services t echnologies have been designed from t he ground up t o focus on t he problem s of applicat ion int egrat ion. As a result , w e are able t o do t hings out side t he scope of t radit ional dist ribut ed com put ing approaches:
•
•
•
I n ot her words, Web services are bet t er suit ed for t he t ask t han what we have so far because w e have specifically built t hem w it h t his in m ind. COM/ CORBA/ RMI are st ill great t echnologies for t ying t oget her dist ribut ed obj ect s on t he corporat e net w ork. How ever, t he e- business applicat ion int egrat ion problem is best t ackled by Web services.
Because Web services address a m uch m ore broadly scoped problem , t hey use m uch m ore flexible t echnologies t han t radit ional dist ribut ed com put ing approaches. Furt her, w it h Web services w e can leverage all t hat w e have learned about connect ing and int egrat ing applicat ions since w e first st art ed doing dist ribut ed com put ing. These t w o fact ors put Web services on a bet t er t echnology foundat ion for solving t he problem s of e-business t han t radit ional dist ribut ed com put ing approaches.
Lat er, in t he "Web Services I nt eroperabilit y St acks" sect ion, w e int roduce t he not ion of Web services int eroperabilit y st acks. These int eroperabilit y st acks organize a layering of t echnologies t hat define t he capabilit ies of Web services. I t is possible t o com pare t he Web services approach t o t radit ional dist ribut ed com put ing approaches level- by- level t o see w hy t he t echnical foundat ion of Web services is m ore appropriat e for t he problem s it needs t o solve. Rat her t han going t hrough t his lengt hy process, let 's focus on t w o key capabilit ies: t he abilit y t o represent dat a st ruct ures and t he abilit y t o describe t hese dat a st ruct ures.
Web services address t hese issues by using XML t o represent inform at ion. XML's t ext -based form elim inat es byt e ordering concerns. The w ide availabilit y of XML processing t ools m akes part icipat ion in t he w orld of Web services relat ively easy. XML's hierarchical st ruct ure ( achieved by t he nest ing of XML elem ent s) allows changes at som e level of nest ing in an XML docum ent t o be m ade w it h ease w it hout w orrying about t he effect on ot her part s of t he docum ent . Also, t he expressive nat ure of at t ribut es and nest ed
elem ent s m akes it considerably easier t o represent com plex dat a st ruct ures in XML t han in t he pure binary form at s t radit ionally used by COM and CORBA, for exam ple. I n short , XML m akes w orking w it h arbit rary dat a easier.
The choice of XML brought anot her advant age t o Web services—t he abilit y t o describe dat at ypes and validat e w het her dat a com ing on t he w ire com plies w it h it s specificat ion. This happens t hrough t he use of XML m et a- languages such as XML Schem a. Binary dat a encodings t ypically used for dist ribut ed com put ing offered no such m echanism and t hus pushed dat a validat ion int o applicat ion logic, considerably com plicat ing applicat ions dealing w it h non- t rivial dat a.
Mom ent um is a very im port ant aspect of t he dynam ics of soft w are innovat ion. Great problem s gat e great opport unit ies. The desire t o capit alize on t he opport unit ies generat es m om ent um around a set of init iat ives t arget ed at solving t he problem . This m om ent um is t he binding force of our indust ry. This is how m aj or innovat ion t akes place on a broad scale. The challenge of e- business applicat ion int egrat ion is great ; t his is w hy all t he key players in t he indust ry are focused on it ( see t he sidebar "Web Services Market Dynam ics" ) . Cust om er need, m arket pressure, and t he desire t o be part of t he front ier- defining elit e have pushed m any com panies t o becom e deeply engaged w it h Web services. Good t hings are bound t o happen. Consider t his: The last t im e every one of t he key infrast ruct ure vendors was focused on t he sam e set of issues was during t he early days of e- business w hen t he indust ry w as t rying t o address t he challenges of building Web applicat ions. The net result w as a new m odel for applicat ion developm ent t hat leveraged t he Web brow ser as a universal client and t he Web applicat ion server as a universal backend. I n short , t rust t hat som e of t he very best m inds in t he indust ry w orking t oget her under t he aegis of organizat ions such as t he W3C and OASI S w ill be able t o com e up w it h a good solut ion t o t he problem s of e- business int egrat ion.
To t he vet erans of t he soft w are indust ry, m om ent um som et im es equals hype. So, are w e t rying t o say t hat Web services w ill succeed because t here is so m uch hype around t hem ? Absolut ely not ! The m om ent um around Web services is real and different from w hat w e have experienced so far w it h ot her dist ribut ed com put ing fads. The fundam ent al difference is around t he abilit y of m any indust ry players t o engage in com plem ent ary st andardizat ion in parallel.
Parallelism is key t o building real m om ent um and increasing t he bandw idt h of innovat ion. Tradit ional dist ribut ed com put ing effort s could not achieve t his kind of parallelism
because t hey w ere eit her driven by a single vendor—Microsoft prom ot ing COM, for exam ple—or t hey w ere driven by a large, slow organizat ion such as t he Obj ect
Managem ent Group ( OMG) , w hich ow ns t he CORBA st andards. I n bot h cases, t he key barrier t o fast progress w as t he cent ralized m anagem ent of st andards. Any change had t o be approved by t he body ow ning t he st andard. And Microsoft and OMG ow ned all of COM and CORBA, respect ively. This is no w ay t o gain real m om ent um , regardless of t he size of t he m arket ing budget s t o prom ot e any given t echnology. Vendors t hat feel t hey have very lit t le cont rol over t he evolut ion of a t echnology w ill likely spend very lit t le t im e invest ing in it s evolut ion. I n ot her w ords, you m ight use COM, but if you t hink you have no chance of influencing Microsoft 's direct ion on COM you w ill probably not spend m uch t im e t hinking about and prot ot yping w ays t o im prove COM. Open- source effort s such as t he Linux operat ing syst em and proj ect s of t he Apache Soft w are Foundat ion
st andardizat ion w ork is going on in parallel at t he W3C, OASI S, UDDI , and m any ot her horizont al and vert ical indust ry st andards organizat ions. Furt her, t he m aj or players so far have show n a com m it m ent t o do a lot of innovat ion out in t he open.
The int erest ing t hing from a t echnical perspect ive is t hat XML act ually has som et hing t o do w it h t he abilit y of Web service st andardizat ion t o be parallelized. XML has facilit ies ( nam espaces and schem a) t hat enable t he decent ralized evolut ion of XML- based
st andards w it hout prevent ing t he lat er com posit ion of t hese st andards in t he cont ext of a single solut ion. For exam ple, if group A ow ns som e st andard and group B is t rying t o build an ext ension t o t he st andard, t hen w it h som e careful use of XML, group B can design t he ext ensions such t hat :
•
•
•
•
The indust ry's focus on Web services com bines t he right scope ( e- business applicat ion int egrat ion) w it h t he right t echnologies ( XML- based st andards) w it h t he pot ent ial for significant parallelism and high- bandw idt h innovat ion. This is w hy Web services w ill be successful.
Hist orically, dist ribut ed com put ing has been focused on t he problem of
dist ribut ing com put at ion bet w een several syst em s t hat are j oint ly w orking on a problem . The m ost oft en used dist ribut ed com put ing abst ract ion is t he RPC. RPCs allow a rem ot e funct ion t o be invoked as if it w ere a local one. Dist ribut ed obj ect - orient ed syst em s require obj ect - based RPCs ( ORPCs) . ORPCs need som e addit ional cont ext t o be able t o invoke m et hods on specific obj ect inst ances. The hist ory of RPC- st yle dist ribut ed com put ing and dist ribut ed obj ect s is fairly
com plicat ed. The follow ing t im eline illust rat es som e of t he key event s:
•
o
o
•
o
•
o
•
o
o
•
o
o
•
o
•
o
o
Alt hough RPCs and dist ribut ed obj ect s have been t he t radit ional approaches for building dist ribut ed syst em s, t hey are by no m eans t he only ones. Anot her very im port ant approach is t hat of dat a- orient ed or docum ent - cent ric m essaging. Rat her t han being focused on dist ribut ing com put at ion by specifically invoking rem ot e code, m essaging t akes a different approach. Applicat ions t hat
com m unicat e via m essaging run t heir ow n independent com put at ions and com m unicat e via m essages t hat cont ain pure dat a. Messaging w as popularized via t he effort s of syst em int egrat ors w ho w ere t rying t o get highly
het erogeneous syst em s t o int eroperat e. I n m ost cases, t he syst em s were so different t hat t he requirem ent t o perform fine- grain int egrat ion via RPCs w as im possible t o sat isfy. I nst ead, syst em int egrat ors w ere happy t o be able t o reliably m ove pure dat a bet w een t he syst em s. Com m ercially, t he im port ance of m essaging applicat ions has been st eadily grow ing since I BM released it s
m essaging product MQSeries in 1993. Microsoft 's m essaging product is t he Microsoft Message Queuing Server ( MSMQ) . J2EE defines a set of API s for m essaging t hrough t he Java Messaging Service ( JMS) . There has been no at t em pt t o define a st andard int eroperabilit y prot ocol for m essaging servers. One of t he key benefit s of Web services is t hat t he core Web service prot ocols can support RPCs and m essaging w it h equal ease.
Chapt er 3, " Sim ple Obj ect Access Prot ocol ( SOAP) ," has a sect ion t hat addresses t his t opic in det ail.
Any service- orient ed archit ect ure cont ains t hree roles: a service request or , a service provider , and a service regist ry :
•
•
Each of t hese roles can be played by any program or net w ork node. I n som e
circum st ances, a single program m ight fulfill m ult iple roles; for exam ple, a program can be a service provider, providing a Web service t o dow nst ream consum ers as w ell as a service request or, it self consum ing Web services provided by ot hers.
An SOA also includes t hree operat ions: publish
, find , and bind . These operat ions define t he cont ract s bet w een t he SOA roles:
•
•
The key t o SOA is t he service descript ion. I t is t he service descript ion t hat is published by t he service provider t o t he service regist ry. I t is t he service descript ion t hat is ret rieved by t he service request or as a result of t he find operat ion. I t is a service descript ion t hat t ells t he service request or everyt hing it needs t o know in order t o bind t o or invoke t he Web service provided by t he service provider. The service descript ion also indicat es w hat inform at ion ( if any) is ret urned t o t he service request or as a result of t he Web service invocat ion.
Each t im e a service- orient ed archit ect ure is deployed, t here m ight be different
t echnologies t o fulfill each role. Chapt er 7, " Discovering Web Services," discusses various opt ions for im plem ent ing a service regist ry and goes int o great det ail on t he UDDI
service regist ry t echnology. Chapt er 6, " Describing Web Services," discusses service descript ion and how a service descript ion can be used t o aut om at e t he t ask of building a client - side proxy t o t he Web service and a server- side skelet on t o dispat ch t he Web service invocat ion t o t he t arget Web service im plem ent at ion. Chapt ers 3 and 4, "Sim ple Obj ect Access Prot ocol ( SOAP)" and "Creat ing Web Services," focus on t he use of SOAP t o fulfill t he bind operat ion; Chapt er 5, " Using SOAP for e- Business," det ails how t he bind can be m ade ready for e- business.
An alphabet soup of t echnologies is sw im m ing around t he Web services space. We have XML, SOAP, WSDL, UDDI , WSEL, WSFL, and m ore. How can anyone m ake sense of what t hese t echnologies are and how t hey fit t oget her? Well, t hat is one of t he purposes of t his book.
To help put a fram ew ork around t hese t echnologies, w e refer t o a t rio of Web services int eroperabilit y st acks, first proposed t o t he W3C by I BM and Microsoft in March 2001 (ht t p: / / w w w .w 3.org/ 2001/ 03/ WSWS- popa/ paper51) . This proposal fact ored Web services t echnologies int o t hree st acks:
•
•
•
The cont ent s of t he st acks present ed in t his book reflect a different fact oring t han originally proposed t o t he W3C, due in part t o t he addit ional st andards effort s t hat have com e int o play since March 2001.
The w ire st ack represent s t he t echnologies t hat det erm ine how a m essage is sent from t he service request or t o t he service provider. The base of t he w ire st ack is a net w ork prot ocol. Web services can be based on a variet y of st andard, I nt ernet w ire prot ocols such as HTTP or HTTPS, SMTP, FTP, and so on, as well as sophist icat ed ent erprise- level prot ocols such as RMI / I I OP and MQSeries.
For dat a encoding, Web services use XML. I n addit ion, non- XML cont ent can be
referenced from a Web service invocat ion m essage, allow ing full flexibilit y in t he kinds of dat a used in t he m essage. For dat a specificat ion, Web services use XML Schem a. This includes bot h cust om schem as in t he case of XML m essaging or schem as conform ing t o a set of pre- defined rules, such as t he SOAP encoding rules discussed in Chapt er 3.
Built on t op of t he net w orking prot ocol and dat a- encoding layers are t he XML m essaging layers. For XML m essaging, Web services use SOAP in all it s dat a encoding, int eract ion st yle, and prot ocol binding variat ions. SOAP is used as a sim ple approach t o w rapper an XML m essage in an envelope. The result is a solid, st andards- based foundat ion for Web services.
Concept ually layered on t op of t he SOAP enveloping m echanism is a m echanism for envelope ext ensions called SOAP headers . Wit h SOAP headers, ort hogonal
ext ensions such as a digit al signat ure can be associat ed w it h t he body of t he m essage cont ained w it hin t he SOAP envelope. Chapt er 3 w ill give det ails on t he SOAP enveloping m echanism and t he SOAP header facilit y.
The layers of t his st ack are w ell defined, eit her as st andard net w orking prot ocols or as t he SOAP specificat ion it self. This st ack is t he m ost accept ed and m ost w idely deployed set of t echnologies for Web services.
handful of facet s of Web services t hat can appear at several levels of t he w ire st ack. There is no w ell- accept ed st andard for t hese facet s, but w ork is underw ay in t hese areas.
The w ire st ack is only w here t he capabilit ies of Web services begin. Even t he sim plest exam ple of Web service use show s t he need for a higher level of int eroperabilit y.
Consider t he follow ing sit uat ion ( w e'll see t his exam ple in great er det ail in Chapt er 3) . A com pany has provided an invent ory checking service, allowing cust om ers t o det erm ine w het her a part icular num ber of it em s are in st ock for a given product code ( as
represent ed as a st ock keeping unit [ SKU] ) . The Web service t akes as param et ers a st ring represent ing t he SKU and an int eger represent ing t he num ber of unit s needed. I f t he com pany has on hand t he request ed num ber of unit s, t he Web service responds w it h a Boolean t rue value; ot herw ise, t he response is a Boolean false.
From a pure SOAP perspect ive, t he int eract ion w it h t his Web service is t rivial. How ever, t hings get m uch m ore com plicat ed when we consider how m uch com m on underst anding m ust exist bet w een t he service request or and t he service provider. For t he int eract ion t o succeed, at a m inim um , t he service request or needs t o know t he follow ing:
•
•
•
•
•
•
Throw in securit y, paym ent s, error handling, and ot her capabilit ies required t o build ent erprise- grade Web services, and t he need for shared know ledge expands even
furt her…. How can t he service request or acquire t his inform at ion? Well, t radit ionally Web services have advert ised t heir capabilit ies in som e hum an readable form . Developers have read t he descript ion of t hese capabilit ies and configured user applicat ions t o be able t o com m unicat e w it h part icular Web services.
While t his approach w orks in principle, it is not scalable for m any reasons:
•
•
•
These are som e of t he reasons w hy indust ry leaders are developing t he st andards described in a service descript ion st ack.
Figure 1.3 shows t he service descript ion st ack.
Key t o t he ent ire service- orient ed archit ect ure approach is t he service descript ion it self. Many aspect s of a Web service need t o be com m unicat ed, and t herefore t he descript ion st ack has m ult iple levels. The focus on service descript ion is t o com m unicat e t hose aspect s of a service t hat m ight be im port ant t o t he service request or. Chapt er 6 goes int o det ail on each of t he t echnologies used for service descript ion.
The next t w o levels of t he st ack, service im plem ent at ion and service int erface, are described using t he Web Services Descript ion Language ( WSDL) . WSDL is a not e t o t he W3C, and t here is act ive w ork t o refine t his language int o a st andard. WSDL is t he int erface definit ion language for Web services; it is t he key t o underst anding Web services. Wit h WSDL, a developer describes t he set of operat ions support ed by a Web service, including t he kinds of obj ect s t hat are expect ed as input and out put of t he operat ions, t he various bindings t o concret e net w ork and dat a encoding schem es. This level const it ut es t he core definit ion of t he service's int erface. The service im plem ent at ion defines t he net w ork address w here t he service it self can be invoked. WSDL allow s for aut om at ic code- generat ion of Web service client s based on t his inform at ion.
But I DL is not enough for Web services. Ot her aspect s of t he Web service could affect w het her a service request or w ould choose t o bind t o a Web service. For exam ple, if t w o different service providers host im plem ent at ions of t he sam e service int erface, perhaps a st ock quot e service, t hen from t he I DL perspect ive, t he services are alm ost
indist inguishable: The net w ork address is t he only difference. How ever, t he service providers m ight differ w idely in t heir privacy policy, cost t o use, t im eliness of response, and so on. These non- operat ional charact erist ics m ight be crit ical t o t he service
request or. The role of t he endpoint definit ion is t o layer on t op of t he WSDL descript ion inform at ion about charact erist ics of t he Web service t hat are im pact ed by it s
im plem ent at ion environm ent . Work in t his area is at it s very beginnings. The not ion of a Web Services Endpoint Language ( WSEL) has only been hint ed at publicly. Ot her exam ples of t his sort of descript ion include t he ebXML Collaborat ion- Prot ocol Profile and Agreem ent Specificat ion ( CPP) .
At t he t op of t he service descript ion st ack is t he elusive prom ise of seam less, aut om at ic service int egrat ion: t he service orchest rat ion layer. Wit h service orchest rat ion , t he developer describes how a collect ion of Web services is com bined t o produce a m ore sophist icat ed Web service. For exam ple, you w ould use service orchest rat ion t o m odel how a purchase order subm ission Web service could be com bined wit h a not ificat ion service and a ret urns- processing service t o produce a richer overall purchasing Web service. At t his level, several alt ernat ive approaches exist . I BM has proposed t he Web Services Flow Language, and Microsoft has Xlang. A single st andard has not em erged in t his space.
The orchest rat ion of Web services poses significant challenges from bot h a t echnical and a business perspect ive. On t he t echnical side, seam less service int egrat ion requires a significant t echnological foundat ion. Most im port ant is t he descript ion of service behavior, defined by t he rules for sequencing operat ion invocat ions and for sending and receiving m essages. Next is t he problem of com posing services int o process- based int eract ions. The problem is m ade harder by t he requirem ent t hat som e com posit ion bindings m ust happen at runt im e. Wit hout t his capabilit y, it is difficult t o m ap t he t echnology t o w ell-est ablished business processes such as represent at ion, referral, and brokering. On t he business side, t he problem s are no less significant . From a business perspect ive, service int egrat ion is a w orkflow problem and as such could int roduce dependencies on aspect s of com panies' core business m odels. Part icularly difficult in t his perspect ive is pot ent ially t he m ost valuable t ype of service int egrat ion—t he one t hat spans ent erprise boundaries.
Given t he abilit y t o describe Web services, w e are bet t er off t han w e w ere, but w e st ill have solved only part of t he Web service int egrat ion problem . Service descript ions t ell us how t o bind t o Web services, but how did t he service request or get t he service
Service request ors w ill need w ell- defined find API s. This is t he SOA service regist ry role w e described earlier.
Figure 1.4 show s t he t hird int eroperabilit y st ack, t he discovery st ack. The discovery st ack organizes t echnologies associat ed wit h Web service discovery.
The first level of t he st ack represent s a sim ple inspect ion level. I nspect ion is a t echnique of discovering t he service descript ion given t hat t he det ails about t he service ( a service ident ifier or URL, for exam ple) are already known. Once again, no single st andard exist s in t his space. I BM has ADS and Microsoft has DI SCO . The direct ory level represent s t he capabilit y of discovering Web services and business part ners using a capabilit ies- based lookup. Unlike previous dist ribut ed com put ing
t echniques t hat relied on w ell know n nam es as t he basis for rem ot e discovery of services, Web services can use find t echniques based on t he kind of service or service capabilit ies. The UDDI st andard is t he proposed t echnology for Web services direct ory.
Chapt er 7 is dedicat ed t o explaining service discovery in m uch m ore det ail, and in part icular review ing t he UDDI st andard.
Does any given Web service require all of t hese t echnologies in order t o be considered a Web service? Cert ainly not .
Looking at t he w ire st ack, no single net w ork prot ocol—not even HTTP—is a required part of a Web service; any num ber of net w orking prot ocols can be used. Som e Web services don't even need t o use a net w ork prot ocol. Techniques such as t he Web Services
I nvocat ion Fram ew ork ( WSI F) (ht t p: / / w w w .alphaw orks.ibm .com / t ech/ w sif) discuss t he possibilit y of a Web service being a sim ple Java m et hod invocat ion, w here t he service request or and service provider are in t he sam e Java Virt ual Machine. Moving up t he st ack, we can discover t hat even SOAP is not a necessary t echnology for Web services. I t is possible t hat a com ponent accessed t hrough a sim ple HTTP POST can be considered a Web service. I n t hese cases, t he com m onalit y t hat m akes t hese com ponent s Web services is t he use of WSDL t o describe t he service.
So, is a service descript ion required in order for a com ponent t o be considered a Web service? Again, not necessarily. Many Web services, part icularly older Web services d
