A Young Person's Guide to The Simple Object Access Protocol: SOAP Increases Interoperability Across Platforms and anguages

Don Box This article assumes youre familiar with COM and XML

e!el of "ifficulty
S&''A(Y

Code for this article: SOA !exe "#$%B&

The Sim'le O()ect Access rotocol "SOA & facilitates intero'era(ility amon* a wide ran*e of 'ro*rams and 'latforms+ ma,in* existin* a''lications accessi(le to a (roader ran*e of users! SOA com(ines the 'ro-en .e( technolo*y of /TT with the flexi(ility and extensi(ility of XML! This article ta,es you on a com'rehensi-e tour of O()ect 0 C technolo*y to hel' you understand the foundations of SOA and the ways it o-ercomes many of the limitations of existin* technolo*ies+ includin* DCOM and CO0BA! This is followed (y a detailed treatment of the SOA encodin* rules with a focus on how SOA ma's onto existin* O0 C conce'ts!

hen I began my computing career in 1984, most programmers didnt care about network protocols. However, sometime in the 199 s networking became ubi!uitous, and now its hard to imagine using a computer without some "orm o" connectivity. #oday the average programmer is more interested in building scalable, distributed applications than implementing "loating, semi$transparent, nonrectangular, owner$drawn %oolbars in &'%. (rogrammers pre"er to think in terms o" programming models, not network protocols. #hough thats generally a good thing, in this article Ill discuss the )imple *b+ect ,ccess (rotocol -)*,(., a network protocol that happens to have no e/plicit programming model. #his doesnt mean that the architects o" )*,( -including the author. are out to "undamentally change the way you program. 0ather, one o" the primary goals o" )*,( is to make your e/isting programs more accessible to a broader range o" users. #o this end, there is no )*,( ,(I or )*,( *b+ect 0e!uest 1roker -*01.. Instead, )*,( assumes that you will use as much e/isting technology as possible. )everal ma+or %*01, vendors have committed to support the )*,( protocol in their *01 products. &icroso"t has committed to support )*,( in "uture versions o" %*&. 2evelop&entor has developed re"erence implementations that make )*,( accessible to any 3ava$ language or (erl programmer on any plat"orm. #he guiding principle behind )*,( is to 4"irst invent no new technology.4 )*,( uses two e/isting and widely deployed protocols5 H##( and 6&7. H##( is )*,(s 0(%$style transport, and 6&7 is its encoding scheme. 8ith a "ew lines o" code and an 6&7 parser, H##( servers such as &icroso"t9 Internet In"ormation )erver -II). and ,pache instantly become )*,( *01s. :iven the "act that over hal" o" the planets 8eb tra""ic is directed at II) or ,pache, )*,( bene"its "rom the proven engineering and wide availability o" these two products. #his does not mean, however, that all )*,( re!uests must be routed through a 8eb server. #raditional 8eb servers are +ust one way to dispatch )*,( re!uests. 8eb services like II) or ,pache are su""icient, but by no means necessary "or building )*,($enabled applications. ,s this article will describe, )*,( simply codi"ies the use o" 6&7 as an H##( payload. #he most common application o" )*,( is as a 0emote (rocedure %all -0(%. protocol. #o understand how )*,( works, it is use"ul to take a brie" look into the history o" 0(% protocols. (P)s Throughout *istory #he two dominant communication models "or building distributed applications are message passing -o"ten combined with !ueuing. and re!uest;response. &essage passing systems typically allow any party to send messages at any time. 0e!uest;response protocols restrict the communication pattern to re!uest;response pairs. &essaging$based applications are acutely aware that they are communicating with e/ternal concurrent processes and re!uire an e/plicit design style. 0e!uest;response$based applications more closely resemble a single$process application, since the application that sends the re!uest is more or less blocked until it receives the response "rom the second process. #his makes re!uest;response communications a natural "it "or 0(% applications. 8hile both messaging and re!uest;response have their advantages, either one can be implemented in terms o" the other. &essaging systems can be built using lower$level re!uest;response protocols. 'or e/ample, &icroso"t &essage <ueue )erver -&)&<. uses 2%= 0(% internally "or most o" its control logic. 0(% systems can be built using lower$level messaging systems. &)&< provides a correlation I2 "or e/actly this purpose. 'or better or worse, most applications tend to use 0(% protocols due to their wider availability, simpler design, and natural mapping to traditional programming techni!ues. 2uring the 198 s, the two dominant 0(% protocols were )un 0(% and 2%= 0(%. #he most popular )un 0(% application is the >etwork 'ile )ystem ->'). used by most ?ni/ systems. #he most popular 2%= 0(% application is 8indows >#9, which uses the 2%= 0(% protocol "or a number o" system services. 1oth o" these protocols proved to be !uite "unctional and adaptable to a wide range o" applications. However, as the decade neared an end, the industrys obsession

+or related articles see: htt':11msdn!microsoft!com1xml1*eneral1soa's'ec2-3!as' htt':11www!microsoft!com1mind143441soa'1soa'!as' The author recommends: htt':11www!w#!or*1XML htt':11www!de-elo'!com1soa' ,ac-ground information: The author recommends: IIOP Complete+ .illiam 0uh+ Thomas /erron+ aul %lin,er "Addison .esley&5 Computer Networks+ Andrew Tannen(aum " rentice /all& "on ,o. is a cofounder of De-elo'Mentor+ a COM thin,

tan, that educates the software industry in COM+ MTS+ and ATL! Don wrote Essential COM+ and coauthored the follow2u' Effective COM "Addison2.esley+ 3667&! 0each Don at htt':11www!de-elo'!com1d(ox!

issue of MSD9 Ma*a:ine! ;et it at your local newsstand+ or (etter yet+ subscribe!
8rom the March $444