Yleiskatsaus<\/b>
\nKomponenttipohjaisesta ohjelmoinnista on tullut suositumpaa kuin koskaan. Nyky\u00e4\u00e4n rakennetaan tuskin sovellusta, jossa ei k\u00e4ytett\u00e4isi komponentteja jossakin muodossa, yleens\u00e4 eri valmistajilta. Sovellusten kehittyess\u00e4 yh\u00e4 monimutkaisemmiksi on my\u00f6s kasvanut tarve hy\u00f6dynt\u00e4\u00e4 et\u00e4koneisiin hajautettuja komponentteja.<\/p>\n
<\/p>\n
Esimerkki komponenttipohjaisesta sovelluksesta on kokonaisvaltainen s\u00e4hk\u00f6isen kaupank\u00e4ynnin ratkaisu. Web-farmilla sijaitsevan s\u00e4hk\u00f6isen kaupank\u00e4ynnin sovelluksen on l\u00e4hetett\u00e4v\u00e4 tilauksia taustaj\u00e4rjestelm\u00e4n toiminnanohjaussovellukseen (ERP). Monissa tapauksissa ERP-sovellus sijaitsee eri laitteistossa ja saattaa toimia eri k\u00e4ytt\u00f6j\u00e4rjestelm\u00e4ss\u00e4.<\/p>\n
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\u00e4ksynt\u00e4\u00e4 n\u00e4ill\u00e4 alustoilla, joten sit\u00e4 k\u00e4ytet\u00e4\u00e4n harvoin helpottamaan Windows- ja muiden kuin Windows-tietokoneiden v\u00e4list\u00e4 viestint\u00e4\u00e4. Toiminnanohjausohjelmistojen toimittajat luovat usein Windows-alustalle komponentteja, jotka kommunikoivat taustaj\u00e4rjestelm\u00e4n kanssa oman protokollan avulla.<\/p>\n
Jotkin s\u00e4hk\u00f6isen kaupank\u00e4ynnin sovelluksen k\u00e4ytt\u00e4m\u00e4t palvelut eiv\u00e4t v\u00e4ltt\u00e4m\u00e4tt\u00e4 sijaitse lainkaan datakeskuksessa. Jos s\u00e4hk\u00f6isen kaupank\u00e4ynnin sovellus esimerkiksi hyv\u00e4ksyy luottokorttimaksun asiakkaan ostamista tavaroista, sen on k\u00e4ytett\u00e4v\u00e4 kauppapankin palveluja asiakkaan luottokorttitietojen k\u00e4sittelyyn. K\u00e4yt\u00e4nn\u00f6ss\u00e4 DCOM ja siihen liittyv\u00e4t tekniikat, kuten CORBA ja Java RMI, rajoittuvat kuitenkin sovelluksiin ja komponentteihin, jotka on asennettu yrityksen datakeskukseen. Kaksi t\u00e4rkeint\u00e4 syyt\u00e4 t\u00e4h\u00e4n on se, ett\u00e4 n\u00e4m\u00e4 tekniikat k\u00e4ytt\u00e4v\u00e4t oletusarvoisesti omia protokollia ja ett\u00e4 n\u00e4m\u00e4 protokollat ovat luonnostaan yhteyspainotteisia.<\/p>\n
Internetin kautta palvelimen kanssa kommunikoivilla asiakkailla on lukuisia mahdollisia esteit\u00e4 yhteydenpidossa palvelimen kanssa. Tietoturvatietoiset verkonvalvojat ymp\u00e4ri maailmaa ovat ottaneet k\u00e4ytt\u00f6\u00f6n yritysreitittimi\u00e4 ja palomuureja, jotka est\u00e4v\u00e4t k\u00e4yt\u00e4nn\u00f6ss\u00e4 kaikenlaisen Internetin kautta tapahtuvan viestinn\u00e4n. Tarvitaan usein jumalan teko, jotta verkonvalvoja saa avattua portteja enemm\u00e4n kuin v\u00e4ltt\u00e4m\u00e4tt\u00f6m\u00e4t portit.<\/p>\n
Jos olet onnekas ja saat verkonvalvojan avaamaan asianmukaiset portit palvelusi tueksi, asiakkaasi eiv\u00e4t todenn\u00e4k\u00f6isesti ole yht\u00e4 onnekkaita. T\u00e4m\u00e4n vuoksi DCOM:n, CORBA:n ja Java RMI:n kaltaiset omat protokollat eiv\u00e4t ole k\u00e4yt\u00e4nn\u00f6llisi\u00e4 Internet-skenaarioissa.<\/p>\n
Kuten sanoin, toinen ongelma n\u00e4iss\u00e4 tekniikoissa on se, ett\u00e4 ne ovat luonnostaan yhteyspainotteisia eiv\u00e4tk\u00e4 siksi pysty k\u00e4sittelem\u00e4\u00e4n verkon keskeytyksi\u00e4 sujuvasti. Koska Internet ei ole suorassa hallinnassasi, et voi tehd\u00e4 oletuksia yhteyden laadusta tai luotettavuudesta. Jos verkkoon tulee katkos, asiakkaan seuraava kutsu palvelimelle saattaa ep\u00e4onnistua.<\/p>\n
N\u00e4iden tekniikoiden yhteyspainotteinen luonne tekee my\u00f6s haasteelliseksi rakentaa suuren skaalautuvuuden saavuttamiseksi tarvittavia kuormitustasapainotettuja infrastruktuureja. Kun asiakkaan ja palvelimen v\u00e4linen yhteys katkeaa, seuraavaa pyynt\u00f6\u00e4 ei voi yksinkertaisesti ohjata toiselle palvelimelle.<\/p>\n
Kehitt\u00e4j\u00e4t ovat yritt\u00e4neet voittaa n\u00e4m\u00e4 rajoitukset hy\u00f6dynt\u00e4m\u00e4ll\u00e4 mallia nimelt\u00e4 valtioton <\/i>ohjelmointi<\/i>, mutta niiden menestys on ollut rajallista, koska tekniikat ovat melko raskaita ja yhteyden muodostaminen et\u00e4objektiin on kallista.<\/p>\n
Koska asiakkaan luottokortin k\u00e4sittely tapahtuu Internetiss\u00e4 sijaitsevalla et\u00e4palvelimella, DCOM ei ole ihanteellinen v\u00e4line s\u00e4hk\u00f6isen kaupank\u00e4ynnin asiakkaan ja luottokortin k\u00e4sittelypalvelimen v\u00e4lisen viestinn\u00e4n helpottamiseksi. Kuten toiminnanohjausratkaisussa, kolmannen osapuolen komponentti asennetaan usein asiakkaan datakeskukseen (t\u00e4ss\u00e4 tapauksessa luottokorttien k\u00e4sittelyratkaisun tarjoajan toimesta). T\u00e4m\u00e4 komponentti toimii vain v\u00e4litt\u00e4j\u00e4n\u00e4, joka helpottaa s\u00e4hk\u00f6isen kaupank\u00e4ynnin ohjelmiston ja kauppapankin v\u00e4list\u00e4 viestint\u00e4\u00e4 oman protokollan avulla.<\/p>\n
N\u00e4etk\u00f6 t\u00e4ss\u00e4 kaavaa? Koska nykyisten tekniikoiden rajoitukset tietokonej\u00e4rjestelmien v\u00e4lisen viestinn\u00e4n helpottamisessa ovat olleet rajalliset, ohjelmistojen toimittajat ovat usein turvautuneet oman infrastruktuurinsa rakentamiseen. T\u00e4m\u00e4 tarkoittaa, ett\u00e4 resurssit, joita olisi voitu k\u00e4ytt\u00e4\u00e4 toiminnanohjausj\u00e4rjestelm\u00e4n tai luottokorttien k\u00e4sittelyj\u00e4rjestelm\u00e4n toimintojen parantamiseen, on sen sijaan k\u00e4ytetty omien verkkoprotokollien kirjoittamiseen.<\/p>\n
Pyrkiess\u00e4\u00e4n tukemaan paremmin t\u00e4llaisia Internet-skenaarioita Microsoft otti aluksi k\u00e4ytt\u00f6\u00f6n strategian, jossa se t\u00e4ydensi olemassa olevia tekniikoitaan, kuten COM Internet Services (CIS), jonka avulla voit luoda DCOM-yhteyden asiakkaan ja et\u00e4osan v\u00e4lille portin 80 kautta. Eri syist\u00e4 CIS:t\u00e4 ei hyv\u00e4ksytty laajalti.<\/p>\n
Tuli selv\u00e4ksi, ett\u00e4 tarvittiin uusi l\u00e4hestymistapa. Niinp\u00e4 Microsoft p\u00e4\u00e4tti ratkaista ongelman alhaalta yl\u00f6sp\u00e4in. Tarkastellaan joitakin vaatimuksia, jotka ratkaisun oli t\u00e4ytett\u00e4v\u00e4 menesty\u00e4kseen.<\/p>\n
T\u00e4m\u00e4n kirjan otsikon perusteella ei liene yll\u00e4tys, ett\u00e4 Microsoftin luoma ratkaisu tunnetaan nimell\u00e4 Verkkopalvelut<\/i>. Verkkopalvelu tarjoaa rajapinnan, jonka avulla tietty toiminto voidaan k\u00e4ynnist\u00e4\u00e4 asiakkaan puolesta. Asiakas voi k\u00e4ytt\u00e4\u00e4 verkkopalvelua Internet-standardien avulla.<\/p>\n
Verkkopalvelujen rakennuspalikat<\/b>
\nSeuraavassa kuvassa on esitetty kahden sovelluksen v\u00e4lisen et\u00e4yhteyden mahdollistamiseen tarvittavat keskeiset rakennuspalikat.<\/p>\n
Keskustellaanpa kunkin rakennuspalikan tarkoituksesta. Koska moni lukija tuntee DCOM:n, mainitsen my\u00f6s kunkin rakennuspalikan DCOM-ekvivalentin.<\/p>\n
Ilman vakiomuotoista tapaa muotoilla viestit on l\u00e4hes mahdotonta kehitt\u00e4\u00e4 ty\u00f6kaluja, joilla kehitt\u00e4j\u00e4t voidaan irrottaa taustalla olevista protokollista. Kun kehitt\u00e4j\u00e4n ja taustalla olevien protokollien v\u00e4liin luodaan abstraktiokerros, kehitt\u00e4j\u00e4 voi keskitty\u00e4 enemm\u00e4n k\u00e4sill\u00e4 olevaan liiketoimintaongelmaan ja v\u00e4hemm\u00e4n ratkaisun toteuttamiseen tarvittavaan infrastruktuuriin.<\/p>\n
Verkkopalvelujen suunnittelup\u00e4\u00e4t\u00f6kset<\/b><\/p>\n
Keskustellaanpa n\u00e4ist\u00e4 verkkopalvelujen rakennuspalikoista ja niiden taustalla olevista suunnittelup\u00e4\u00e4t\u00f6ksist\u00e4.<\/p>\n
Siirtoprotokollien valitseminen<\/b><\/p>\n
Ensimm\u00e4iseksi m\u00e4\u00e4ritettiin, miten asiakas ja palvelin kommunikoivat kesken\u00e4\u00e4n. Asiakas ja palvelin voivat sijaita samassa l\u00e4hiverkossa, mutta asiakas voi mahdollisesti kommunikoida palvelimen kanssa Internetin kautta. Siksi siirtoprotokollan on sovelluttava yht\u00e4 hyvin l\u00e4hiverkko- ja Internet-ymp\u00e4rist\u00f6ihin.<\/p>\n
Kuten aiemmin mainitsin, DCOM:n, CORBA:n ja Java RMI:n kaltaiset tekniikat soveltuvat huonosti tukemaan asiakkaan ja palvelimen v\u00e4list\u00e4 tiedonsiirtoa Internetiss\u00e4. HTTP-protokollan (Hypertext Transfer Protocol) ja SMTP-protokollan (Simple Mail Transfer Protocol) kaltaiset protokollat ovat hyv\u00e4ksi havaittuja Internet-protokollia. HTTP m\u00e4\u00e4rittelee pyynt\u00f6-vastaus-viestint\u00e4mallin pyynn\u00f6n l\u00e4hett\u00e4mist\u00e4 ja siihen liittyv\u00e4n vastauksen saamista varten. SMTP m\u00e4\u00e4rittelee reititett\u00e4v\u00e4n viestiprotokollan asynkronista viestint\u00e4\u00e4 varten. Tarkastellaan, miksi HTTP ja SMTP soveltuvat hyvin Internetiin.<\/p>\n
HTTP-pohjaiset verkkosovellukset ovat luonnostaan tilattomia. Ne eiv\u00e4t perustu jatkuvaan yhteyteen asiakkaan ja palvelimen v\u00e4lill\u00e4. T\u00e4m\u00e4 tekee HTTP:st\u00e4 ihanteellisen protokollan korkean k\u00e4ytett\u00e4vyyden kokoonpanoihin, kuten palomuureihin. Jos asiakkaan alkuper\u00e4isen pyynn\u00f6n k\u00e4sitellyt palvelin ei ole k\u00e4ytett\u00e4viss\u00e4, seuraavat pyynn\u00f6t voidaan ohjata automaattisesti toiselle palvelimelle asiakkaan tiet\u00e4m\u00e4tt\u00e4 tai v\u00e4litt\u00e4m\u00e4tt\u00e4 siit\u00e4.<\/p>\n
L\u00e4hes kaikilla yrityksill\u00e4 on k\u00e4yt\u00f6ss\u00e4 SMTP:t\u00e4 tukeva infrastruktuuri. SMTP soveltuu hyvin asynkroniseen viestint\u00e4\u00e4n. Jos palvelu h\u00e4iriintyy, s\u00e4hk\u00f6posti-infrastruktuuri huolehtii automaattisesti uusintayrityksist\u00e4. Toisin kuin HTTP:ss\u00e4, SMTP-viestej\u00e4 voi v\u00e4litt\u00e4\u00e4 paikalliselle s\u00e4hk\u00f6postipalvelimelle, joka yritt\u00e4\u00e4 toimittaa s\u00e4hk\u00f6postiviestin puolestasi.<\/p>\n
Sek\u00e4 HTTP:n ett\u00e4 SMTP:n toinen merkitt\u00e4v\u00e4 etu on niiden yleisyys. Ty\u00f6ntekij\u00e4t ovat tottuneet luottamaan sek\u00e4 s\u00e4hk\u00f6postiin ett\u00e4 verkkoselaimiin, ja verkon yll\u00e4pit\u00e4j\u00e4t tukevat n\u00e4it\u00e4 palveluita hyvin mielell\u00e4\u00e4n. NAT:n (network address translation) ja v\u00e4lityspalvelimien kaltaiset tekniikat tarjoavat mahdollisuuden k\u00e4ytt\u00e4\u00e4 Interneti\u00e4 HTTP:n kautta muutoin eristetyist\u00e4 l\u00e4hiverkoista k\u00e4sin. J\u00e4rjestelm\u00e4nvalvojat k\u00e4ytt\u00e4v\u00e4t usein palomuurin sis\u00e4ll\u00e4 olevaa SMTP-palvelinta. T\u00e4lle palvelimelle l\u00e4hetetyt viestit ohjataan sitten lopulliseen m\u00e4\u00e4r\u00e4np\u00e4\u00e4h\u00e4ns\u00e4 Internetin kautta.<\/p>\n
Luottokorttien k\u00e4sittelyohjelmiston tapauksessa kauppapankilta tarvitaan v\u00e4lit\u00f6n vastaus, jotta voidaan p\u00e4\u00e4tt\u00e4\u00e4, onko tilaus toimitettava toiminnanohjausj\u00e4rjestelm\u00e4\u00e4n. HTTP soveltuu hyvin t\u00e4h\u00e4n teht\u00e4v\u00e4\u00e4n pyynt\u00f6\/vastaus-sanomamallinsa ansiosta.<\/p>\n
Useimmat toiminnanohjausohjelmistopaketit eiv\u00e4t pysty k\u00e4sittelem\u00e4\u00e4n suuria tilausm\u00e4\u00e4ri\u00e4, joita s\u00e4hk\u00f6isen kaupank\u00e4ynnin sovelluksesta voidaan mahdollisesti saada. Lis\u00e4ksi tilauksia ei ole v\u00e4ltt\u00e4m\u00e4t\u00f6nt\u00e4 toimittaa toiminnanohjausj\u00e4rjestelm\u00e4\u00e4n reaaliajassa. Siksi SMTP:t\u00e4 voidaan k\u00e4ytt\u00e4\u00e4 tilausten jonottamiseen, jotta ERP-j\u00e4rjestelm\u00e4 voi k\u00e4sitell\u00e4 ne sarjak\u00e4sittelyss\u00e4.<\/p>\n
Jos toiminnanohjausj\u00e4rjestelm\u00e4 tukee hajautettuja tapahtumia, toinen vaihtoehto on k\u00e4ytt\u00e4\u00e4 Microsoft Message Queue Server (MSMQ) -palvelinta. Niin kauan kuin s\u00e4hk\u00f6isen kaupank\u00e4ynnin sovellus ja toiminnanohjausj\u00e4rjestelm\u00e4 sijaitsevat samassa l\u00e4hiverkossa, yhteys muiden kuin Internet-protokollien v\u00e4lityksell\u00e4 ei ole ongelma. MSMQ:n etuna SMTP:hen verrattuna on se, ett\u00e4 viestej\u00e4 voidaan asettaa jonoon ja poistaa jonosta tapahtuman puitteissa. Jos jonosta poistetun viestin k\u00e4sittelyyritys ep\u00e4onnistuu, viesti asetetaan automaattisesti takaisin jonoon, kun tapahtuma keskeytyy.<\/p>\n
Koodausj\u00e4rjestelm\u00e4n valinta<\/b><\/p>\n
HTTP ja SMTP tarjoavat keinon l\u00e4hett\u00e4\u00e4 tietoja asiakkaan ja palvelimen v\u00e4lill\u00e4. Kumpikaan ei kuitenkaan m\u00e4\u00e4rit\u00e4, miten viestin rungon sis\u00e4lt\u00e4m\u00e4 tieto tulisi koodata. Microsoft tarvitsi vakiomuotoisen, alustariippumattoman tavan koodata asiakkaan ja palvelimen v\u00e4lill\u00e4 vaihdettavat tiedot.<\/p>\n
Koska tavoitteena oli hy\u00f6dynt\u00e4\u00e4 Internet-pohjaisia protokollia, XML (Extensible Markup Language) oli luonnollinen valinta. XML tarjoaa monia etuja, kuten alustarajat ylitt\u00e4v\u00e4n tuen, yhteisen tyyppij\u00e4rjestelm\u00e4n ja tuen alan standardimerkist\u00f6ille.<\/p>\n
DCOM:n, CORBA:n ja Java RMI:n kaltaisissa bin\u00e4\u00e4rikoodausj\u00e4rjestelmiss\u00e4 on otettava huomioon eri laitteistoalustojen yhteensopivuusongelmat. Esimerkiksi eri laitteistoalustoilla on erilaiset sis\u00e4iset bin\u00e4\u00e4riset esitystavat usean tavun numeroille. Intel-alustat j\u00e4rjest\u00e4v\u00e4t usean tavun numeron tavut k\u00e4ytt\u00e4en little endian -k\u00e4yt\u00e4nt\u00f6\u00e4, kun taas monet RISC-prosessorit j\u00e4rjest\u00e4v\u00e4t usean tavun numeron tavut k\u00e4ytt\u00e4en big endian -k\u00e4yt\u00e4nt\u00f6\u00e4.<\/p>\n
XML:ss\u00e4 v\u00e4ltet\u00e4\u00e4n bin\u00e4\u00e4rikoodaukseen liittyv\u00e4t ongelmat, koska siin\u00e4 k\u00e4ytet\u00e4\u00e4n tekstipohjaista koodausj\u00e4rjestelm\u00e4\u00e4, joka hy\u00f6dynt\u00e4\u00e4 standardimerkist\u00f6j\u00e4. Lis\u00e4ksi jotkin siirtoprotokollat, kuten SMTP, voivat sis\u00e4lt\u00e4\u00e4 vain tekstipohjaisia viestej\u00e4.<\/p>\n
Bin\u00e4\u00e4riset koodausmenetelm\u00e4t, kuten DCOM:n ja CORBA:n k\u00e4ytt\u00e4m\u00e4t, ovat hankalia, ja ne vaativat tuki-infrastruktuurin, joka irrottaa kehitt\u00e4j\u00e4n yksityiskohdista. XML on paljon kevyempi ja helpompi k\u00e4sitell\u00e4, koska se voidaan luoda ja k\u00e4ytt\u00e4\u00e4 tavallisilla tekstin j\u00e4sent\u00e4mistekniikoilla.<\/p>\n
Lis\u00e4ksi saatavilla on erilaisia XML-j\u00e4sennimi\u00e4, jotka yksinkertaistavat XML-dokumenttien luomista ja k\u00e4ytt\u00e4mist\u00e4 k\u00e4yt\u00e4nn\u00f6ss\u00e4 kaikilla nykyaikaisilla alustoilla. XML on kevyt ja sill\u00e4 on erinomainen ty\u00f6kalutuki, joten XML-koodaus mahdollistaa uskomattoman laajuuden, koska k\u00e4yt\u00e4nn\u00f6ss\u00e4 mik\u00e4 tahansa asiakas mill\u00e4 tahansa alustalla voi kommunikoida verkkopalvelusi kanssa.<\/p>\n
Muotoilusopimuksen valitseminen<\/b><\/p>\n
Usein on tarpeen sis\u00e4llytt\u00e4\u00e4 viestin runkoon lis\u00e4\u00e4 metatietoja. Voit esimerkiksi haluta sis\u00e4llytt\u00e4\u00e4 tietoja siit\u00e4, mink\u00e4 tyyppisi\u00e4 palveluja verkkopalvelun on tarjottava, jotta pyynt\u00f6si voidaan t\u00e4ytt\u00e4\u00e4, kuten ilmoittautuminen tapahtumaan tai reititystiedot. XML ei tarjoa mekanismia viestin rungon erottamiseksi siihen liittyvist\u00e4 tiedoista.<\/p>\n
HTTP:n kaltaiset siirtoprotokollat tarjoavat laajennettavissa olevan mekanismin otsikkotietoja varten, mutta jotkin viestiin liittyv\u00e4t tiedot eiv\u00e4t v\u00e4ltt\u00e4m\u00e4tt\u00e4 ole siirtoprotokollakohtaisia. Asiakas voi esimerkiksi l\u00e4hett\u00e4\u00e4 viestin, joka on reititett\u00e4v\u00e4 useisiin kohteisiin, mahdollisesti eri siirtoprotokollien kautta. Jos reititystiedot sijoitettaisiin HTTP-otsikkoon, ne olisi k\u00e4\u00e4nnett\u00e4v\u00e4 ennen kuin ne l\u00e4hetet\u00e4\u00e4n seuraavalle v\u00e4litt\u00e4j\u00e4lle toisen siirtoprotokollan, kuten SMTP:n, kautta. Koska reititystieto liittyy viestiin eik\u00e4 siirtoprotokollaan, sen pit\u00e4isi olla osa viesti\u00e4.<\/p>\n
SOAP (Simple Object Access Protocol) tarjoaa protokollasta riippumattoman keinon yhdist\u00e4\u00e4 otsikkotiedot viestin runkoon. Jokaisessa SOAP-sanomassa on m\u00e4\u00e4ritelt\u00e4v\u00e4 kirjekuori. Kirjekuoressa on runko, joka sis\u00e4lt\u00e4\u00e4 viestin hy\u00f6tykuorman, ja otsikko, joka voi sis\u00e4lt\u00e4\u00e4 viestiin liittyv\u00e4\u00e4 metatietoa.<\/p>\n
SOAP ei aseta rajoituksia viestirungon muotoilulle. T\u00e4m\u00e4 on mahdollinen huolenaihe, koska ilman johdonmukaista tapaa koodata tiedot on vaikea kehitt\u00e4\u00e4 ty\u00f6kaluja, jotka irrottavat sinut taustalla olevista protokollista. Saatat joutua k\u00e4ytt\u00e4m\u00e4\u00e4n melko paljon aikaa Web-palvelun k\u00e4ytt\u00f6liittym\u00e4n opetteluun sen sijaan, ett\u00e4 ratkaisisit k\u00e4sill\u00e4 olevan liiketoimintaongelman.<\/p>\n
Tarvittiin vakiomuotoinen tapa muotoilla RPC-sanoma (Remote Procedure Call) ja koodata sen parametrien luettelo. SOAP-m\u00e4\u00e4rittelyn kohdassa 7 tarjotaan juuri t\u00e4m\u00e4. Siin\u00e4 kuvataan vakiomuotoinen nime\u00e4misk\u00e4yt\u00e4nt\u00f6 ja koodaustyyli menettelytapasuuntautuneille viesteille.<\/p>\n
Koska SOAP tarjoaa vakiomuodon tietojen sarjallistamiseen XML-viestiksi, ASP.NETin ja Remotingin kaltaiset alustat voivat abstrahoida yksityiskohdat puolestasi.<\/p>\n
Kuvausmekanismien valinta<\/b><\/p>\n
SOAP tarjoaa vakiomuotoisen tavan muotoilla verkkopalvelun ja asiakkaan v\u00e4lill\u00e4 vaihdettavat viestit. Asiakas tarvitsee kuitenkin lis\u00e4tietoja, jotta se voi sarjallistaa pyynn\u00f6n ja tulkita vastauksen oikein. XML-skeema tarjoaa keinon luoda skeemoja, joita voidaan k\u00e4ytt\u00e4\u00e4 viestin sis\u00e4ll\u00f6n kuvaamiseen.<\/p>\n
XML Schema tarjoaa keskeisen joukon sis\u00e4\u00e4nrakennettuja tietotyyppej\u00e4, joita voidaan k\u00e4ytt\u00e4\u00e4 viestin sis\u00e4ll\u00f6n kuvaamiseen. Voit my\u00f6s luoda omia tietotyyppej\u00e4. Esimerkiksi kauppapankki voi luoda monimutkaisen tietotyypin kuvaamaan luottokorttimaksupyynn\u00f6n l\u00e4hett\u00e4miseen k\u00e4ytett\u00e4v\u00e4n viestin rungon sis\u00e4lt\u00f6\u00e4 ja rakennetta.<\/p>\n
Skeema sis\u00e4lt\u00e4\u00e4 joukon tietotyyppi- ja elementtim\u00e4\u00e4rityksi\u00e4. Verkkopalvelu k\u00e4ytt\u00e4\u00e4 skeemaa paitsi viestin sis\u00e4lt\u00e4mien tietotyyppien ilmoittamiseen my\u00f6s saapuvien ja l\u00e4htevien viestien validointiin.<\/p>\n
Pelkk\u00e4 skeema ei kuitenkaan tarjoa riitt\u00e4v\u00e4sti tietoa verkkopalvelun tehokkaaseen kuvaamiseen. Skeema ei kuvaa asiakkaan ja palvelimen v\u00e4lisi\u00e4 viestimalleja. Asiakkaan on esimerkiksi tiedett\u00e4v\u00e4, voiko h\u00e4n odottaa vastausta, kun tilaus l\u00e4hetet\u00e4\u00e4n toiminnanohjausj\u00e4rjestelm\u00e4\u00e4n. Asiakkaan on my\u00f6s tiedett\u00e4v\u00e4, mink\u00e4 siirtoprotokollan kautta verkkopalvelu odottaa vastaanottavansa pyynt\u00f6j\u00e4. Lis\u00e4ksi asiakkaan on tiedett\u00e4v\u00e4 osoite, josta verkkopalvelu on tavoitettavissa.<\/p>\n
N\u00e4m\u00e4 tiedot annetaan WSDL-asiakirjassa (Web Services Description Language). WSDL on XML-dokumentti, joka kuvaa t\u00e4ysin tietyn verkkopalvelun. Ty\u00f6kalut, kuten ASP.NET WSDL.exe ja Remoting SOAPSUDS.exe, voivat k\u00e4ytt\u00e4\u00e4 WSDL:\u00e4\u00e4 ja rakentaa automaattisesti v\u00e4lityspalvelimia kehitt\u00e4j\u00e4n puolesta.<\/p>\n
Kuten mink\u00e4 tahansa ohjelmiston rakentamiseen k\u00e4ytett\u00e4v\u00e4n komponentin kohdalla, my\u00f6s verkkopalvelun mukana tulisi olla kirjallinen dokumentaatio kehitt\u00e4jille, jotka ohjelmoivat verkkopalvelua vastaan. Dokumentaatiossa tulisi kuvata, mit\u00e4 verkkopalvelu tekee, mit\u00e4 rajapintoja se tarjoaa ja joitakin esimerkkej\u00e4 sen k\u00e4yt\u00f6st\u00e4. Hyv\u00e4 dokumentaatio on erityisen t\u00e4rke\u00e4\u00e4, jos verkkopalvelu on avoin asiakkaille Internetin kautta.<\/p>\n
L\u00f6yt\u00e4mismekanismien valinta<\/b><\/p>\n
Kun olet kehitt\u00e4nyt ja dokumentoinut verkkopalvelun, miten potentiaaliset asiakkaat voivat l\u00f6yt\u00e4\u00e4 sen? Jos verkkopalvelu on suunniteltu siten, ett\u00e4 sit\u00e4 voi k\u00e4ytt\u00e4\u00e4 kehitystiimisi j\u00e4sen, l\u00e4hestymistapa voi olla melko ep\u00e4virallinen, kuten WSDL-dokumentin URL-osoitteen jakaminen parin p\u00f6yd\u00e4n p\u00e4\u00e4ss\u00e4 olevan kollegan kanssa. Mutta kun potentiaaliset asiakkaat ovat Internetiss\u00e4, verkkopalvelun tehokas mainostaminen on aivan eri asia.<\/p>\n
Tarvitaan yhteinen tapa mainostaa verkkopalveluja. Universal Description, Discovery and Integration (UDDI) tarjoaa juuri t\u00e4llaisen mekanismin. UDDI on teollisuusstandardin mukainen keskitetty hakemistopalvelu, jota voidaan k\u00e4ytt\u00e4\u00e4 verkkopalvelujen mainostamiseen ja paikantamiseen. UDDI:n avulla k\u00e4ytt\u00e4j\u00e4t voivat hakea verkkopalveluja k\u00e4ytt\u00e4m\u00e4ll\u00e4 useita hakuehtoja, kuten yrityksen nime\u00e4, luokkaa ja verkkopalvelun tyyppi\u00e4.<\/p>\n
Verkkopalveluja voidaan mainostaa my\u00f6s DISCO:n avulla, joka on Microsoftin m\u00e4\u00e4rittelem\u00e4 oma XML-dokumenttiformaatti, jonka avulla verkkosivut voivat mainostaa tarjoamiaan palveluja. DISCO m\u00e4\u00e4rittelee yksinkertaisen protokollan, jolla helpotetaan resurssien paikantamista hyperlinkkien avulla. DISCO:n ensisijainen k\u00e4ytt\u00e4j\u00e4 on Microsoft Visual Studio.NET. Kehitt\u00e4j\u00e4 voi kohdistaa toimintonsa tiettyyn Web-palvelimeen ja selata palvelimen tarjoamia eri Web-palveluja.<\/p>\n
Mit\u00e4 verkkopalveluista puuttuu?<\/b><\/p>\n
Olet ehk\u00e4 huomannut, ett\u00e4 joitakin hajautetun komponentti-infrastruktuurin keskeisi\u00e4 osia ei ole m\u00e4\u00e4ritelty verkkopalveluissa. Kaksi huomattavinta puutetta ovat hyvin m\u00e4\u00e4ritelty sovellusliittym\u00e4 Web-palvelujen luomista ja k\u00e4ytt\u00e4mist\u00e4 varten sek\u00e4 joukko komponenttipalveluja, kuten tuki hajautetuille transaktioille. Keskustellaan n\u00e4ist\u00e4 puuttuvista osista.<\/p>\n
Pyrkiess\u00e4\u00e4n varmistamaan, ett\u00e4 verkkopalvelut ovat ohjelmointikielist\u00e4 riippumattomia, Microsoft on j\u00e4tt\u00e4nyt yksitt\u00e4isten ohjelmistotoimittajien teht\u00e4v\u00e4ksi sitoa verkkopalvelutuki tiettyyn alustaan. K\u00e4sittelen my\u00f6hemmin kirjassa kahta Web-palvelutoteutusta.NET-alustalle, ASP.NET ja Remoting.<\/p>\n
Jotkin palvelut, kuten tuki hajautetuille tapahtumille, voidaan ottaa k\u00e4ytt\u00f6\u00f6n my\u00f6hemmin, kun tekniikka kehittyy. Toisia, kuten objektien yhteisk\u00e4ytt\u00f6\u00e4 ja mahdollisesti objektien k\u00e4ytt\u00f6i\u00e4n hallintaa, voidaan pit\u00e4\u00e4 alustan toteutuksen yksityiskohtana. Esimerkiksi Remoting m\u00e4\u00e4rittelee laajennuksia, jotka tukevat objektien elinkaaren hallintaa, ja Microsoft Component Services tukee objektien yhdist\u00e4mist\u00e4.<\/p>\n
Yhteenveto<\/b><\/p>\n
Komponenttipohjainen ohjelmointi on osoittautunut kehitt\u00e4jien tuottavuutta parantavaksi, mutta joitakin palveluja ei voida kapseloida asiakkaan tietokeskuksessa sijaitsevaan komponenttiin. DCOM:n, CORBA:n ja Java RMI:n kaltaiset vanhat tekniikat eiv\u00e4t sovellu siihen, ett\u00e4 asiakkaat voisivat k\u00e4ytt\u00e4\u00e4 palveluja Internetin kautta, joten Microsoft katsoi tarpeelliseksi aloittaa alusta ja rakentaa alan standardin mukaisen tavan k\u00e4ytt\u00e4\u00e4 et\u00e4palveluja.<\/p>\n
Verkkopalvelut<\/i> on sateenvarjotermi, joka kuvaa kokoelmaa alan standardiprotokollia ja -palveluja, joita k\u00e4ytet\u00e4\u00e4n helpottamaan sovellusten yhteentoimivuuden perustasoa. Web-palvelut ovat saaneet ennenn\u00e4kem\u00e4tt\u00f6m\u00e4n paljon tukea teollisuudelta. Koskaan aikaisemmin ei ole n\u00e4in monet johtavat teknologiayritykset tukeneet standardia, joka helpottaa sovellusten yhteentoimivuutta riippumatta siit\u00e4, mill\u00e4 alustalla niit\u00e4 k\u00e4ytet\u00e4\u00e4n.<\/p>\n
Yksi verkkopalvelujen menestykseen vaikuttavista tekij\u00f6ist\u00e4 on se, ett\u00e4 ne perustuvat olemassa oleviin Internet-standardeihin, kuten XML:\u00e4\u00e4n ja HTTP:hen. N\u00e4in ollen mik\u00e4 tahansa j\u00e4rjestelm\u00e4, joka pystyy j\u00e4sent\u00e4m\u00e4\u00e4n teksti\u00e4 ja kommunikoimaan standardoidun Internetin siirtoprotokollan kautta, voi kommunikoida verkkopalvelun kanssa. Yritykset voivat my\u00f6s hy\u00f6dynt\u00e4\u00e4 investointeja, joita ne ovat jo tehneet n\u00e4ihin teknologioihin.<\/p>","protected":false},"excerpt":{"rendered":"
Overview Component-based programming has become more popular than ever. Hardly an application is built today that does not involve leveraging components in some form, usually from different vendors. As applications have grown more sophisticated, the need to leverage components distributed on remote machines has also grown.<\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-231","post","type-post","status-publish","format-standard","hentry","category-smtp-servers"],"_links":{"self":[{"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/fi\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}