Yleiskatsaus
Komponenttipohjaisesta ohjelmoinnista on tullut suositumpaa kuin koskaan. Nykyään rakennetaan tuskin sovellusta, jossa ei käytettäisi komponentteja jossakin muodossa, yleensä eri valmistajilta. Sovellusten kehittyessä yhä monimutkaisemmiksi on myös kasvanut tarve hyödyntää etäkoneisiin hajautettuja komponentteja.
Esimerkki komponenttipohjaisesta sovelluksesta on kokonaisvaltainen sähköisen kaupankäynnin ratkaisu. Web-farmilla sijaitsevan sähköisen kaupankäynnin sovelluksen on lähetettävä tilauksia taustajärjestelmän toiminnanohjaussovellukseen (ERP). Monissa tapauksissa ERP-sovellus sijaitsee eri laitteistossa ja saattaa toimia eri käyttöjärjestelmässä.
Microsoftin Distributed Component Object Model (DCOM) on hajautettu objekti-infrastruktuuri, jonka avulla sovellus voi kutsua toiseen palvelimeen asennettuja Component Object Model (COM) -komponentteja, ja se on siirretty useille muille kuin Windows-alustoille. DCOM ei kuitenkaan ole koskaan saanut laajaa hyväksyntää näillä alustoilla, joten sitä käytetään harvoin helpottamaan Windows- ja muiden kuin Windows-tietokoneiden välistä viestintää. Toiminnanohjausohjelmistojen toimittajat luovat usein Windows-alustalle komponentteja, jotka kommunikoivat taustajärjestelmän kanssa oman protokollan avulla.
Jotkin sähköisen kaupankäynnin sovelluksen käyttämät palvelut eivät välttämättä sijaitse lainkaan datakeskuksessa. Jos sähköisen kaupankäynnin sovellus esimerkiksi hyväksyy luottokorttimaksun asiakkaan ostamista tavaroista, sen on käytettävä kauppapankin palveluja asiakkaan luottokorttitietojen käsittelyyn. Käytännössä DCOM ja siihen liittyvät tekniikat, kuten CORBA ja Java RMI, rajoittuvat kuitenkin sovelluksiin ja komponentteihin, jotka on asennettu yrityksen datakeskukseen. Kaksi tärkeintä syytä tähän on se, että nämä tekniikat käyttävät oletusarvoisesti omia protokollia ja että nämä protokollat ovat luonnostaan yhteyspainotteisia.
Internetin kautta palvelimen kanssa kommunikoivilla asiakkailla on lukuisia mahdollisia esteitä yhteydenpidossa palvelimen kanssa. Tietoturvatietoiset verkonvalvojat ympäri maailmaa ovat ottaneet käyttöön yritysreitittimiä ja palomuureja, jotka estävät käytännössä kaikenlaisen Internetin kautta tapahtuvan viestinnän. Tarvitaan usein jumalan teko, jotta verkonvalvoja saa avattua portteja enemmän kuin välttämättömät portit.
Jos olet onnekas ja saat verkonvalvojan avaamaan asianmukaiset portit palvelusi tueksi, asiakkaasi eivät todennäköisesti ole yhtä onnekkaita. Tämän vuoksi DCOM:n, CORBA:n ja Java RMI:n kaltaiset omat protokollat eivät ole käytännöllisiä Internet-skenaarioissa.
Kuten sanoin, toinen ongelma näissä tekniikoissa on se, että ne ovat luonnostaan yhteyspainotteisia eivätkä siksi pysty käsittelemään verkon keskeytyksiä sujuvasti. Koska Internet ei ole suorassa hallinnassasi, et voi tehdä oletuksia yhteyden laadusta tai luotettavuudesta. Jos verkkoon tulee katkos, asiakkaan seuraava kutsu palvelimelle saattaa epäonnistua.
Näiden tekniikoiden yhteyspainotteinen luonne tekee myös haasteelliseksi rakentaa suuren skaalautuvuuden saavuttamiseksi tarvittavia kuormitustasapainotettuja infrastruktuureja. Kun asiakkaan ja palvelimen välinen yhteys katkeaa, seuraavaa pyyntöä ei voi yksinkertaisesti ohjata toiselle palvelimelle.
Kehittäjät ovat yrittäneet voittaa nämä rajoitukset hyödyntämällä mallia nimeltä valtioton ohjelmointi, mutta niiden menestys on ollut rajallista, koska tekniikat ovat melko raskaita ja yhteyden muodostaminen etäobjektiin on kallista.
Koska asiakkaan luottokortin käsittely tapahtuu Internetissä sijaitsevalla etäpalvelimella, DCOM ei ole ihanteellinen väline sähköisen kaupankäynnin asiakkaan ja luottokortin käsittelypalvelimen välisen viestinnän helpottamiseksi. Kuten toiminnanohjausratkaisussa, kolmannen osapuolen komponentti asennetaan usein asiakkaan datakeskukseen (tässä tapauksessa luottokorttien käsittelyratkaisun tarjoajan toimesta). Tämä komponentti toimii vain välittäjänä, joka helpottaa sähköisen kaupankäynnin ohjelmiston ja kauppapankin välistä viestintää oman protokollan avulla.
Näetkö tässä kaavaa? Koska nykyisten tekniikoiden rajoitukset tietokonejärjestelmien välisen viestinnän helpottamisessa ovat olleet rajalliset, ohjelmistojen toimittajat ovat usein turvautuneet oman infrastruktuurinsa rakentamiseen. Tämä tarkoittaa, että resurssit, joita olisi voitu käyttää toiminnanohjausjärjestelmän tai luottokorttien käsittelyjärjestelmän toimintojen parantamiseen, on sen sijaan käytetty omien verkkoprotokollien kirjoittamiseen.
Pyrkiessään tukemaan paremmin tällaisia Internet-skenaarioita Microsoft otti aluksi käyttöön strategian, jossa se täydensi olemassa olevia tekniikoitaan, kuten COM Internet Services (CIS), jonka avulla voit luoda DCOM-yhteyden asiakkaan ja etäosan välille portin 80 kautta. Eri syistä CIS:tä ei hyväksytty laajalti.
Tuli selväksi, että tarvittiin uusi lähestymistapa. Niinpä Microsoft päätti ratkaista ongelman alhaalta ylöspäin. Tarkastellaan joitakin vaatimuksia, jotka ratkaisun oli täytettävä menestyäkseen.
- Yhteentoimivuus Muilla alustoilla olevien asiakkaiden on voitava käyttää etäpalvelua.
- Internet-ystävällisyys Ratkaisun pitäisi toimia hyvin sellaisten asiakkaiden tukemisessa, jotka käyttävät etäpalvelua Internetistä.
- Vahvasti tyypitetyt rajapinnat Etäpalveluun lähetettävien ja sieltä vastaanotettavien tietojen tyypistä ei saa olla epäselvyyttä. Lisäksi etäpalvelun määrittelemien tietotyyppien pitäisi sopia kohtuullisen hyvin useimpien proseduraalisten ohjelmointikielten määrittelemiin tietotyyppeihin.
- Kyky hyödyntää nykyisiä Internet-standardeja Etäpalvelun toteutuksessa olisi hyödynnettävä mahdollisimman paljon nykyisiä Internet-standardeja ja vältettävä keksimästä uudelleen ratkaisuja jo ratkaistuihin ongelmiin. Laajasti hyväksyttyihin Internet-standardeihin perustuvassa ratkaisussa voidaan hyödyntää olemassa olevia työkaluja ja teknologiaa varten luotuja tuotteita.
- Tuki mille tahansa kielelle Ratkaisun ei pitäisi olla tiukasti sidottu tiettyyn ohjelmointikieleen. Esimerkiksi Java RMI on tiukasti sidottu Java-kieleen. Visual Basicista tai Perlistä olisi vaikea kutsua toiminnallisuutta etä-Java-objektiin. Asiakkaan pitäisi pystyä toteuttamaan uusi verkkopalvelu tai käyttämään olemassa olevaa verkkopalvelua riippumatta siitä, millä ohjelmointikielellä asiakas on kirjoitettu.
- Tuki mille tahansa hajautetulle komponentti-infrastruktuurille Ratkaisun ei pitäisi olla tiukasti sidottu tiettyyn komponentti-infrastruktuuriin. Itse asiassa sinun ei pitäisi joutua hankkimaan, asentamaan tai ylläpitämään hajautettua objekti-infrastruktuuria vain rakentaaksesi uuden etäpalvelun tai kuluttaaksesi olemassa olevaa palvelua. Taustalla olevien protokollien pitäisi helpottaa olemassa olevien hajautettujen olioinfrastruktuurien, kuten DCOM:n ja CORBA:n, välistä perusyhteyttä.
Tämän kirjan otsikon perusteella ei liene yllätys, että Microsoftin luoma ratkaisu tunnetaan nimellä Verkkopalvelut. Verkkopalvelu tarjoaa rajapinnan, jonka avulla tietty toiminto voidaan käynnistää asiakkaan puolesta. Asiakas voi käyttää verkkopalvelua Internet-standardien avulla.
Verkkopalvelujen rakennuspalikat
Seuraavassa kuvassa on esitetty kahden sovelluksen välisen etäyhteyden mahdollistamiseen tarvittavat keskeiset rakennuspalikat.
Keskustellaanpa kunkin rakennuspalikan tarkoituksesta. Koska moni lukija tuntee DCOM:n, mainitsen myös kunkin rakennuspalikan DCOM-ekvivalentin.
- Discovery Asiakassovellus, joka tarvitsee pääsyn verkkopalvelun tarjoamiin toimintoihin, tarvitsee keinon selvittää etäpalvelun sijainti. Tämä tapahtuu prosessin avulla, jota kutsutaan yleisesti nimellä löytö. Löytämistä voidaan helpottaa keskitetyn hakemiston avulla sekä tapauskohtaisemmilla menetelmillä. DCOM:ssä Service Control Manager (SCM) tarjoaa löytöpalveluja.
- Kuvaus Kun tietyn verkkopalvelun päätepiste on määritetty, asiakas tarvitsee riittävästi tietoa voidakseen toimia sen kanssa asianmukaisesti. Web-palvelun kuvaus sisältää jäsenneltyä metatietoa rajapinnasta, jota asiakassovelluksen on tarkoitus käyttää, sekä kirjallista dokumentaatiota Web-palvelusta, mukaan lukien käyttöesimerkkejä. DCOM-komponentti paljastaa rajapinnoistaan strukturoitua metatietoa tyyppikirjaston (typelib) kautta. Komponentin typelibin sisältämä metatieto on tallennettu omaan binäärimuotoon, ja sitä käytetään oman sovellusohjelmointirajapinnan (API) kautta.
- Viestin muoto Tietojen vaihtamiseksi asiakkaan ja palvelimen on sovittava yhteisestä tavasta koodata ja muotoilla viestit. Vakioitu tapa koodata tietoja varmistaa, että palvelin tulkitsee asiakkaan koodaamat tiedot oikein. DCOM:ssä asiakkaan ja palvelimen väliset viestit muotoillaan DCOM Object RPC (ORPC) -protokollassa määritellyllä tavalla.
Ilman vakiomuotoista tapaa muotoilla viestit on lähes mahdotonta kehittää työkaluja, joilla kehittäjät voidaan irrottaa taustalla olevista protokollista. Kun kehittäjän ja taustalla olevien protokollien väliin luodaan abstraktiokerros, kehittäjä voi keskittyä enemmän käsillä olevaan liiketoimintaongelmaan ja vähemmän ratkaisun toteuttamiseen tarvittavaan infrastruktuuriin.
- Koodaus Asiakkaan ja palvelimen välillä lähetettävät tiedot on koodattava viestin runkoon. DCOM käyttää binäärikoodausjärjestelmää asiakkaan ja palvelimen välillä vaihdettujen parametrien sisältämien tietojen sarjallistamiseen.
- Liikenne Kun viesti on muotoiltu ja tiedot sarjallistettu viestin runkoon, viesti on siirrettävä asiakkaan ja palvelimen välillä jonkin siirtoprotokollan välityksellä. DCOM tukee useita omia protokollia, jotka on sidottu useisiin verkkoprotokolliin, kuten TCP:hen, SPX:ään, NetBEUI:hin ja NetBIOS over IPX:ään.
Verkkopalvelujen suunnittelupäätökset
Keskustellaanpa näistä verkkopalvelujen rakennuspalikoista ja niiden taustalla olevista suunnittelupäätöksistä.
Siirtoprotokollien valitseminen
Ensimmäiseksi määritettiin, miten asiakas ja palvelin kommunikoivat keskenään. Asiakas ja palvelin voivat sijaita samassa lähiverkossa, mutta asiakas voi mahdollisesti kommunikoida palvelimen kanssa Internetin kautta. Siksi siirtoprotokollan on sovelluttava yhtä hyvin lähiverkko- ja Internet-ympäristöihin.
Kuten aiemmin mainitsin, DCOM:n, CORBA:n ja Java RMI:n kaltaiset tekniikat soveltuvat huonosti tukemaan asiakkaan ja palvelimen välistä tiedonsiirtoa Internetissä. HTTP-protokollan (Hypertext Transfer Protocol) ja SMTP-protokollan (Simple Mail Transfer Protocol) kaltaiset protokollat ovat hyväksi havaittuja Internet-protokollia. HTTP määrittelee pyyntö-vastaus-viestintämallin pyynnön lähettämistä ja siihen liittyvän vastauksen saamista varten. SMTP määrittelee reititettävän viestiprotokollan asynkronista viestintää varten. Tarkastellaan, miksi HTTP ja SMTP soveltuvat hyvin Internetiin.
HTTP-pohjaiset verkkosovellukset ovat luonnostaan tilattomia. Ne eivät perustu jatkuvaan yhteyteen asiakkaan ja palvelimen välillä. Tämä tekee HTTP:stä ihanteellisen protokollan korkean käytettävyyden kokoonpanoihin, kuten palomuureihin. Jos asiakkaan alkuperäisen pyynnön käsitellyt palvelin ei ole käytettävissä, seuraavat pyynnöt voidaan ohjata automaattisesti toiselle palvelimelle asiakkaan tietämättä tai välittämättä siitä.
Lähes kaikilla yrityksillä on käytössä SMTP:tä tukeva infrastruktuuri. SMTP soveltuu hyvin asynkroniseen viestintään. Jos palvelu häiriintyy, sähköposti-infrastruktuuri huolehtii automaattisesti uusintayrityksistä. Toisin kuin HTTP:ssä, SMTP-viestejä voi välittää paikalliselle sähköpostipalvelimelle, joka yrittää toimittaa sähköpostiviestin puolestasi.
Sekä HTTP:n että SMTP:n toinen merkittävä etu on niiden yleisyys. Työntekijät ovat tottuneet luottamaan sekä sähköpostiin että verkkoselaimiin, ja verkon ylläpitäjät tukevat näitä palveluita hyvin mielellään. NAT:n (network address translation) ja välityspalvelimien kaltaiset tekniikat tarjoavat mahdollisuuden käyttää Internetiä HTTP:n kautta muutoin eristetyistä lähiverkoista käsin. Järjestelmänvalvojat käyttävät usein palomuurin sisällä olevaa SMTP-palvelinta. Tälle palvelimelle lähetetyt viestit ohjataan sitten lopulliseen määränpäähänsä Internetin kautta.
Luottokorttien käsittelyohjelmiston tapauksessa kauppapankilta tarvitaan välitön vastaus, jotta voidaan päättää, onko tilaus toimitettava toiminnanohjausjärjestelmään. HTTP soveltuu hyvin tähän tehtävään pyyntö/vastaus-sanomamallinsa ansiosta.
Useimmat toiminnanohjausohjelmistopaketit eivät pysty käsittelemään suuria tilausmääriä, joita sähköisen kaupankäynnin sovelluksesta voidaan mahdollisesti saada. Lisäksi tilauksia ei ole välttämätöntä toimittaa toiminnanohjausjärjestelmään reaaliajassa. Siksi SMTP:tä voidaan käyttää tilausten jonottamiseen, jotta ERP-järjestelmä voi käsitellä ne sarjakäsittelyssä.
Jos toiminnanohjausjärjestelmä tukee hajautettuja tapahtumia, toinen vaihtoehto on käyttää Microsoft Message Queue Server (MSMQ) -palvelinta. Niin kauan kuin sähköisen kaupankäynnin sovellus ja toiminnanohjausjärjestelmä sijaitsevat samassa lähiverkossa, yhteys muiden kuin Internet-protokollien välityksellä ei ole ongelma. MSMQ:n etuna SMTP:hen verrattuna on se, että viestejä voidaan asettaa jonoon ja poistaa jonosta tapahtuman puitteissa. Jos jonosta poistetun viestin käsittelyyritys epäonnistuu, viesti asetetaan automaattisesti takaisin jonoon, kun tapahtuma keskeytyy.
Koodausjärjestelmän valinta
HTTP ja SMTP tarjoavat keinon lähettää tietoja asiakkaan ja palvelimen välillä. Kumpikaan ei kuitenkaan määritä, miten viestin rungon sisältämä tieto tulisi koodata. Microsoft tarvitsi vakiomuotoisen, alustariippumattoman tavan koodata asiakkaan ja palvelimen välillä vaihdettavat tiedot.
Koska tavoitteena oli hyödyntää Internet-pohjaisia protokollia, XML (Extensible Markup Language) oli luonnollinen valinta. XML tarjoaa monia etuja, kuten alustarajat ylittävän tuen, yhteisen tyyppijärjestelmän ja tuen alan standardimerkistöille.
DCOM:n, CORBA:n ja Java RMI:n kaltaisissa binäärikoodausjärjestelmissä on otettava huomioon eri laitteistoalustojen yhteensopivuusongelmat. Esimerkiksi eri laitteistoalustoilla on erilaiset sisäiset binääriset esitystavat usean tavun numeroille. Intel-alustat järjestävät usean tavun numeron tavut käyttäen little endian -käytäntöä, kun taas monet RISC-prosessorit järjestävät usean tavun numeron tavut käyttäen big endian -käytäntöä.
XML:ssä vältetään binäärikoodaukseen liittyvät ongelmat, koska siinä käytetään tekstipohjaista koodausjärjestelmää, joka hyödyntää standardimerkistöjä. Lisäksi jotkin siirtoprotokollat, kuten SMTP, voivat sisältää vain tekstipohjaisia viestejä.
Binääriset koodausmenetelmät, kuten DCOM:n ja CORBA:n käyttämät, ovat hankalia, ja ne vaativat tuki-infrastruktuurin, joka irrottaa kehittäjän yksityiskohdista. XML on paljon kevyempi ja helpompi käsitellä, koska se voidaan luoda ja käyttää tavallisilla tekstin jäsentämistekniikoilla.
Lisäksi saatavilla on erilaisia XML-jäsennimiä, jotka yksinkertaistavat XML-dokumenttien luomista ja käyttämistä käytännössä kaikilla nykyaikaisilla alustoilla. XML on kevyt ja sillä on erinomainen työkalutuki, joten XML-koodaus mahdollistaa uskomattoman laajuuden, koska käytännössä mikä tahansa asiakas millä tahansa alustalla voi kommunikoida verkkopalvelusi kanssa.
Muotoilusopimuksen valitseminen
Usein on tarpeen sisällyttää viestin runkoon lisää metatietoja. Voit esimerkiksi haluta sisällyttää tietoja siitä, minkä tyyppisiä palveluja verkkopalvelun on tarjottava, jotta pyyntösi voidaan täyttää, kuten ilmoittautuminen tapahtumaan tai reititystiedot. XML ei tarjoa mekanismia viestin rungon erottamiseksi siihen liittyvistä tiedoista.
HTTP:n kaltaiset siirtoprotokollat tarjoavat laajennettavissa olevan mekanismin otsikkotietoja varten, mutta jotkin viestiin liittyvät tiedot eivät välttämättä ole siirtoprotokollakohtaisia. Asiakas voi esimerkiksi lähettää viestin, joka on reititettävä useisiin kohteisiin, mahdollisesti eri siirtoprotokollien kautta. Jos reititystiedot sijoitettaisiin HTTP-otsikkoon, ne olisi käännettävä ennen kuin ne lähetetään seuraavalle välittäjälle toisen siirtoprotokollan, kuten SMTP:n, kautta. Koska reititystieto liittyy viestiin eikä siirtoprotokollaan, sen pitäisi olla osa viestiä.
SOAP (Simple Object Access Protocol) tarjoaa protokollasta riippumattoman keinon yhdistää otsikkotiedot viestin runkoon. Jokaisessa SOAP-sanomassa on määriteltävä kirjekuori. Kirjekuoressa on runko, joka sisältää viestin hyötykuorman, ja otsikko, joka voi sisältää viestiin liittyvää metatietoa.
SOAP ei aseta rajoituksia viestirungon muotoilulle. Tämä on mahdollinen huolenaihe, koska ilman johdonmukaista tapaa koodata tiedot on vaikea kehittää työkaluja, jotka irrottavat sinut taustalla olevista protokollista. Saatat joutua käyttämään melko paljon aikaa Web-palvelun käyttöliittymän opetteluun sen sijaan, että ratkaisisit käsillä olevan liiketoimintaongelman.
Tarvittiin vakiomuotoinen tapa muotoilla RPC-sanoma (Remote Procedure Call) ja koodata sen parametrien luettelo. SOAP-määrittelyn kohdassa 7 tarjotaan juuri tämä. Siinä kuvataan vakiomuotoinen nimeämiskäytäntö ja koodaustyyli menettelytapasuuntautuneille viesteille.
Koska SOAP tarjoaa vakiomuodon tietojen sarjallistamiseen XML-viestiksi, ASP.NETin ja Remotingin kaltaiset alustat voivat abstrahoida yksityiskohdat puolestasi.
Kuvausmekanismien valinta
SOAP tarjoaa vakiomuotoisen tavan muotoilla verkkopalvelun ja asiakkaan välillä vaihdettavat viestit. Asiakas tarvitsee kuitenkin lisätietoja, jotta se voi sarjallistaa pyynnön ja tulkita vastauksen oikein. XML-skeema tarjoaa keinon luoda skeemoja, joita voidaan käyttää viestin sisällön kuvaamiseen.
XML Schema tarjoaa keskeisen joukon sisäänrakennettuja tietotyyppejä, joita voidaan käyttää viestin sisällön kuvaamiseen. Voit myös luoda omia tietotyyppejä. Esimerkiksi kauppapankki voi luoda monimutkaisen tietotyypin kuvaamaan luottokorttimaksupyynnön lähettämiseen käytettävän viestin rungon sisältöä ja rakennetta.
Skeema sisältää joukon tietotyyppi- ja elementtimäärityksiä. Verkkopalvelu käyttää skeemaa paitsi viestin sisältämien tietotyyppien ilmoittamiseen myös saapuvien ja lähtevien viestien validointiin.
Pelkkä skeema ei kuitenkaan tarjoa riittävästi tietoa verkkopalvelun tehokkaaseen kuvaamiseen. Skeema ei kuvaa asiakkaan ja palvelimen välisiä viestimalleja. Asiakkaan on esimerkiksi tiedettävä, voiko hän odottaa vastausta, kun tilaus lähetetään toiminnanohjausjärjestelmään. Asiakkaan on myös tiedettävä, minkä siirtoprotokollan kautta verkkopalvelu odottaa vastaanottavansa pyyntöjä. Lisäksi asiakkaan on tiedettävä osoite, josta verkkopalvelu on tavoitettavissa.
Nämä tiedot annetaan WSDL-asiakirjassa (Web Services Description Language). WSDL on XML-dokumentti, joka kuvaa täysin tietyn verkkopalvelun. Työkalut, kuten ASP.NET WSDL.exe ja Remoting SOAPSUDS.exe, voivat käyttää WSDL:ää ja rakentaa automaattisesti välityspalvelimia kehittäjän puolesta.
Kuten minkä tahansa ohjelmiston rakentamiseen käytettävän komponentin kohdalla, myös verkkopalvelun mukana tulisi olla kirjallinen dokumentaatio kehittäjille, jotka ohjelmoivat verkkopalvelua vastaan. Dokumentaatiossa tulisi kuvata, mitä verkkopalvelu tekee, mitä rajapintoja se tarjoaa ja joitakin esimerkkejä sen käytöstä. Hyvä dokumentaatio on erityisen tärkeää, jos verkkopalvelu on avoin asiakkaille Internetin kautta.
Löytämismekanismien valinta
Kun olet kehittänyt ja dokumentoinut verkkopalvelun, miten potentiaaliset asiakkaat voivat löytää sen? Jos verkkopalvelu on suunniteltu siten, että sitä voi käyttää kehitystiimisi jäsen, lähestymistapa voi olla melko epävirallinen, kuten WSDL-dokumentin URL-osoitteen jakaminen parin pöydän päässä olevan kollegan kanssa. Mutta kun potentiaaliset asiakkaat ovat Internetissä, verkkopalvelun tehokas mainostaminen on aivan eri asia.
Tarvitaan yhteinen tapa mainostaa verkkopalveluja. Universal Description, Discovery and Integration (UDDI) tarjoaa juuri tällaisen mekanismin. UDDI on teollisuusstandardin mukainen keskitetty hakemistopalvelu, jota voidaan käyttää verkkopalvelujen mainostamiseen ja paikantamiseen. UDDI:n avulla käyttäjät voivat hakea verkkopalveluja käyttämällä useita hakuehtoja, kuten yrityksen nimeä, luokkaa ja verkkopalvelun tyyppiä.
Verkkopalveluja voidaan mainostaa myös DISCO:n avulla, joka on Microsoftin määrittelemä oma XML-dokumenttiformaatti, jonka avulla verkkosivut voivat mainostaa tarjoamiaan palveluja. DISCO määrittelee yksinkertaisen protokollan, jolla helpotetaan resurssien paikantamista hyperlinkkien avulla. DISCO:n ensisijainen käyttäjä on Microsoft Visual Studio.NET. Kehittäjä voi kohdistaa toimintonsa tiettyyn Web-palvelimeen ja selata palvelimen tarjoamia eri Web-palveluja.
Mitä verkkopalveluista puuttuu?
Olet ehkä huomannut, että joitakin hajautetun komponentti-infrastruktuurin keskeisiä osia ei ole määritelty verkkopalveluissa. Kaksi huomattavinta puutetta ovat hyvin määritelty sovellusliittymä Web-palvelujen luomista ja käyttämistä varten sekä joukko komponenttipalveluja, kuten tuki hajautetuille transaktioille. Keskustellaan näistä puuttuvista osista.
- Verkkopalvelukohtainen API Useimmissa hajautetuissa komponentti-infrastruktuureissa määritellään sovellusliittymä, jonka avulla voidaan suorittaa sellaisia tehtäviä kuin suoritusajan alustaminen, komponentin instanssin luominen ja komponentin kuvaamiseen käytettyjen metatietojen heijastaminen. Koska useimmat korkean tason ohjelmointikielet tarjoavat jonkinasteista yhteentoimivuutta C-kielen kanssa, API on yleensä esitetty yhtenäisenä joukkona C-metodien allekirjoituksia. RMI:ssä on jopa niin pitkälle menty, että sen API on tiukasti sidottu yhteen ainoaan korkean tason kieleen, Javaan.
Pyrkiessään varmistamaan, että verkkopalvelut ovat ohjelmointikielistä riippumattomia, Microsoft on jättänyt yksittäisten ohjelmistotoimittajien tehtäväksi sitoa verkkopalvelutuki tiettyyn alustaan. Käsittelen myöhemmin kirjassa kahta Web-palvelutoteutusta.NET-alustalle, ASP.NET ja Remoting.
- Komponenttipalvelut Verkkopalvelualusta ei tarjoa monia hajautetuissa komponentti-infrastruktuureissa yleisesti esiintyviä palveluja, kuten objektien käyttöiän etähallintaa, objektien yhdistämistä ja hajautettujen transaktioiden tukemista. Näiden palvelujen toteuttaminen on jätetty hajautetun komponentti-infrastruktuurin tehtäväksi.
Jotkin palvelut, kuten tuki hajautetuille tapahtumille, voidaan ottaa käyttöön myöhemmin, kun tekniikka kehittyy. Toisia, kuten objektien yhteiskäyttöä ja mahdollisesti objektien käyttöiän hallintaa, voidaan pitää alustan toteutuksen yksityiskohtana. Esimerkiksi Remoting määrittelee laajennuksia, jotka tukevat objektien elinkaaren hallintaa, ja Microsoft Component Services tukee objektien yhdistämistä.
Yhteenveto
Komponenttipohjainen ohjelmointi on osoittautunut kehittäjien tuottavuutta parantavaksi, mutta joitakin palveluja ei voida kapseloida asiakkaan tietokeskuksessa sijaitsevaan komponenttiin. DCOM:n, CORBA:n ja Java RMI:n kaltaiset vanhat tekniikat eivät sovellu siihen, että asiakkaat voisivat käyttää palveluja Internetin kautta, joten Microsoft katsoi tarpeelliseksi aloittaa alusta ja rakentaa alan standardin mukaisen tavan käyttää etäpalveluja.
Verkkopalvelut on sateenvarjotermi, joka kuvaa kokoelmaa alan standardiprotokollia ja -palveluja, joita käytetään helpottamaan sovellusten yhteentoimivuuden perustasoa. Web-palvelut ovat saaneet ennennäkemättömän paljon tukea teollisuudelta. Koskaan aikaisemmin ei ole näin monet johtavat teknologiayritykset tukeneet standardia, joka helpottaa sovellusten yhteentoimivuutta riippumatta siitä, millä alustalla niitä käytetään.
Yksi verkkopalvelujen menestykseen vaikuttavista tekijöistä on se, että ne perustuvat olemassa oleviin Internet-standardeihin, kuten XML:ään ja HTTP:hen. Näin ollen mikä tahansa järjestelmä, joka pystyy jäsentämään tekstiä ja kommunikoimaan standardoidun Internetin siirtoprotokollan kautta, voi kommunikoida verkkopalvelun kanssa. Yritykset voivat myös hyödyntää investointeja, joita ne ovat jo tehneet näihin teknologioihin.