Keith Matsudaira: Skaalautuva verkkoarkkitehtuuri ja hajautetut järjestelmät. Verkkopalvelun kokoaminen ja testaus. yleiskuvaus työstä

Luento 10. Verkkopalveluteknologiat

Suunnitelma

8.1. Verkkopalveluiden perusteet

8.2. Web 2.0 ja verkkopalvelut

8.4 Vuorovaikutus verkkopalvelujen kanssa

8.6. Verkkopalveluiden kokoonpano

8.7 Verkkopalvelut ASP.Netissä

8.1. Verkkopalveluiden perusteet

verkkopalvelu(Web-palvelu) (katso W3C-dokumentti "Web-palveluiden arkkitehtuurivaatimukset") on URI-merkkijonolla tunnistettu ohjelmistojärjestelmä, jonka liitännät ja sidokset on määritelty ja kuvattu XML-kieli. Tämän ohjelmistojärjestelmän kuvauksen voivat löytää muut ohjelmistojärjestelmät, jotka voivat olla vuorovaikutuksessa sen kanssa tämän kuvauksen mukaisesti. viestien kautta, perustuu XML:ään ja läpäissyt käyttäen Internet-protokollat.

Verkkopalvelukonsepti sai alkunsa 1990-luvun lopulla. Tähän mennessä tämä konsepti on kuitenkin onnistunut vakiinnuttamaan ja sen tarjoamasta arkkitehtuurista on tullut IT-alan standardi.

Verkkopalveluarkkitehtuurin standardoinnista vastaavat W3C-komitean työryhmät.

Verkkopalvelustandardit määrittelevät viestien muodon, rajapinnan, johon viesti välitetään, säännöt viestin sisällön sitomiseksi palvelun toteuttavaan sovellukseen ja sieltä pois sekä mekanismit rajapintojen julkaisemiseen ja etsimiseen.

Viestintämekanismi on määritelty Web Services -kuvauksessa, joka on palvelurajapintamääritelmä ja kattaa viestimuodot, tietotyypit ja siirtoprotokollat, joita käytetään asiakkaan ja palveluntarjoajan välisessä vaihdossa. Lisäksi palvelun kuvaus sisältää viittauksen yhdestä tai useammasta verkon (päätepisteen) pisteestä, josta palveluntarjoaja on tavoitettavissa.

Web Services -palvelun avulla minkä tahansa verkossa olevan ohjelman toiminnot voidaan asettaa saataville Internetin kautta.

Verkkopalvelut perustuvat seuraaviin universaaleihin teknologioihin:

TCP/IP on yleinen protokolla, jota kaikki verkkolaitteet ymmärtävät keskuskoneista aina matkapuhelimet ja PDA;

HTML- universaali kieli merkinnät, joita käytetään tietojen näyttämiseen käyttäjän laitteilla;

XML (Extensible Markup Language) on universaali kieli kaikentyyppisten tietojen käsittelyyn.

Joten verkkopalvelut päättävät alkuperäinen ongelma– tehtävä integroida erilaisia sovelluksia ja rakentaa hajautettuja IS.

Tämä on tärkein perustavanlaatuinen ero edeltäjiensä verkkopalvelut - teknologiat hajautettujen sovellusten vuorovaikutukseen, jotka mahdollistivat tietojen vaihdon sovellusten välillä (Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) ja Common Objektipyyntö Broker Architecture (CORBA)). Jokainen niistä oli kuitenkin melko vaikea toteuttaa, niillä ei ollut tarvittavaa universaalisuutta (eli se riippui silti esimerkiksi saman käyttöjärjestelmän valinnasta kaikille vaihdon osallistujille) ja mikä on erityisen huonoa, nämä tekniikat liittyivät keskenään suurilla vaikeuksilla.

Verkkopalveluiden edut ja haitat

Edut

verkkopalvelut varmistavat ohjelmistojärjestelmien vuorovaikutuksen alustasta riippumatta;
verkkopalvelut perustuvat avoimiin standardeihin ja protokolliin. XML:n käytöllä saavutetaan verkkopalveluiden kehittämisen ja virheenkorjauksen helppous;
HTTP Internet-protokollan käyttö varmistaa ohjelmistojärjestelmien vuorovaikutuksen palomuurin kautta.

Vikoja

vähemmän suorituskykyä ja suurempi koko verkkoliikennettä verrattuna RMI-, CORBA-, DCOM-tekniikoihin XML-tekstiviestien avulla.

Alustat

Verkkopalvelut toimivat sovelluspalvelimilla. Nykyään lähes kaikki verkkosovelluspalvelimet tukevat tätä tekniikkaa:

Axis ja Tomcat (molemmat ovat Apache-projekteja).
Novellin mono-kehitysalusta
Microsoftin .NET-palvelimet Microsoftilta
Java Web Services Development Pack (JWSDP) Sun Microsystemsiltä (perustuu Jakarta Tomcatiin)
Zope on Pythonilla kirjoitettu oliopohjainen verkkosovelluspalvelin.
IBM:n sovelluspalvelin (perustuu Apache- ja J2EE-alustaan)
Cordys WS-AppServer
infoRouter Document Management ohjelmisto Web Services API
JONAS (osa ObjectWeb Open Source -aloitetta)
SAP:n verkkosovelluspalvelin (Web AS on keskeinen osa SAP NetWeaver -pinoa)
Pramati-sovelluspalvelin, Pramati Technologies Limited
Progress Softwaren OpenEdge-alusta
Oracle Corporationin Oracle Application Server
Zend Framework - Zend Technologies
Pythomnic on alusta hajautettujen verkkopalvelujen kirjoittamiseen.
Google App Engine on alusta erittäin skaalautuville sovelluksille, jotka käyttävät Googlen infrastruktuuria.

Verkkopalvelut ovat samanlaisia kuin DLL:t, mutta niissä on seuraavat erot:

suoritetaan palvelinpuolella;
tarjota joukon menetelmiä ulkoisten asiakkaiden käytettävissä;
suorittaa web-menetelmiä ja palauttaa tulokset asiakkaille;
verkkopalvelut ja niiden asiakkaat voidaan kirjoittaa eri kielillä ja/tai eri alustoilla.

8.2. Web 2.0 ja verkkopalvelut

Verkkopalvelutekniikat ovat Web 2.0:n perusta.

Kuuluisa amerikkalainen kustantaja Tim O'Reilly ehdotti termiä "Web 2.0" vuonna 2005 viittaamaan joukkoon verkkoteknologian kehityksen edistyksellisiä suuntauksia.

Nykyään tätä termiä ei ymmärretä niinkään tiettyjen teknologioiden joukkona, vaan filosofiana tiedon esittämisestä verkkoympäristössä ja tietosuhteiden rakentamisesta.

Web 2.0 -ilmiö voidaan jakaa useisiin yleisiin verkkoympäristön kehityksen suuntauksiin.

Web alustana. Tämä konsepti on web 2.0 -filosofian perusta.

Tämä tarkoittaa, että käyttäjät voivat käyttää ohjelmistosovelluksia suoraan verkkoselaimen avulla. Toisin sanoen tämä konsepti sisältää kaikkien tarvittavien laskelmien suorittamisen käyttämällä vain niitä ohjelmistotyökalut jotka on integroitu verkkoselaimen kanssa.

Koska verkkopalvelut sallivat yhden verkkoprojektin käyttää toisen ohjelmistosovelluksia, organisaatioiden ei tarvitse luoda monia samanlaisia tuotteita suorittaakseen samoja tehtäviä. Näin verkkopalvelut mahdollistavat eri instituutioiden yhteistyön ja koordinoinnin verkkosisällön luomisprosessissa.

Täällä puhumme jo toisesta tärkeästä Web 2.0:n periaatteesta - "mashupista" (Mash-up - "sekoitus"). Tämä periaate tarkoittaa, että yhdistämällä useiden itsenäisten verkkopalveluiden ohjelmointiominaisuudet on mahdollista luoda uusi ainutlaatuinen verkkoprojekti.

8.3 Verkkopalveluiden teknologiapino

Verkkopalvelut edellyttävät useiden toisiinsa liittyvien XML-tekniikoiden käyttöä, jotka muodostavat teknologiapinon (kuva 8.1).

XML on perusta, jolle verkkopalvelut rakennetaan. Se tarjoaa tietojen määrittelykielen ja käsittelyjärjestyksen. XML on Internet Consortiumin (W3C) ja muiden organisaatioiden julkaisema ja ylläpitämä asiaan liittyvien spesifikaatioiden perhe.
SOAP (yksinkertainen Objektin käyttöoikeus Protocol), jonka W3C-konsortio on kehittänyt, määrittelee verkkopalveluiden pyyntöjen muodon. Verkkopalvelun ja sen käyttäjän väliset viestit pakataan niin sanottuihin SOAP-kuoriin (SOAP-kirjekuoret, joskus niitä kutsutaan myös XML-kuoriksi). Itse viesti voi sisältää joko pyynnön suorittaa jonkin toiminnon tai vastauksen - tämän toiminnon suorittamisen tuloksena.
WSDL (Web Services Description Language) on XML-pohjainen tekniikka, joka määrittelee verkkopalvelurajapinnat, data- ja viestityypit sekä vuorovaikutusmallit ja sidosprotokollat. Ennen palvelun käyttöönottoa kehittäjä kirjoittaa sen kuvauksen WSDL:ssä, määrittää verkkopalvelun osoitteen, tuetut protokollat, luettelon sallituista toiminnoista, pyyntö- ja vastausmuodot.
UDDI (Universal Description, Discovery and Integration) -tekniikka on verkkopalvelurekisteri- ja hakukone. Sitä käytetään tallentamaan ja järjestämään tietoa verkkopalveluista sekä etsimään viitteitä verkkopalveluliittymiin.

Riisi. 8.1. Verkkopalveluiden teknologiapino

Nämä tekniikat tarjoavat toteutuksen perusominaisuudet määritelmässä kuvattu verkkopalvelu.

Niiden pohjalta kehitetään uusia vuorovaikutuskieliä ja palvelukeskeisiä arkkitehtuureja.

8.4 Vuorovaikutus verkkopalvelujen kanssa

Verkkopalvelurajapinnat vastaanottavat tavallisia XML-viestejä verkkoympäristöstä, muuntavat XML-tiedot tietyn sovellusohjelmistojärjestelmän "ymmärtämään" muotoon ja lähettävät vastausviestin (jälkimmäinen on valinnainen). Ohjelmiston toteutus verkkopalveluita (perusohjelmisto, alempi taso) voidaan luoda millä tahansa ohjelmointikielellä millä tahansa käyttöjärjestelmällä ja millä tahansa väliohjelmistolla (middleware).

Ohjelmistojärjestelmien vuorovaikutus verkkopalvelujen kanssa on esitetty kuvassa. 8.2.

Riisi. 8.2. Vuorovaikutus verkkopalvelujen kanssa

Palvelukeskeisessä arkkitehtuurissa on kolme pääarkkitehtuurikomponenttia:

palvelun käyttäjä: sovellus, ohjelmamoduuli tai palvelu, joka etsii ja kutsuu palvelurekisteristä palvelukuvauksen mukaista palvelua ja käyttää myös palveluntarjoajan tarjoamaa palvelua palvelurajapinnan mukaisesti;
palveluntarjoaja: sovellus, ohjelmistomoduuli tai palvelu, joka toteuttaa palvelun verkkopalveluna, vastaanottaa ja suorittaa pyynnöt palvelun käyttäjiltä sekä julkaisee palvelun palvelurekisterissä;
palvelurekisteri: Palvelukirjasto, joka tarjoaa palvelun käyttäjille keinot etsiä ja kutsua tarvittava palvelu sekä ottaa vastaan palveluntarjoajien pyyntöjä julkaista palveluita.

Kullakin komponentilla voi olla joko vain yksi rooli (olla esimerkiksi vain palvelun käyttäjä) tai useita rooleja kerralla (esimerkiksi olla joidenkin palvelujen tarjoaja ja toisten käyttäjä).

Palvelukeskeisen arkkitehtuurin komponentit suorittavat vuorovaikutuksessa keskenään seuraavat päätoiminnot:

julkaisu: jotta palvelu olisi palvelun käyttäjien saatavilla (kutsutaan), sen käyttöliittymä on saatettava heidän tietoonsa;
Hae: palvelun käyttäjän tulee pystyä löytämään palvelurekisteristä tarvittava palvelu, joka täyttää määritellyt kriteerit;
sitominen ja kutsuminen: Palvelukuvauksen saatuaan palvelun käyttäjän tulee pystyä soittamaan ja käyttämään palvelua palvelukuvauksen mukaisesti.

Kun otetaan huomioon palvelukeskeisen arkkitehtuurin komponenttien vuorovaikutus, on huomioitava seuraavien kahden artefaktin olemassaolo (ja ero):

palvelun kuvaus: määrittää pyynnön ja vastauksen muodon palvelun käyttäjän ja palveluntarjoajan välisessä vuorovaikutuksessa sekä vaaditun palvelun laadun;
palvelua: todellinen palvelu, jota palvelun käyttäjä voi kutsua ja käyttää palvelun julkaistun käyttöliittymän mukaisesti.

8.5 Palvelukeskeinen sovellusarkkitehtuuri

8.5.1. Palvelukeskeisen arkkitehtuurin perusteet

Arkkitehtuuria, jossa kaikki sovellustoiminnot ovat itsenäisiä palveluita, joissa on hyvin määritellyt rajapinnat, joita voidaan kutsua oikeassa järjestyksessä muodostamaan liiketoimintaprosesseja, kutsutaan palvelukeskeiseksi (SOA).

SOA on keino esittää yritystä toisiinsa liittyvien palveluiden kokonaisuutena. Yksi sen eduista on joustavuus ja uusien sovellusten kehittämisen helppous. SOA luo viestintäympäristön moduuleille, jotka toteuttavat sovellettua liiketoimintalogiikkaa. Moduuleista julkaistaan tiedot siten, että niiden käyttö ei edellytä niissä käytettyjen ratkaisujen ja teknologioiden tuntemusta.

8.5.2. Palvelukeskeisen arkkitehtuurin toteutustekniikat

Monimutkaisten hajautettujen sovellusten luomiseen yksi pino perustekniikoita (SOAP, WSDL, UDDI) ei riitä. Muita asioita on käsiteltävä, kuten suorituskyky, turvallisuus, luotettava toimitus viestit, tapahtumien koordinointi ja muut. Siksi tämä teknologiapino laajenee jatkuvasti. Kuvassa Kuva 8.3 esittää laajennettua pinoa verkkopalvelutekniikoita, sisältäen sekä jo standardoituja että uusia teknologioita.

Riisi. 8.3 Edistyksellinen pino verkkopalvelutekniikoita

Laajennettu verkkopalvelutekniikoiden pino on jaettu pohjimmiltaan kahteen osaan:

tarjoavia teknologioita toiminnallisuutta Web-palvelut (toiminnot);
tarjoavia teknologioita palvelun laatu verkkopalvelut (palvelun laatu).

Nämä komponentit puolestaan muodostuvat useista kerroksista (kerroksista):

tekniikat, jotka tarjoavat verkkopalveluiden toimivuuden:

kuljetuskerros (kuljetuskerros);
viestintäkerros (palveluviestintäkerros);
palvelun kuvaus kerros
palvelukerros (palvelukerros);
liiketoimintaprosessien kerros;
palvelurekisterikerros.

teknologiat, jotka varmistavat verkkopalveluiden laadun:

politiikan kerros;
turvakerros (turvakerros);
tapahtumakerros (transaktiokerros);
hallintakerros.

Annamme kerrosten tarkoituksen ymmärtämiseksi Lyhyt kuvaus jokainen heistä.

№ p/p	Tason nimi	Tasotehtävä	Tekniikat, jotka toteuttavat kerroksen
Toiminnallisuus
1	Kuljetuskerros	Kuvaa keinoja tiedonvaihtoon verkkopalveluiden välillä	Vakio: HTTP, JMS (Java-sovelluksille), SMTP Uutta: WS-ReliableMessaging, BEEP
2	Viestintäkerros (palveluviestintäkerros)	Kuvaa tapoja formalisoida verkkopalveluiden siirtoprotokollien käyttömekanismit.	Vakio: SOAP Uusi: REST
3	Palvelun kuvaustaso	Kuvaa työkalut verkkopalvelurajapintojen formalisoimiseksi niiden toiminnan varmistamiseksi ohjelmisto- ja laitteistototeutusalustasta tai ohjelmointikielestä riippumatta.	Vakio: XML, WSDL Syntyvä: ebXML
4	Palvelukerros	Kuvaa ohjelmistoja, jotka käynnistetään käyttämällä WSDL-kuvauksia verkkopalveluliittymistä. Erityisesti nämä ovat itse verkkopalveluita.
5	Liiketoimintaprosessi kerros	Kuvaa mahdollisuuksia järjestää verkkopalveluita liiketoimintaprosessien ja työnkulkujen toteuttamiseksi. Samalla määritellään säännöt, jotka määrittelevät verkkopalvelujen vuorovaikutusjärjestyksen liiketoiminnan vaatimusten täyttämiseksi.	Uusi: BPEL4WS, WCF, WF
6	Palvelurekisterikerros	Kuvaa mahdollisuuksia järjestää verkkopalveluita hierarkkisiin kirjastoihin, jotka mahdollistavat verkkopalvelujen julkaisemisen, haun ja soittamisen WSDL-rajapintakuvaustensa mukaan	Vakio: UDDI Syntyvä: WS-Inspection
Palvelun laatu
7	Käytäntötaso	Kuvaa ehdot, joilla verkkopalveluita voidaan käyttää. Koska nämä ehdot koskevat sekä verkkopalveluiden toiminnallista puolta että kuvan 2 palvelun laatunäkökulmaa. 8.3, tämä kerros on yhteinen molemmille aspekteille	Vakio: ei tällä hetkellä Uutta: WS-Policy, WS-PolicyAssertions ja WS-PolicyAttachment
8	Turvakerros	Kuvaa verkkopalveluiden suojausominaisuuksia ja niiden toiminnan turvallisuutta (valtuutus, todennus ja pääsyn jakaminen)	Vakio: WS-Security Uutta: WS-SecureConversation, WS-Federation, WS-Authorization, WS-Trust ja WS-Privacy
9	Tapahtumataso	Kuvaa verkkopalveluihin perustuvien hajautettujen järjestelmien transaktioominaisuutta niiden toiminnan luotettavuuden varmistamiseksi	Vakio: ei tällä hetkellä Uutta: WS-Transaction ja WS-Coordination
10	Hallintakerros	Kuvaa kykyä hallita verkkopalveluita ja niiden toiminnan ominaisuuksia.	Uusi:

Yllä esitetty verkkopalveluteknologiapino tuo hierarkian useisiin verkkopalvelutekniikoihin niiden mukaan. toiminnallinen tarkoitus. Samaan aikaan taulukossa näkyvät vain laajimmin käytetyt ja vakiintuneet tekniikat. Teknologiat, jotka ovat saaneet virallinen asema kansainvälisten yhteenliittymien standardit IT-standardien kehittämiseksi (W3C).

8.6. Verkkopalveluiden kokoonpano

Verkkopalveluiden koostettavuus nähdään usein yhtenä tekniikan tärkeimmistä eduista, mikä tekee niistä uudelleenkäytettäviä. uudelleenkäyttö. Yleisesti ottaen verkkopalveluiden laatiminen on käyttäjän pyynnön täyttämiseen tarvittavien ydinpalveluiden joukon löytämistä ja niiden suoritusjärjestyksen määrittämistä.

Kunkin verkkopalvelun toiminnallisuus määritellään sen syötteillä, lähdöillä, edellytyksillä ja toiminnoilla, joita kutsutaan IOPE:iksi (tulot, lähdöt, ennakkoehdot ja efektit). Palvelun IOPE sisältyy sen WSDL-kuvaukseen.

Suorituksensa näkökulmasta verkkopalvelut voidaan jakaa atomisiin, joita ei ole jaettu aliprosesseihin ja joita käyttäjä voi kutsua suoraan Internetin kautta, ja komposiittisiin, joissa on ohjausrakenteiden yhdistämiä aliprosesseja. Pääsääntöisesti käyttäjän liiketoimintatehtävät toteuttavat yhdistelmäpalveluita, jotka voidaan koota olemassa olevista atomeista.

Verkkopalveluiden käsite viittaa siihen yksittäisiä palveluita on tietty rajallinen toiminnallisuus, kun taas enemmän tai vähemmän monimutkaiset tehtävät edellyttävät useiden palvelujen toiminnallisuuden käyttöä. Siksi verkkopalveluiden arkkitehtuurin kehittämisen aikana sellaisia konsepteja kuin koostumus ja virtaus tai kuten nyt sanotaan, orkestraatio ja koreografia. He heijastavat palvelun vuorovaikutus ja järjestys niiden täytäntöönpano; web-palveluilla rakennettujen sovellusten katsotaan perustuvan työnkulkuihin (Work Flow, WF).

Ehdot orkestrointi Ja koreografia kuvaile verkkopalveluliittoon perustuvien liiketoimintaprosessien kehittämisen kahta näkökohtaa. Kuvassa 8.5 osoittaa yleisesti näiden näkökohtien suhteen, jotka jossain määrin täydentävät toisiaan.

Alla orkestrointi ymmärtää, kuinka palvelut ovat vuorovaikutuksessa toistensa kanssa viestitasolla, mukaan lukien liiketoimintalogiikka ja yhteistyö suoritettaessa monimutkaisia prosesseja sisällä yksi yritys (yksi liiketoimintaprosessi).

Koreografia kattaa laajemman joukon vuorovaikutukseen osallistujia, mukaan lukien yrityksen tavarantoimittajat, kuluttajat ja yhteistyökumppanit. Se liittyy julkiseen viestintään useiden verkkopalvelujen välillä eikä yksittäiseen liiketoimintaprosessiin, joka on käynnissä yhdessä yrityksessä.

Koreografia ja orkestrointistandardit perustuvat WSDL:ään. Liiketoimintaprosessimallin tasolla standardiprojektit, kuten Wf-XML (Workflow Management Coalition), WSFL (IBM Web Services Flow Language), XLANG (Microsoftin XLANG: Business Modeling Language for BizTalk), PIPs (RosettaNetin kumppani) ovat ehdotettuja käyttöliittymäprosesseja. ).

Tähän mennessä BPEL4WS (Business Process Execution Kieli for Web Services), jonka ovat valmistaneet IBM, Microsoft ja BEA Systems, ja Sun Microsystems Corporationin WSCI (Web Service Choreography Interface).

BPEL4WS-kieli on suunniteltu toteutettavaksi orkestrointi palvelut.

WSCI-kieli heijastaa konseptia koreografia palvelut.

WSCI (Web Service Choreography Interface) on kuvaava XML-pohjainen käyttöliittymäkieli, joka toimii yhdessä WSDL:n kanssa. Sen tavoitteena on antaa yrityksille mahdollisuus hyödyntää verkkopalveluiden voimaa luodakseen prosesseja, jotka heijastavat muuttuvia liiketoiminnan vaatimuksia. Kielen avulla yritykset voivat esitellä sovelluksensa ja resurssinsa verkkopalveluina, jotta muut yritykset löytävät ne nopeasti ja voivat käyttää niitä liiketoimintaprosesseissaan.

Vuodesta 2002 lähtien WSCI:tä on kehittänyt W3C-konsortion työryhmä (Web Services Choreography Working Group on järjestetty);
BPEL4WS:n kehittämistä varten vuonna 2003 OASIS-konsortioon perustettiin tekninen komitea - OASIS Web Services Business Process Execution Language TC (WS-BPEL TC).

BPEL määrittelee rakenteet, joita tarvitaan palvelujoukon muodostamiseen liittyville liiketoimintaprosesseille yhteistä toimintaa ja tarjouksia.

BPEL määrittelee liiketoimintaprosessien käyttäytymisen dt-palveluihin perustuen.

BPEL toteuttaa vienti- ja tuontitoimintoja käyttämällä vain verkkopalvelurajapintoja.

BPEL sopii verkkopalveluiden ydinarkkitehtuuriin, joka on rakennettu UDDI-, WSDL-, XML- ja XML Scheman päälle.

Kolme keskeistä ominaisuutta muodostavat BPEL:n perustan: asynkronisuus, säikeiden koordinointi ja poikkeusten käsittely. Kaikki ne liittyvät ongelmiin, joita kehittäjät kohtaavat integroinnin hallinnassa.

Asynchrony Asynchrony käsittelee asynkronista vuorovaikutusta, viestien korrelaatiota ja luotettavuutta. Asynkronian tuki on tarpeen verkkopalveluiden mahdollistamiseksi integraatioskenaarioissa, ja se on pakollinen työajan optimaalisen käytön kannalta (prosessoinnin paremman jakautumisen vuoksi sen avulla käyttäjät voivat puuttua liiketoiminnan kulkuun tai viivästyneen eräkäsittelyn aikana). Erottamalla palvelupyynnöt ja niitä vastaavat vastaukset asynkronisuus parantaa skaalautuvuutta ja auttaa välttämään pullonkauloja sovellusten suorittamisessa. Lisäksi se mahdollistaa keskeytymättömän suorituksen, kun palvelut ovat tilapäisesti poissa käytöstä ja kun asiakkaat ovat käynnissä offline-tilassa tai vammainen.

virtauksen koordinointi. (Säikeen koordinointi) Säikeen koordinointi sisältää rinnakkaiset suoritussäikeet, yhteyskuviot ja dynaamiset säikeet. Todellisissa sovelluksissa liiketoimintavirrat voivat sisältää monimutkaisia vuorovaikutusmalleja sekä synkronisten että asynkronisten palvelujen kanssa. Flow-koordinointi sisältää rajapinnan WSDL:n kanssa, virtaustoiminnot, XML-muuttujat ja vastaa korvauksista. BPEL käyttää WSDL:ää viitatakseen vaihdettuihin viesteihin, kutsutuihin toimintoihin ja porttityyppeihin. Stream-toiminnoilla on yhteiset XML-muuttujat, joten korvausten käsittelijöiden on tallennettava tilannekuvia tiedoista, joita käsittelijä voi käyttää. Korvausten käsittelijät voivat kumota vaiheet, jotka on jo suoritettu.

BPEL sisältää perus- ja strukturoituja toimintoja. (BPEL sisältää perus- ja strukturoidut toiminnot). Perustoiminnot koostuvat yksittäisistä vaiheista vuorovaikutuksessa palvelun kanssa, vaihdettujen tietojen käsittelemiseksi tai suorituksen aikana havaittujen poikkeusolosuhteiden käsittelemiseksi. Strukturoidut toiminnot määrittelevät suoritusjärjestyksen ja kuvaavat prosessin luomista muuntaen niiden suorittamat toiminnot rakenteiksi; Näitä rakenteita ovat tiedonkulku, ohjausmallit, ulkoisten tapahtumien käsittely, virheiden käsittely ja viestien koordinointi.

poikkeushallinta. (Poikkeustilanteiden hallinta). Poikkeushallinta käsittelee synkronisia virheitä, asynkroninen ohjaus poikkeukset ja liiketoimien korvaukset. Automatisoidaksesi liiketoimintaprosesseja, suurta vaivaa keskittyy poikkeusten hallintaan, ja BPEL tekee Web-palveluiden poikkeuksien hallinnasta helppoa. Kun poikkeuksia esiintyy, Web-palveluihin liittyvät paikalliset virhekäsittelijät kutsutaan ja asynkronisille palveluille ilmoitetaan näistä poikkeuksista.

8.7 Verkkopalvelut ASP.Netissä

ASP.Netin verkkopalveluteknologia laajentaa verkkosovellusten luomismahdollisuuksia. ASP.Net tukee tällä hetkellä kahta tapaa kehittää ja kutsua verkkopalveluita:

HTTP-protokollan kautta (yksisuuntainen synkroninen puhelu) - XML-verkkopalvelut;

Via MCF (Microsoft Communication Fundation) - asynkroninen kaksisuuntainen viestintä - MCF-verkkopalvelut.

Verkkopalvelun (verkkopalvelun) luominen sisään visuaalinen studio samanlainen kuin verkkosivun luominen. Voit myös käyttää Microsoft Visual Web Developer Web Development Tool -työkalua viittauksiin ja käyttää Visual Web Developer -ratkaisussa olevia verkkopalveluita osoitteessa paikallinen tietokone tai paikallisessa tai ulkoisessa UDDI-hakemistossa.

Käsittelemme seuraavia tehtäviä:

luo yksinkertainen XML-verkkopalvelu Visual Web Developerissa;
itsenäisen verkkosivuston luominen verkkopalvelun avulla.

Toteutamme tämän tehtävän kahden erillisen ratkaisun muodossa.

8.7.1. Verkkopalvelun luominen ASP .Netissä. Ohjaus

http://msdn.microsoft.com/en-us/library/8wbhsy70.aspx

Avaa Visual Web Developer.
valikossa Tiedosto Valitse tavara Luo verkkosivusto.

Tiedosto-Uusi-Web-sivusto

Valintaikkuna avautuu Uusi verkkosivusto

Valitse alta ASP.NET-verkkopalvelu.

ASP.NET-verkkopalvelu

Napsauta painiketta Arvostelu ja valitse polku ja palvelun nimi.
Listattu Kieli valitse c#
Napsauta painiketta OK.

Tiedosto luodaan Service.asmx huoltokoodiin viitaten

@WebService Language="C#" CodeBehind="~/App_Code/Service.cs" Class="Palvelu" %>

Ja tiedosto palvelukoodilla: Service.cs

käyttämällä järjestelmää;

käyttäen System.Linq;

käyttäen System.Web;

käyttämällä System.Web.Services-palvelua;

julkinen palvelu ()

// InitializeComponent();

Julkinen merkkijono HelloWorld() (

Palauta "Hello World";

Attribuutti määrittää verkkopalvelun nimitilan

Attribuutti koskee WSDL:n määrittelyä

Verkkopalvelun kautta käytettävän menetelmän lisääminen tapahtuu kirjoittamalla asianmukainen koodi ja määrittämällä menetelmän pääsytunniste muodossa julkinen.

Metodilla on oltava attribuutti

2. Verkkopalvelun kokoaminen ja testaus

Tallenna palvelu ja käynnistä selain

Seuraavat toiminnot ovat tuettuja. Muodollinen määritelmä, katso palvelun kuvaus .

Linkki palvelun kuvaus WSDL:ssä on palvelun kuvaus

Linkki - Hei maailma palvelupuhelun kuvaus. SOAP-pyynnön ja vastauksen rakenne ja miltä ne näyttävät käytettäessä GET- ja POST HTTP -menetelmiä.

Voit testata menetelmäkutsua napsauttamalla Suorita-painiketta.

http://tempuri.org/"> Hei maailma

Esimerkki

Palvelu, joka sisältää kaksi tapaa.

Esimerkki1()-metodi palauttaa merkkijonon "Hei ASP.Netistä!";

Summa-menetelmä palauttaa kahden parametreina välitetyn kokonaisluvun summan.

käyttämällä järjestelmää;

käyttäen System.Web;

käyttämällä System.Web.Services-palvelua;

käyttäen System.Web.Services.Protocols;

julkisen luokan palvelu: System.Web.Services.WebService

julkinen palvelu ()

//Poista seuraavan rivin kommentit, jos käytät suunniteltuja komponentteja

//InitializeComponent();

Julkinen merkkijono Esimerkki1() (

Palauta "Hei ASP.Netistä!";

Julkinen int Summa(int a, int b)

VS:ssä on sisäänrakennettu Web DeveloperServer Suoritettava, kun palvelua kutsutaan. Luotu verkkopalvelu isännöi tällä palvelimella.

Luodaan toinen verkkopalvelu lämpötilamuunnoksia varten (esimerkki MSDN:stä)

Luot verkkopalvelun, joka muuntaa Fahrenheit-lämpötilan Celsius-lämpötilaksi ja päinvastoin.

Verkkopalvelun luominen

Solution Explorerissa(Ratkaisututkimus) napsauta nimeä hiiren kakkospainikkeellaluotu verkkopalvelu

(http://localhost/TemperatureWebService) ja valitse sitten komento Lisää uusi elementti.

Luvussa Asennetut mallit visuaalinen studio valitse (Web Service) ja kenttään Nimi kirjoita Muunna.
Varmista, että valintaruutu on valittuna Sijoita koodi erilliseen tiedostoon ja paina painiketta Lisätä.

Visual Web Developer luo uuden verkkopalvelun, joka koostuu kahdesta tiedostosta. Convert.asmx-tiedosto on tiedosto, jota voidaan kutsua kutsumaan verkkopalvelumenetelmiä, ja se osoittaa verkkopalvelun koodiin. Itse koodi on luokkatiedostossa (CONVERT.cs) App_Code-kansiossa. Kooditiedosto sisältää verkkopalvelun mallin. Kooditiedosto sisältää jonkin verran koodia verkkopalvelumenetelmälle.

Tämä esimerkki luo kaksi menetelmää yhteen verkkopalveluun. Ensimmäinen menetelmä muuntaa Fahrenheit-lämpötilan Celsius-lämpötilaksi ja toinen menetelmä muuntaa Celsius-lämpötilan Fahrenheit-lämpötilaksi.

Voit luoda muunnosmenetelmiä seuraavasti:

Lisää seuraava koodi luokkaan heti HelloWorld-metodin jälkeen:

Huomaa, että funktion nimiä edeltää attribuutti (>) osana funktion määritystä.

Kun olet syöttänyt toiminnot, tallenna tiedosto.

Täysi koodi alla.

käyttäen System.Collections;

käyttäen System.Linq;

käyttäen System.Web;

käyttämällä System.Web.Services-palvelua;

käyttäen System.Web.Services.Protocols;

käyttäen System.Xml.Linq;

/// Muuntamisen yhteenvetokuvaus

// Jos haluat sallia tämän Web-palvelun kutsumisen komentosarjasta ASP.NET AJAXin avulla, poista seuraavan rivin kommentit.

public class Muunna: System.Web.Services.WebService(

julkinen Muunna()(

//Poista seuraavan rivin kommentit, jos käytät suunniteltuja komponentteja

//InitializeComponent();

Julkinen merkkijono HelloWorld() (

Palauta "Hello World";

Julkinen kaksinkertainen FahrenheitToCelsius (kaksinkertainen Fahrenheit)

Paluu ((Fahrenheit - 32) * 5) / 9;

Julkinen kaksinkertainen Celsius-Fahrenheit (kaksinkertainen Celsius)

Paluu ((Celsius * 9) / 5) + 32;

Nyt voit testata verkkopalvelua Visual Web Developerissa.

Voit testata verkkopalvelua seuraavasti:

Valitse Solution Explorerissa Convert.asmx ja paina CTRL+F5.

Verkkopalvelu avataan ja selaimeen ilmestyy sivu, joka näyttää verkkopalvelun tarjoamat menetelmät.

Napsauta painiketta Celsius-Fahrenheit Se joka kutsuu tätä menetelmää.

Näkyviin tulee sivu, joka pyytää parametriarvoja CelsiusToFahrenheit-menetelmälle.

Kentällä Celsius syötä 100 ja napsauta painiketta koota.

Uusi ikkuna näyttää XML-tiedot, jotka verkkopalvelu palauttaa kutsuttaessa CelsiusToFahrenheit-menetelmää. Merkitys 212 renderöity XML:ssä.

Sulje selain, joka sisältää menetelmän tulokset.
Napsauta painiketta lähdeselaimessa Takaisin palataksesi menetelmäluetteloon.
Klikkaus Fahrenheitto Celsiukseen ja varmista, että menetelmä palauttaa odotetun tuloksen.

Jos syötät 212, FahrenheitToCelsius-metodi palaa 100 .

Sulje selain.

Kun verkkopalvelu on luotu, seuraava vaihe on sen kuluttaminen.

8.7.2. Verkkopalvelun käyttäminen sovelluksessa

Nyt kun verkkopalvelu on luotu, seuraava askel on luoda web-sivusto, joka käyttää luotua verkkopalvelua. Sinun on luotava erillinen verkkosivusto, jossa on sivu, josta juuri luodut verkkopalvelumenetelmät toimivat.

Tätä varten sinun on luotava asiakassovellus (palvelun kuluttaja). Luodaan ASP.Net-sivu tällaiseksi asiakkaaksi.

Luodaan esimerkiksi sivu kahdella painikkeella, kun sitä napsautetaan, palveluita kutsutaan.

Verkkopalveluun soittaminen asiakassovelluksesta tapahtuu välitysluokan (proxy-luokan) kautta.

1. Luo verkkosivusto:

valikossa Tiedosto Valitse tavara Luo verkkosivusto.
Luvussa Asennetut Visual Studio -mallit valitse ASP.NET Web Host.
Kirjoita nimi TemperatureWeb.
Listattu Kieli valitse C#
Napsauta painiketta OK.

Visual Web Developer luo uuden paikallisen IIS-Web-sivuston ja uuden sivun nimeltä Default.aspx.

Verkkopalvelu on komponentti, johon voidaan viitata sovelluksessa. Siksi on tarpeen luoda linkki siihen.

Luo linkki verkkopalveluun seuraavasti:

valikossa Verkkosivusto valitse joukkue Lisää verkkolinkki.

Valintaikkuna avautuu Verkkolinkin lisääminen kuten seuraavassa kuvakaappauksessa näkyy.

Listattu URL-osoitteet kirjoita seuraava verkkopalvelun URL-osoite ja napsauta painiketta Siirtyminen:

http://localhost/TemperatureWebService/Convert.asmx

Kun Visual Web Developer löytää verkkopalvelun, verkkopalvelun tiedot näytetään valintaikkunassa Verkkolinkin lisääminen.

Huomautus

Jos et voi lisätä verkkopalvelun viittausta, välityspalvelinta ei ehkä ole määritetty oikein. Microsoft Internet Explorerissa valikossa Palvelu Valitse tavara Internet-asetukset, valitse välilehti Liitännät ja napsauta sitten painiketta LAN-asetukset. Valintaruutu Älä käytä välityspalvelinta paikallisille osoitteille. Aseta myös välityspalvelimen osoitekenttään välityspalvelimen tarkka nimi sen sijaan Internetin käyttöoikeudet Explorer tunnistaa välityspalvelimen itsenäisesti. Lisätietoja saat verkon järjestelmänvalvojalta.

Valitse yksi menetelmälinkeistä.

Menetelmän testisivu avautuu.

Napsauta painiketta Lisää linkki.

Visual Web Developer luo App_WebReferences-kansion ja lisää siihen kansion uutta verkkoviittausta varten. Oletuksena verkkolinkeille on määritetty nimiavaruudet, jotka vastaavat niiden palvelimen nimeä (tässä tapauksessa paikallinen isäntä). Kirjoita verkkolinkin nimiavaruuden nimi muistiin. Visual Web Developer lisää WSDL-tiedoston kansioon, joka viittaa verkkopalveluun. Se lisää myös aputiedostoja, kuten hakutiedostoja (DISCO- ja DISCOMAP-tiedostot), jotka sisältävät tietoa verkkopalvelun sijainnista.

Huomautus.

Web Developer Serverin on oltava käynnissä/

3. Soita palveluun ASP-sivulta

Esimerkki 1. Lukujen summan laskeminen

1. Luo lomake, jossa on kaksi tekstikenttää ja Määrä-painike.

Lisää menetelmäkutsu painikkeen käsittelijään.

Yhdistä localhost-nimiavaruus

käyttämällä järjestelmää;

käyttäen System.Data;

käyttäen System.Configuration;

käyttäen System.Web;

käyttämällä System.Web.Securityä;

käyttämällä System.Web.UI:ta;

käyttäen System.Web.UI.WebControls;

käyttämällä System.Web.UI.WebControls.WebPartsia;

käyttäen System.Web.UI.HtmlControls;

käyttämällä localhostia;

julkinen osittainen luokka _Oletus: System.Web.UI.Page

Suojattu void Page_Load(objektin lähettäjä, EventArgs e)

Suojattu void Button1_Click(objektin lähettäjä, EventArgs e)

Palvelu myService= new Service();

Tunniste1.Teksti = omaPalvelu.Esimerkki1();

Suojattu void Button2_Click(objektin lähettäjä, EventArgs e)

Int a,b,summa;

A = int.Parse(txt_a.Text);

B = int.Parse(txt_b.Text);

// summa = a + b;

Palvelu myService1 = uusi Palvelu();

Summa = omaPalvelu1.Summa(a,b);

Txt_summa.Teksti = summa.ToString();

Esimerkki 2. Lämpötilan käännösmenetelmien kutsuminen

Luo sivulle lomake, jossa on seuraavat kentät:

Voit kutsua verkkopalvelumenetelmiä seuraavasti:

Avaa Default.aspx-sivu ja vaihda suunnittelunäkymään.
Ryhmästä Vakio Vedä Toolboxissa seuraavat säätimet sivulle ja aseta niiden ominaisuudet seuraavan taulukon mukaisesti:

suojattu void ConvertButton_Click(objektin lähettäjä, EventArgs e)

Localhost.Convert wsConvert = uusi localhost.Convert();

Kaksinkertainen lämpötila =

System.Convert.ToDouble(TemperatureTextbox.Text);

FahrenheitLabel.Text = "Fahrenheit To Celsius = " +

WsConvert.FahrenheitToCelsius(lämpötila).ToString();

CelsiusLabel.Text = "Celsius To Fahrenheit = " +

WsConvert.CelsiusToFahrenheit(lämpötila).ToString();

Avaa sivu painamalla CTRL+F5.
Kirjoita tekstikenttään arvo, esimerkiksi 100 , ja paina painiketta Muuttaa.

Sivu näyttää tuloksen lämpötila-arvon muuntamisesta Fahrenheit-asteista Celsius-asteiksi.

Verkkopalvelun virheenkorjaus voidaan tehdä samalla tavalla kuin verkkosivujen virheenkorjaus.

Ensin sinun on määritettävä Web-palvelua isännöivä Web-sivusto ottamaan virheenkorjaus käyttöön.

Voit ottaa virheenkorjauksen käyttöön Web Service -sivustossa seuraavasti:

Web-sivuston hallintatyökalu luo Web.config-tiedoston Web-sivustolle ja määrittää määritysasetukset mahdollistamaan virheenkorjauksen.

Sulje Web-sivuston hallintatyökalu.

Nyt sinun on otettava käyttöön verkkopalvelua käyttävän sivuston virheenkorjaus.

Ota virheenkorjaus käyttöön verkkosivustolla seuraavasti:

Visual Web Developer avaa sivun kooditiedoston.

Aseta osoitin seuraavalle riville:

Web Service Discovery

Mistä muut kehittäjät tietävät verkkopalvelun olemassaolosta?

Ensinnäkin DISCOn (lyhenne sanasta Discovery) avulla - tiedostomekanismi paikallisten verkkopalvelujen etsimiseen, eli mekanismi, jolla saadaan luettelo saatavilla olevista verkkopalveluista verkkopalvelimilla olevista DISCO-tiedostoista. Lisäksi DISCO-tiedostot sisältävät tietueita käytettävissä olevien palvelujen WSDL-sopimusten sijainnista. DISCO-tiedosto on XML-tiedosto tietueilla.

On myös mahdollista käyttää VSDISCO-tiedostoja, jotka ovat samanlaisia kuin DISCO-tiedostoja, mutta niiden sisältö on tulosta dynaamisesta verkkopalveluiden hausta määritetyistä hakemistoista ja kaikista sisäkkäisistä alihakemistoista. ASP .NET yhdistää .vsdisco-tiedostotunnisteen HTTP-käsittelijään, josta se etsii tämä hakemisto ja sen asmx- ja disco-alihakemistot ja palauttaa dynaamisesti luodun DISCO-asiakirjan. Turvallisuussyistä dynaaminen haku on poistettu käytöstä joissakin .NET Frameworkin versioissa, mutta voit ottaa sen käyttöön muokkaamalla Machine.config-tiedoston merkintöjä.

Mutta miten verkkopalveluiden etsiminen globaalissa verkossa sujuu? Web-palveluiden etsimiseksi maailmanlaajuisesta verkosta Microsoft, IBM ja Ariba kehittivät yhdessä UDDI:n (Universal Description Discovery and Integration) - spesifikaation hajautettujen tietokantojen rakentamiseen, jonka avulla voit löytää verkkopalveluita. UDDI:ta tukevat sadat yritykset. UDDI-sivustot ovat itse verkkopalveluita. Kuka tahansa voi julkaista rekisterinsä UDDI:n perusteella. Useimmat kehittäjät eivät koskaan käytä UDDI-sovellusliittymää suoraan. Sen sijaan UDDI-rekistereihin päästään kehitystyökaluilla. Ne myös luovat kääreluokkia löydetyille ja valituille verkkopalveluille.

8.8 Tulokset

Tekniikka Web palvelut- Tämä moderni teknologia, joka tarjoaa uuden jakelutason. Komponenttien kehittämisen tai ostamisen ja IS:ään upottamisen sijaan ehdotetaan niiden käyttöajan ostamista ja ohjelmistojärjestelmän muodostamista, joka tekee menetelmäkutsuja itsenäisten palveluntarjoajien omistamista ja ylläpitämistä komponenteista.

Web palvelut ratkaista ongelma, joka liittyy erilaisten sovellusten integrointiin ja hajautetun tietoyhteiskunnan rakentamiseen. Tämä on tärkein perustavanlaatuinen ero verkkopalvelujen ja niiden edeltäjien välillä - hajautettujen sovellusten vuorovaikutusteknologiat, jotka jotenkin mahdollistivat tietojenvaihdon sovellusten välillä (kehitetyimpiä ovat Remote Procedure Calls (RPC), Distributed COM (DCOM) , Remote Method Invocation (RMI) ja Common Object Request Broker Architecture (CORBA)). Jokainen niistä oli kuitenkin melko vaikea toteuttaa, niillä ei ollut tarvittavaa universaalisuutta (eli se riippui silti esimerkiksi saman käyttöjärjestelmän valinnasta kaikille vaihdon osallistujille) ja mikä on erityisen huonoa, nämä tekniikat liittyivät keskenään suurilla vaikeuksilla.

Web palvelut- uusi sana hajautettujen järjestelmien teknologiassa. Erittely Open Net Environment (ONE) Sun Microsystems Corporation ja aloite. Net, Microsoft tarjoaa infrastruktuurin verkkopalveluiden kirjoittamiseen ja käyttöönottoon. Tällä hetkellä on olemassa useita verkkopalvelumääritelmiä. Web-palvelu voi olla mikä tahansa sovellus, joka käyttää Internetiä, kuten Web-sivu, jolla on dynaamista sisältöä. Enemmässä suppea merkitys Verkkopalvelu on sovellus, joka paljastaa julkisen käyttöliittymän, jota muut Web-sovellukset voivat käyttää. ONE Sun -spesifikaatio edellyttää, että Web-palvelut ovat saatavilla HTTP:n ja muiden Web-protokollien kautta, jotta tietoa voidaan vaihtaa XML-sanomien kautta ja löytää erityispalvelujen, hakupalvelujen kautta. Web-palveluihin pääsyä varten on kehitetty erityinen protokolla - Simple Object Access Protocol (SOAP), joka tarjoaa XML-pohjaisen yhteentoimivuuden monille verkkopalveluille. Verkkopalvelut ovat erityisen houkuttelevia, koska ne voivat tarjota korkeatasoista yhteentoimivuutta eri järjestelmien välillä.

Sunin ONE-arkkitehtuurin mukaan suunniteltu hypoteettinen verkkopalvelu voisi olla muodossa, jossa palvelurekisteri julkaisee Web-palvelun kuvauksen dokumenttina. .

Web-palvelujen valtava potentiaali ei riipu niiden luomiseen käytetystä tekniikasta. HTTP, XML ja muut verkkopalveluiden käyttämät protokollat eivät ole uusia. Yhteentoimivuus ja verkkopalvelujen skaalautuvuus tarkoittaa, että kehittäjät voivat luoda nopeasti suuria sovelluksia ja suuremmat verkkopalvelut pienemmiltä verkkopalveluilta. Sun Open Net Environment -spesifikaatiossa kuvataan rakentamisen arkkitehtuuri älykkäät verkkopalvelutÄlykkäät verkkopalvelut käyttävät yhteistä toimintaympäristöä. Jakamalla kontekstin älykkäät verkkopalvelut voivat suorittaa standarditodennuksen rahoitustapahtumille, tarjota suosituksia ja ohjeita, jotka perustuvat hankkeeseen osallistuvien yritysten maantieteelliseen sijaintiin. sähköinen liiketoiminta.

Jotta voit luoda sovelluksen, joka on verkkopalvelu, sinun on käytettävä useita tekniikoita.

Näiden tekniikoiden suhde on perinteisesti esitetty kuvassa. 10.1.

Riisi. 10.1.

Itse asiassa verkkopalvelut ovat yksi toteutusvaihtoehdoista komponenttiarkkitehtuuri, jossa sovellusta pidetään joukkona komponentteja, jotka ovat vuorovaikutuksessa toistensa kanssa. Kuten toistuvasti on todettu, eri alustoilla toimivien komponenttien vuorovaikutus on melko vaikea tehtävä, erityisesti se vaatii kehittämistä viestintäprotokolla, joka ottaa huomioon eri alustojen välisen tiedonsiirron erityispiirteet. Yksi Web-palveluiden harkitun teknologian taustalla olevista pääajatuksista on binaarin hylkääminen viestintäprotokolla. Järjestelmän komponenttien välinen sanomien vaihto tapahtuu XML-sanomien välittämisellä. Koska XML-viestit ovat tekstitiedostoja, lähetyksen kuljetusprotokolla voi olla hyvin erilainen - XML-viestejä voidaan lähettää HTTP-, SMTP-, FTP-protokollien kautta, ja erilaisten kuljetusprotokollien käyttö on sovelluksille läpinäkyvää. Kuten jo mainittiin, protokollaa, joka mahdollistaa verkkopalvelujen vuorovaikutuksen, kutsutaan SAIPPUA (Simple Object Access Protocol). Se on määritelty XML:n perusteella. SAIPPUA varmistaa hajautettujen järjestelmien vuorovaikutuksen käytetystä objektimallista tai alustasta riippumatta. Tiedot sisällä SAIPPUA lähetetään erityismuotoisina XML-asiakirjoina. SAIPPUA ei vaadi mitään erityistä siirtoprotokollaa. Todellisissa sovelluksissa siirto toteutetaan kuitenkin useimmiten SAIPPUA-viestit lähettäjältä HTTP-protokolla. Sitä käytetään laajalti myös kuljetusvälineenä SMTP-protokolla, FTP ja jopa "puhdas" TCP. Niin, SAIPPUA määrittää mekanismin, jolla verkkopalvelut voivat kutsua toistensa toimintoja. Tietyssä mielessä tämän protokollan toiminta muistuttaa kutsua etäproseduuriin - soittaja tietää verkkopalvelun nimen, sen menetelmän nimen, parametrit, jotka menetelmä hyväksyy, muotoilee kutsun tälle menetelmälle muodossa SAIPPUA-viestit ja lähettää ne verkkopalveluun.

Kuvattu lähestymistapa soveltuu kuitenkin vain, jos Web-palvelun toteuttamien menetelmien "allekirjoitukset" tunnetaan etukäteen. Mutta entä jos ei ole? Tämän ongelman ratkaisemiseksi verkkopalvelumalliin on lisätty lisäkerros - palvelurajapintojen kuvauskerros. Tämä kerros esitetään kuvauksena WSDL.

W3C määritelmän mukaan " WSDL- XML-muoto kuvausta varten verkkopalvelut joukkona rajallisia operaatioita, jotka toimivat dokumenttisuuntautuneen tai prosessisuuntautuneen informaation sisältävillä viesteillä. WSDL kuvaa täysin verkkopalvelun käyttöliittymän ulkomaailmaan. Se tarjoaa tietoa palveluista, joita voidaan saada palvelun menetelmillä ja miten niihin pääsee käsiksi. Jos verkkopalvelumenetelmän allekirjoitusta ei siis tarkasti tunneta (esimerkiksi se on muuttunut ajan myötä), kohdeverkkopalvelua voidaan kysyä WSDL-description - tiedosto, johon nämä tiedot sisältyvät.

Seuraava teknologian kerros on palvelu. Universal Description, Discovery and Integration (UDDI).Tämä tekniikka sisältää verkkopalvelurekisterin ylläpitämisen. Yhdistämällä tähän rekisteriin kuluttaja voi löytää tarpeisiinsa parhaiten sopivat verkkopalvelut. Tekniikka UDDI mahdollistaa halutun palvelun etsimisen ja julkaisun, ja nämä toiminnot voidaan suorittaa sekä henkilö että toinen verkkopalvelu tai erityinen asiakasohjelma. UDDI, puolestaan on myös verkkopalvelu.

Siten verkkopalvelut ovat toinen järjestelmän toteutus väliohjelmisto. Tämän tekniikan erottuva piirre on sen riippumattomuus käytetystä ohjelmistosta ja laitteistosta sekä laajalti käytettyjen avoimet standardit(kuten XML) ja tavallisia viestintäprotokollia.

Tällä hetkellä Web-palvelut ovat erittäin aktiivisesti edistetty tekniikka, ja ne on asetettu välineeksi useiden ongelmien ratkaisemiseen.

On huomattava, että niiden käytöllä voidaan rakentaa myös ns. "standardi" sovelluksia, missä palvelimen osa.

Simple Object Access Protocol (SOAP)

Perusprotokolla, joka tarjoaa vuorovaikutusta Web-palveluympäristössä, on protokolla

Tässä artikkelissa haluaisin käsitellä kysymyksiä, jotka liittyvät ohjelmien väliseen vuorovaikutukseen suunniteltujen verkkopalvelujen suunnitteluun. Ns. integraatioverkkopalvelut. Ensinnäkin nämä ovat palveluita, jotka toimivat erilaisia ratkaisuja Enterprise Applications Integration (EAI) -luokassa sekä B2B-ratkaisuissa. Paljon kirjoja ja artikkeleita on omistettu verkkopalveluiden kehittämiseen eri alustoilla, mutta suunnittelukysymyksiä käsitellään paljon vähemmän. Löydät tonnia SOA-loitsuartikkeleita, jotka ovat täysin hyödyttömiä, kun alat suunnitella omia. verkkopalvelu.
Tarkastellaanpa siis tilannetta, jossa käsissäsi on kaksi toimivaa järjestelmää (tai kahden järjestelmän projektia) ja edessäsi on vuorovaikutuksen järjestäminen niiden välillä. Olet kyllästynyt tuonti-/vientitiedostoihin perustuviin synkronointijärjestelmiin ja olet valinnut muodikkaan, modernin ja kätevän verkkopalvelutekniikan. Yritän puhua siitä, mihin sinun tulee kiinnittää huomiota ja miten välttää tyypilliset virheet suunniteltaessa verkkopalvelua kahden järjestelmän vuorovaikutukseen.

Jotain SOA:ta

Ja kuitenkin, ensin muutama sana pahamaineisesta SOA:sta. Termi Service Oriented Architecture (SOA) on kärsinyt melkoisen umpimähkäisen markkinoinnin käytöstä. Sitä käytetään niin usein erilaisissa yhteyksissä, että SOA:sta on nyt vaikea sanoa muuta lopullista kuin että se on "palvelusuuntautunut arkkitehtuuri".
SOA:lla on kuitenkin sama oikeus elämään kuin "asiakas-palvelinarkkitehtuuri" tai "monikerroksinen arkkitehtuuri". Kuten mikä tahansa muu "arkkitehtuuri", SOA esittelee joukon abstraktioita ja sääntöjä, jotka auttavat meitä kehittämään tietyn luokan sovelluksia. Tässä nimenomaisessa tapauksessa on hyödyllistä noudattaa SOA:n periaatteita kehitettäessä mekanismeja sovellusten vuorovaikutukseen ja integrointiin koko yrityksessä (Enterprise Applications Integration - EAI).
Joten aluksi SOA pitää sovelluksia palveluina tai palvelukokoelmina, jotka vaihtavat viestejä joko suoraan tai jonkin integrointimekanismin kautta. Näiden palvelujen on täytettävä useita ehtoja tai vaatimuksia.
Ensinnäkin palvelulla on oltava määritelty "liikearvo", toisin sanoen palvelulla on oltava sovellusarvo. Jos et pysty yksinkertaisin sanoin selittämään asiakkaalle tai järjestelmän käyttäjälle, mihin palvelusi on tarkoitettu, niin kyseessä on SOA:n kannalta epäonnistunut palvelu. Esimerkki huonosta palvelusta: "Palvelu maailmanlaajuisesti yksilöllisten tunnisteiden hankkimiseen." Esimerkki hyvistä palveluista: "Yritystyöntekijätietopalvelu" tai "Osuusreskontrapalvelu".
Toiseksi SOA:n näkökulmasta palvelujen tulee olla itsenäisiä ja riippumattomia. Tämä on välttämätöntä, jotta voimme SOA:n tapaan yhdistää palvelun toiseen liiketoiminnan tarpeiden mukaan. Jos halusimme käyttää "Laskujen vastaanotto- ja käsittelypalvelua" ja näin tehdessämme selvisi, että meidän pitäisi asentaa ja käyttää "Budjetointi- ja taloussuunnittelupalvelua", "Pääkirjapalvelua" ja kymmenkunta muuta palvelua, niin SOA:n näkökulmasta kaikki se näyttää inhottavalta.
Kolmanneksi palvelun on oltava sovelluksen näkökulmasta toiminnallisesti täydellinen. Tämä vaatimus täydentää edellistä. Esimerkiksi "Maksulaskujen vastaanotto- ja käsittelypalvelu" mahdollistaa sovelluksen lisäämisen, mutta ei sen tilan seurantaa. Mutta periaatteessa saamme hakemuksista raportin, josta saat selville hakemuksen tilasta. Eikö olekin tuttu tilanne? SOA:n näkökulmasta ja mistä tahansa näkökulmasta tämä ei ole oikein. Palvelun on suoritettava kaikki sen tarjoamaan sovellusalueeseen tai liiketoimintaprosessiin liittyvät pääasialliset liiketoiminnot.
Neljänneksi kaikkien palvelujen on pystyttävä antamaan kuvauksensa jossain standardoidussa muodossa. WSDL ja UDDI ovat muunnelmia palvelun kuvausformaateista.
Viidenneksi palvelujen tulee olla hajautettuun, tilattomaan, asynkroniseen viestintään suuntautuvia. Tämä on tyypillistä useimmille nykyaikaisille hajautetuille järjestelmille ja on erittäin tärkeä vaatimus. Riittää, kun muistutetaan, että asiakas-palvelin-arkkitehtuuri on keskittynyt synkroniseen vuorovaikutukseen tilallisuuden kanssa, ja tästä seikasta on tullut keskeinen rajoitus tämän arkkitehtuurin jatkokehityksessä.
Kuudenneksi SOA olettaa, että täyttämällä aiemmat vaatimukset, palvelut pystyvät yhdistämään vuorovaikutukseen toistensa kanssa käyttämällä erilaisia integrointityökaluja, kuten viestivälittäjiä ja reitittimiä, työnkulkupalvelimia ja niin edelleen. ja niin edelleen. Keskeinen asia tässä on se, että integrointiskriptit perustuvat konfiguraatioon, usein visuaaliseen, eivätkä erityisen "integraatiokoodin" kehittämiseen, kuten useimmissa tapauksissa nykyään tehdään.
Tältä näyttävät tärkeimmät virstanpylväät, joihin meidän tulisi keskittyä ja joiden tulisi rajoittaa integraatioverkkopalveluiden suunnittelussa ja kehittämisessä omaksuttua suunnitteluajatteluamme.

Palvelusopimuksen suunnittelu.

Kun Microsoft käytti termiä "palvelusopimus" Windows Communication Foundationissa - WCF:ssä (entinen Indigo), sillä on kaikki mahdollisuudet tulla de facto vakiotermiksi.
Palvelusopimus on kuvaus sen kaikkien toimintojen (menetelmien) allekirjoituksista sekä kuvaus tietomuodoista, joita se toimii syöttö- ja lähtösanomina.
Verkkopalveluiden osalta sopimus on kuvattu tyhjentävästi WSDL-palveluskeemalla. Olet kuitenkin samaa mieltä siitä, että WSDL ei ole kovin hyvin sopeutunut ihmisen havainnointiin. Paljon selkeämpi sopimus voidaan esittää UML-luokkakaaviona. Onneksi suurin osa nykyaikaiset alustat Web-palvelujen kehittämiseen tarjotaan automaattisen sukupolven toiminto WSDL-kuvaukset palvelut.
Oikein suunniteltu palvelusopimus on avain menestykseen ja tae, että palvelusi elää pitkän ja onnellisen elämän ja kuolee luonnolliseen kuolemaan, koska sen tilalle tulee uusi tekniikka, josta emme tällä hetkellä tiedä mitään.
Microsoft tarjoaa erityinen termi– "sopimus ensin" kuvaamaan sopimus ensin -suunnittelulähestymistapaa. Siinä oletetaan, että palvelun suunnittelu aloitetaan viestien (datan) XSD-skeemojen kuvauksella, jonka jälkeen luodaan palvelun toiminnoista WSDL-kuvaus, josta generoidaan palveluluokan koodi. Ja vasta sen jälkeen siirry logiikan toteuttamiseen. Ajatus on hyvä, mutta toistan, että XSD:n ja WSDL:n kanssa työskentely ei ole kovin kätevää edes käyttämällä visuaalisia työkaluja, kuten XmlSpy. Myöskään "ota ensin" -periaate yksin ei takaa, että saamme oikean palvelusopimuksen.
Minulle "kontakti ensin" -periaate tarkoittaa sitä, että palvelua suunniteltaessa meidän tulee ajatella ensin sen sopimusta ja viimeiseksi toteutustietoja. Tulevaisuuden palvelua kannattaa katsoa ulkopuolelta, tämän palvelun tietojen kuluttajan silmin. Tämä näkymä helpottaa palvelun vaatimusten siirtämistä sen tarjoamiin toimintoihin. Kehitämme esimerkiksi palvelua, joka tarjoaa tietoja yrityksen työntekijöistä. On loogista tarjota siihen toiminto, joka palauttaa luettelon kaikista työntekijöistä. Vaatimusten analysoinnin aikana voi kuitenkin käydä ilmi, että palvelutietomme kuluttaja on kiinnostunut ennen kaikkea tietyn osaston työntekijöiden luettelosta. Tämä kertoo meille, että meidän pitäisi lisätä toimintosopimukseen parametri, joka palauttaa työntekijöiden luettelon, jonka avulla voimme suodattaa tietyn osaston työntekijät, tai meidän tulisi erottaa tämä toiminto erilliseksi palveluoperaatioksi. Tällainen lähestymistapa olisi "sopimus ensin" -periaatteen mukainen. Päinvastoin voisimme asettaa palvelumme tietojen kuluttajalle velvollisuuden valita tarvitsemansa osaston työntekijät yleisestä luettelosta. Tämän strategian noudattaminen integraatiopalveluita suunniteltaessa on huono käytäntö. Tätä yksittäistä tapausta analysoimalla voidaan todeta, että tällainen ratkaisu ei ole optimaalinen palvelukuormituksen tai liikennemäärän kannalta, ja myös, että tällainen ratkaisu vähentää turvallisuutta. Yleisesti voidaan todeta, että yksinkertaisuuden ja yleismaailmallisuuden periaatteet eivät saisi vallita palvelua suunniteltaessa. Palvelun monipuolisuus tulee saavuttaa huolellisella suunnittelulla. On erittäin vaikeaa antaa käytännön suosituksia tähän suuntaan. Ei ole helppoa luoda palvelua, joka ei koostu yhdestä menetelmästä, joka heittää ulos kaikki järjestelmän sisäiset tiedot ja joka on samalla riittävän universaali, jotta sitä voi käyttää paitsi kuluttaja, jolle palvelun suunnittelit, vaan myös keneltä tahansa muulta. Tämän saavuttamiseksi sinun tulee kiinnittää huomiota palvelusopimuksen toiminnalliseen täydellisyyteen.
Katsotaanpa esimerkkiä. Oletetaan, että on olemassa jokin kirjanpito- ja ostovelkojen täsmäytysjärjestelmä niiden luokasta, jotka on merkitty termillä Ostovelat. Järjestelmän avulla voit syöttää laskutietoja, varmistaa niiden hyväksymisen liiketoimintaprosessin ja muodostaa maksuja vuorovaikutuksessa kirjanpitojärjestelmän kanssa. Laskujen syöttäminen ja niiden koordinointi tapahtuu järjestelmän käyttöliittymän kautta. Tehtävämme on luoda verkkopalvelu, jonka kautta muut järjestelmät voivat luoda laskuja ja seurata niiden tilaa.
Yksinkertaisuuden vuoksi oletetaan, että maksulaskulla on seuraava rakenne:

Missä:
Numero - luonnin aikana määritetty yksilöllinen tilinumero
RecipientID - linkki vastapuolten hakemistoon, joka tallentaa kaikki maksunsaajan tiedot
Summa - maksettava summa
PaymentDate - maksupäivä
CategoryID - linkki maksukategorioiden hakemistoon
Omistaja - tilin luoneen työntekijän nimi
Kuvaus - kuvaus
Tila - tilin tila, jonka ympärille tilin täsmäytysprosessi on rakennettu.
Alkuperäiset vaatimukset ovat siis meille selvät. Myös laskun esittämisen tietoskeema on selkeä. Esitetyn kaavion perusteella luodaan tällainen XML-skeema, joka sopii meille täydellisesti:

Yritetään nyt hahmotella palvelumenetelmien allekirjoitus. Vaatimusten perusteella meille on selvää, että palvelussa tulee olla menetelmiä, joilla voit luoda, tarkastella ja poistaa maksulaskuja. Tuloksena on palvelu, jossa on kolme tapaa:

Näyttää aivan kamalalta! Katsotaan mikä tässä on vialla.
AddPayment()-menetelmä tilin lisäämiseksi ottaa Maksurakenteen parametriksi ja palauttaa tilille määritetyn numeron. Maksurakenne ei ole kovin sopiva tietotyyppi tämän menetelmän parametrille, koska se sisältää useita kenttiä, joiden täyttö riippuu järjestelmän sisäisestä liiketoimintalogiikasta. Nämä ovat Number-, State- ja Owner-kentät. Emme tunne näitä liiketoimintasääntöjä, emmekä osaa täyttää näitä kenttiä. Laskun luomiseksi meidän on määritettävä: vastaanottaja, maksun summa, päivämäärä, luokka ja kuvaus. Siksi on järkevää luoda menetelmä täsmälleen näillä parametreilla, joka luo laskun maksusta ja palauttaa sen Maksurakenteessa.
ListPayments()-menetelmä palauttaa tililuettelon maksurakenteiden joukona. Ehkä järjestelmän pitäisi palauttaa vain ne tilit, jotka tämä käyttäjä on luonut. Vastaavan parametrin puuttumisen menetelmän allekirjoituksesta ei kuitenkaan pitäisi yllättää. Luotettavampi ja turvallisempi tapa saada käyttäjätiedot on ottaa ne todennustiedoista. Ajan myötä järjestelmään voi kertyä valtava määrä laskuja, eikä tämä menetelmä häiritsisi lähetetyn luettelon suodatusparametreja päivämäärän mukaan.
Lopuksi RemovePayment()-menetelmä hyväksyy tilinumeron ja palauttaa tosi, jos poisto onnistui, ja false muuten. Boolen käyttäminen tuloksena ei ole paras ratkaisu tässä tapauksessa. Syyt poistotoiminnon epäonnistumiseen voivat olla hyvin erilaisia kuin pelkkä määritetyn numeron tilin puuttuminen järjestelmän loogisten rajoitusten rikkomiseen (esimerkiksi et voi poistaa tiliä, jonka tila on Sitoutunut). Tilanne on melko yleinen. Virhe voi tapahtua mitä tahansa verkkopalvelumenetelmää suoritettaessa, ja onneksi verkkopalvelukehys tarjoaa vakiolähestymistavan tämän ongelman ratkaisemiseen. Virhetietojen välittämiseen käytetään SOAP-sanomaa, jonka rungossa on Vika-elementti ja tiedot virheestä. Näin ollen meidän ei tarvitse laajentaa verkkopalvelusopimustamme virheilmoitusten välittämiseksi, ja RemovePayment()-menetelmän tapauksessa voimme täysin pärjätä ilman palautusarvoa. Jos tilin poistaminen epäonnistuu, syy ilmoitetaan virheilmoituksessa.
Kaikkien muutosten jälkeen verkkopalvelumme näyttää tältä:

Näyttää paljon paremmalta, mutta ongelmat jatkuvat.
Katsotaanpa CreatePayment()-menetelmää. Tilin luomiseksi meidän on välitettävä viisi parametria. Meillä ei ole ongelmia määrän, päivämäärän ja desc-parametrien kanssa. Mutta mistä saat linkit vastaanottajaan (vastaanottaja) ja luokkaan (luokka)? Kuten jo mainitsin, nämä tiedot ovat linkkejä vastaavien järjestelmämme hakemistojen elementteihin. Ja nyt meille tulee selväksi, että voidaksemme käyttää verkkopalveluamme menestyksekkäästi, meidän on tarjottava pääsy näiden hakemistojen arvoihin.

Näin ollen verkkopalvelumme lopullinen sopimusmuoto täydennettiin kahdella menetelmällä EnumRecipient() ja EnumCategory() sekä kahdella tietotyypillä RecipientInfo ja CategoryInfo. Niitä ei ollut alkuperäisessä sopimuksessa, eikä näiden menetelmien tarvetta määrätä alkuperäisissä vaatimuksissa. Niiden tarkoituksena on varmistaa palvelusopimuksemme syntaktinen täydellisyys. Nyt palveludatan kuluttaja voi kutsua EnumRecipient()- ja EnumCategory()-menetelmiä saadakseen vastaanottaja- ja luokkien luettelot, valita niistä tarvittavat arvot ja kutsua sitten CreatePayment()-metodia tilin luomiseksi.
Nyt voidaan sanoa, että olemme suunnitelleet toiminnallisesti ja syntaktisesti täydellisen palvelun. Palvelumme on myös varsin universaali, ja suurella todennäköisyydellä sitä voidaan käyttää integroitavaksi muihin vastaavia tehtäviä kohtaaviin järjestelmiin. Lisäksi palvelusopimus ja sen WSDL-kuvaus sisältävät kaikkien sanomien täydelliset dataskeemat. Tämä on erittäin tärkeää palvelullemme, jotta voimme käyttää integrointityökaluja, kuten BizTalk Server, Fiorano ESB, Sonic ESB jne.
Viimeisellä hetkellä haluaisin kiinnittää huomion. Palvelun välittämän tiedon muoto on erittäin tärkeä. Kehittäjät lankeavat usein toiseen kahdesta ääripäästä. Ensimmäinen näistä on "naked Xml":n käyttö kaikkien viestien muotona. Syyt tähän voivat olla hyvin erilaisia, yrityksistä käyttää olemassa olevaa koodia Xml-tietojen tuontiin ja vientiin, verkkopalveluiden olemuksen ymmärtämiseen Xml-viestintämekanismina liian kirjaimellisesti. Tämän lähestymistavan haittapuoli on ilmeinen - tietoskeema ei kuulu palvelusopimuksen WSDL-kuvaukseen, mikä vaikeuttaa sen käyttöä. Mielestäni on vain yksi tapaus, jossa tällainen lähestymistapa on perusteltu. Näin on silloin, kun emme tiedä etukäteen lähetettyjen tietojen muotoa. Kaikissa muissa tapauksissa tulee käyttää kirjoitettuja viestejä.
Toinen ääripää on ensimmäisen vastakohta, ja se ilmenee siinä, että kehittäjät yrittävät hyödyntää palvelusopimuksessa järjestelmässä olevia sisäisiä tiedonesitysmuotoja. Todellakin, jos rakenteet ja luokat tietojen esittämistä varten (Data Transfer Objects) on jo määritelty järjestelmässä, niin miksi et käyttäisi niitä palvelusopimuksessa? Tämä ei ole aina hyvä idea. Sisäiset tietomuodot eivät välttämättä ole mukavia palveluasiakkaalle. Niillä voi olla tietty muoto, jota asiakaspuoli ei tue. Esimerkki tällaisesta DataSet-muodosta Microsoft ADO.NET:stä. DataSet-tiedot muunnetaan täydellisesti XML-muotoon, ja ASP.NET-verkkopalvelut voivat käyttää niitä. Tämä on kuitenkin sisäistä Microsoftin muoto, joka ei ole alan standardi, sillä on oma Xml-esityksen muotoilu, joka voi vaikeuttaa muiden käyttöä näiden tietojen kanssa. On monia tapauksia, joissa DataSetin käyttö on perusteltua ja kätevää, mutta integraatiopalvelut eivät kuulu niihin.
Yleiset suositukset verkkopalveluviestimuotojen suunnittelulle ovat siis seuraavat. Yritä aina käyttää kirjoitettuja viestejä, joiden muoto on kuvattu tietyllä Xsd-skeemalla. Suunnittele viestin muoto toiminnallisten vaatimusten mukaan ja vain, jos tuloksena oleva muoto vastaa järjestelmän sisäistä tietomuotoa, kannattaa harkita sisäisen muodon käyttöä.

Vuorovaikutusprotokolla ja sen vaikutus sopimukseen

Verkkopalvelun vuorovaikutusprotokollalla tarkoitetaan sitä osaa vaatimuksista, joka kuvaa palvelun ja asiakkaan välisen vuorovaikutuksen järjestystä, tiedonsiirron suuntaa sekä sellaisia palvelun käyttäytymisen näkökohtia, kuten transaktio, asynkroninen jne.
Vuorovaikutusprotokolla ja palvelusopimus liittyvät läheisesti toisiinsa. lisäksi tarpeeksi yksinkertaisia tapauksia, kun on yksi palvelu ja sen asiakas, on monimutkaisempia, joissa vuorovaikutusprotokolla edellyttää kahden tai useamman palvelun läsnäoloa. Esimerkki tällaisesta protokollasta on ASAP asynchronous communication protocol.
En paljasta paljoa, jos sanon, että hyvä tapa rakentaa palvelusopimus (ainakin siihen liittyvien toimintojen osalta) on käyttää UML-vuorovaikutuskaavioita. Henkilökohtainen mielipiteeni on, että sekvenssikaavio antaa parhaat tulokset. Kuvassa on esitetty järjestyskaavio asiakkaan ja palvelun välisestä vuorovaikutuksesta edellä käsitellystä AccountsPayable-esimerkistä. Valitettavasti tämä esimerkki on tarpeeksi yksinkertainen saadakseen käsityksen siitä, kuinka sekvenssikaaviot helpottavat palvelusopimuksen suunnittelua.

Monimutkaisimmissa tapauksissa voi olla tarpeen rakentaa tilakaavio vuorovaikutusprotokollalle. Tässä tapauksessa tilakaavion siirtymät edustavat palvelun toimintaa.

Turvallisuuskysymykset

Kun palvelusopimus on laadittu, ja joskus ennenkin, täyspitkä suunnittelija kohtaa turvallisuusongelmia. Ajat, jolloin verkkopalveluita kutsuttiin epäkypsäksi teknologiaksi, joka ei kyennyt tarjoamaan tietoturvaa, ovat kauan menneet. Verkkopalvelut voivat olla luotettavia ja turvallisia. Ja he eivät ehkä olekaan. Kaikki riippuu meistä.
Kerrataan ongelmat, jotka on ratkaistava turvallisen palvelun suunnittelemiseksi:

Palveluasiakkaan todennus
Palveluasiakkaiden valtuutus
Tiedonsiirron turvallisuus
Identiteettien tallentaminen asiakkaiden yhdistämiseksi palveluun

Todennus on prosessi, jolla varmistetaan käyttäjän henkilöllisyys hänelle annettujen tunnistetietojen perusteella. Todennusmekanismien vahvuus on kriittinen koko sovelluksen turvallisuuden kannalta. Siksi sinun tulee heti unohtaa anonyymi pääsy". Paras skenaario todennusta varten on hyödyntää käyttämäsi verkkopalvelualustan tarjoamia mahdollisuuksia. Tyypillisesti autentikointiin käytetään erikoisprotokollia (Kerberos, NTLM), joiden tuki on sisäänrakennettu alustaan. Omien todennusmekanismien käyttöönotto on todennäköisesti kallista ja mahdollisesti vaikeaa toteuttaa ja ylläpitää.
Valtuutus on prosessi, jossa käyttäjälle myönnetään oikeus käyttää toimintoja ja tietoja. Luonnollisesti, jotta käyttäjä voi valtuuttaa, hän on ensin todennettu. Ymmärrä ero todennuksen ja valtuutuksen välillä. Todennus vastaa kysymykseen "kuka" asiakas on, ja valtuutus vastaa kysymykseen "mitä" tämä asiakas voi tehdä. Suurimmassa osassa tapauksista liiketoimintasäännöt, joilla tietylle käyttäjälle myönnetään käyttöoikeudet tiettyihin tietoihin ja toimintoihin, määritetään itse sovelluksessa. Ja siksi valtuuttaminen on palvelun tarjoavan sovelluksen vastuulla. Valtuutusmekanismien toteuttamiseen on monia menetelmiä, käytäntöjä ja malleja, joiden kuvauksesta voi olla erillinen artikkeli.
Todennuksen ja valtuutuksen lisäksi tietojen suojaus sen kuljetuksen aikana palvelun ja sen asiakkaan välillä on kolmas komponentti verkkopalvelun turvallisuuden varmistamisessa. Suojausaste määräytyy tietojen luonteen mukaan. Tietojen suojaamiseen on kaksi tapaa: digitaalinen allekirjoitus ja salaus.
Tietojen aitouden varmentamiseen käytetään digitaalista allekirjoitusta. Se ei suojaa tietoja luvattomalta lukemiselta, koska tietoja ei ole salattu. Digitaalisella allekirjoituksella voit varmistaa, että tiedot kuuluvat allekirjoituksen omistajalle ja että tietoja ei ole muutettu allekirjoituksen jälkeen. Digitaalinen allekirjoitusmekanismi on melko yksinkertainen. Se perustuu epäsymmetristen salausalgoritmien käyttöön, jotka käyttävät avaimia, joista toinen on yksityinen (yksityinen) ja toinen julkinen (julkinen). Epäsymmetristen algoritmien ominaisuus on, että yhdellä avaimella salatut tiedot voidaan purkaa vain toisella avaimella. Digitaalinen allekirjoitus muodostetaan seuraavasti. Tiedoille lasketaan tarkistussumma (hash-koodi), joka on salattu digitaalisen allekirjoituksen omistajan yksityisellä avaimella. Tämä on digitaalinen allekirjoitus, se lisätään tietoihin. Tietoihin voidaan myös lisätä julkinen avain. Julkisen avaimen avulla kuka tahansa käyttäjä voi purkaa digitaalisen allekirjoituksen salauksen ja saada tarkistussumman, jota voidaan verrata tarkistussumma lasketaan nykyisten tietojen perusteella ja näin saadaan selville, ovatko tiedot muuttuneet.
Siinä tapauksessa, että meidän ei tarvitse vain varmistaa tietojen muuttumattomuutta, vaan myös piilottaa niiden sisältö ulkopuolisilta, käytetään salausta. Yleensä dataa siirrettäessä käytetään istuntoavainmallia, jonka mekanismia en käsittele, koska se tarjotaan yleensä infrastruktuuritasolla. Joten digitaalinen allekirjoitus ja salaus ovat tärkeimmät mekanismit siirrettävien tietojen suojaamiseksi. Voimme käyttää näitä mekanismeja siirtoprotokollatasolla tai SOAP-sanomatasolla. Jokaisella menetelmällä on omat etunsa ja haittansa.
Tietosuojan varmistamiseksi siirtoprotokollatasolla käytetään yleensä vakiintunutta SSL-mekanismia. Tässä tapauksessa asiakkaan ja palvelimen välille muodostetaan suojattu yhteys, jossa kaikki liikenne on salattu. Tämän lähestymistavan etuna on, että se ei vaadi lähes mitään lisäponnistuksia kehittäjältä (lukuun ottamatta mahdollisesti joitakin yhteyden muodostamisen erityispiirteitä). Pääasiallinen suojatun SSL-yhteyden määrittäminen tehdään, kun sovellus otetaan käyttöön. Tämän lähestymistavan haittoja ovat se, että kaikki liikenne on salattua, ei vain todella luottamuksellisia tietoja, ja tämä vaatii paljon laskentaresursseja. Kuvaus SSL:n käytöstä ASP.NET 1.1 -verkkopalveluiden kanssa löytyy artikkelistani osoitteessa http://stump-workshop.blogspot.com/2006/10/web-https-ssl.html
Tietosuojamekanismit SOAP-viestitasolla perustuvat SOAP-protokollalaajennuksiin, kuten WS-SecureConversation, WS-Trust, WS-SecurityPolicy ja WS-Security. Yleensä tuki näille määrityksille on sisäänrakennettu verkkopalveluita toteuttavalle alustatasolle, ja ne ovat kehittäjän saatavilla sekä deklaratiivisella tasolla (attribuutit tai konfiguraatio) että API:n muodossa. Näiden mekanismien käytön etuja ovat niiden joustavuus ja monipuolisuus. Voit käyttää sekä salausta että digitaalista allekirjoitusta. On mahdollista suojata vain yksittäisten palvelutoimintojen viestit ja jopa yksittäiset SOAP-sanoman osat. Valitettavasti kaikki verkkopalvelualustat eivät tue näitä määrityksiä täysin. Esimerkiksi laajalle levinnyt .NET Framework 1.1 ei tue WS-Securityä. Siksi, kun käytät tätä alustaa, sinun on toteutettava suojaus kuljetustasolla.
Lopuksi on kolmas tapa - toteuttaa oma suojamekanismisi esimerkiksi kuvatulla tavalla. On kuitenkin ymmärrettävä, että tällainen polku vähentää huomattavasti mahdollisuuksiasi käyttää palveluasi.
Yhteenvetona voidaan todeta, että kannattaa pohtia sellaista asiaa kuin valtuustietojen tallentaminen verkkopalveluihin yhdistämistä varten. Olemme jo sanoneet, että pääsy verkkopalveluihin tulisi tarjota vain todennetuille käyttäjille. Kolikon toinen puoli on, että meidän on määritettävä valtuustiedot (credentials), kun asiakas muodostaa yhteyden palveluun. Siksi meidän on tallennettava nämä identiteetit jonnekin. Kun järjestelmämme on vuorovaikutuksessa useiden palvelujen kanssa, joista jokainen vaatii oman identiteettinsä, ongelma tulee erityisen akuuttiksi.
Mitä ovat valtuustiedot. Useimmissa tapauksissa tämä on kirjautumissalasana-arvopari. Joskus tämä voi olla asiakassertifikaatti tai muun tyyppinen valtuustieto riippuen käytetystä todennusprotokollasta. On ymmärrettävä selvästi, että asiakasidentiteetit viittaavat tietoihin, joita hyökkääjä voi käyttää hyökkäämään järjestelmään. Siksi nämä tiedot vaativat suojaa. Sinun tulee ottaa tämä huomioon suunnitteluvaiheessa. Integraatioverkkopalveluita toteutettaessa joudut todennäköisesti käyttämään jonkin verran vaivaa kehittäessäsi mekanismeja asiakasidentiteetin turvalliseen tallentamiseen ja niiden konfigurointiin/muokkaukseen.

Toteutusongelmat

Verkkopalvelujen käyttöönottoon liittyvät ongelmat riippuvat suuresti käyttämästäsi alustasta, ja niitä on nykyään paljon. Vain Microsoft tarjoaa 4 alustaa (ASP.NET 1.1, ASP.NET 2.0, WSE 1.0-3.0, WCF-Indigo). Java-maailmassa on vielä enemmän. Siksi on erittäin vaikea antaa erityisiä suosituksia. On kuitenkin kohtia, joihin sinun tulee kiinnittää huomiota joka tapauksessa.
Useimmat alustat huolehtivat palvelun WSDL-kuvauksen muodostamisesta, mikä antaa kehittäjälle mahdollisuuden työskennellä palvelun kanssa kuten normaalin luokan kanssa. Siksi sinun tulee kiinnittää jatkuvasti huomiota niihin yksityiskohtiin, jotka vaikuttavat oikean WSDL-kuvauksen ja XSD-dataskeemojen muodostumiseen. Näitä asioita ovat mm. Xml-nimiavaruuksien ja -etuliitteiden käyttö, tietojen sarjoitusjärjestyksen hallinta sekä WSDL-luonnon järjestys ja tyyli.
Sinun tulisi yrittää erottaa liiketoimintalogiikka palvelun toteutuksesta. No, jos onnistut käyttämään yhtä liiketoimintalogiikkaa sovelluksen sisällä ja verkkopalvelussa. Ihannetapauksessa verkkopalvelumenetelmistäsi puuttuu muuta logiikkaa kuin parametrien validointi, tulosten luominen ja virheiden käsittely, kuten kuvassa näkyy:

Johtopäätös

Joten tässä artikkelissa olemme pohtineet useita integraatioverkkopalveluiden suunnitteluun liittyviä kysymyksiä.
Päädyimme SOA-konseptin yleisiin periaatteisiin. Pohdittiin palvelusopimuksen suunnittelun käytännön kysymyksiä, varmistaen sen toiminnallinen ja syntaktinen täydellisyys. Kiinnitimme huomiota vuorovaikutusprotokollan vaikutukseen palvelusopimukseen. Harkitaan vaihtoehtoja verkkopalveluiden tietoturvaongelmien ratkaisemiseksi. Ja lopuksi päädyimme joihinkin käytännön suunnitteluun. Toivon, että tästä artikkelista on sinulle hyötyä, kun suunnittelet integrointiverkkopalveluita.

Avoimen lähdekoodin ohjelmistoista on tullut valtavirtaa rakenteellinen elementti kun rakennat suurimpia verkkosivustoja. Kun nämä sivustot ovat kasvaneet, niiden arkkitehtuurille on syntynyt parhaita käytäntöjä ja ohjeita. Tämän luvun tarkoituksena on kattaa joitakin keskeisiä kysymyksiä, jotka on otettava huomioon suunnitellessa suuria verkkosivustoja, sekä joitakin näiden tavoitteiden saavuttamiseen käytettyjä peruskomponentteja.

Tämän luvun painopiste on verkkojärjestelmien analyysissä, vaikka osa materiaalista voidaan ekstrapoloida muihin hajautetuihin järjestelmiin.

1.1 Hajautettujen verkkojärjestelmien rakentamisen periaatteet

Mitä tarkalleen ottaen tarkoittaa skaalautuvan verkkosivuston tai sovelluksen luominen ja hallinta? Alkeellisella tasolla tämä on yksinkertaisesti käyttäjien yhteys etäresursseihin Internetin kautta. Ja resurssit tai pääsy näihin resursseihin, jotka ovat hajallaan useilla palvelimilla ja ovat linkki, joka varmistaa verkkosivuston skaalautuvuuden.

Kuten useimmat asiat elämässä, verkkopalvelun rakentamisen suunnittelu voi viedä pitkälle. joidenkin suurten verkkosivustojen taustalla olevien näkökohtien ja kompromissien ymmärtäminen voi maksaa itsensä järkevämpien päätösten muodossa pienempiä verkkosivustoja rakennettaessa. Alla on joitain keskeisiä periaatteita, jotka ohjaavat suurten verkkojärjestelmien suunnittelua:

Saatavuus: verkkosivuston käytettävyys on kriittinen monien yritysten maineen ja toiminnallisuuden kannalta. Joillekin suurille verkkokaupoille, jos ne eivät ole käytettävissä edes muutaman minuutin ajan, seurauksena voi olla tuhansien tai miljoonien dollarien tulojen menetys. Jatkuvasti saatavilla olevien ja vikasietoisten järjestelmien kehittäminen on siis sekä liiketoiminnan että teknologian perusvaatimus. Korkea käytettävyys hajautetuissa järjestelmissä edellyttää redundanssin huolellista harkintaa keskeiset komponentit, nopea toipuminen osittaisista järjestelmävioista ja kapasiteetin tasainen vähentäminen ongelmien ilmetessä.
Esitys: Verkkosivuston suorituskyky on tullut tärkeä indikaattori useimmille sivustoille. Verkkosivuston nopeus vaikuttaa käyttäjäkokemukseen ja tyytyväisyyteen sekä hakukonesijoituksiin – tekijä, joka vaikuttaa suoraan yleisön pysyvyyteen ja tuloihin. Tämän seurauksena avain on luoda järjestelmä, joka on optimoitu nopeille vasteille ja alhaiselle latenssille.
Luotettavuus: järjestelmän on oltava kestävä, jotta tietty tietopyyntö palauttaa jatkuvasti tiettyjä tietoja. Jos data muuttuu tai päivitetään, saman kyselyn on palautettava uusia tietoja. Käyttäjien on tiedettävä, että jos jotain kirjoitetaan tai tallennetaan järjestelmään, voit olla varma, että se pysyy paikallaan, jotta tiedot voidaan hakea myöhemmin.
Skaalautuvuus: Mitä tahansa suuria hajautettuja järjestelmiä, koko on vain yksi huomioitava kohde luettelossa. Yhtä tärkeitä ovat pyrkimykset lisätä kaistanleveys käsitellä suuria määriä työtaakkaa, jota yleensä kutsutaan järjestelmän skaalautuvuudeksi. Skaalautuvuus voi viitata erilaisia parametreja järjestelmät: kuinka paljon ylimääräistä liikennettä se pystyy käsittelemään, kuinka helppoa tallennuskapasiteettia on laajentaa tai kuinka paljon muita tapahtumia voidaan käsitellä.
Ohjattavuus: helppokäyttöisen järjestelmän suunnittelu on toinen tärkeä tekijä. Järjestelmän hallittavuus rinnastetaan "ylläpito"- ja "päivitys"-toimintojen skaalautumiseen. Hallittavuuden varmistamiseksi on otettava huomioon esiin tulevien ongelmien diagnosoinnin ja ymmärtämisen helppous, päivityksen tai muuntamisen helppous, käytössä olevan järjestelmän omituisuus. ( Eli toimiiko se odotetusti ilman vikoja tai poikkeuksia?)
Hinta: Kustannukset ovat tärkeä tekijä. Tämä voi tietysti sisältää laitteisto- ja ohjelmistokustannuksia, mutta on myös tärkeää ottaa huomioon muut järjestelmän käyttöönoton ja ylläpidon edellyttämät näkökohdat. On otettava huomioon kehittäjälle järjestelmän rakentamiseen tarvittava aika, järjestelmän käyttöönottoon tarvittava operatiivisen vaivan määrä ja jopa riittävä koulutustaso. Kustannukset edustavat omistamisen kokonaiskustannuksia.

Jokainen näistä periaatteista on perusta päätöksenteolle hajautetun verkkoarkkitehtuurin suunnittelussa. Ne voivat kuitenkin olla myös ristiriidassa keskenään, koska yhden tavoitteiden saavuttaminen tapahtuu muiden laiminlyönnin kustannuksella. Yksinkertainen esimerkki: useiden palvelimien lisääminen suorituskyvyn (skaalautuvuus) ratkaisuksi voi lisätä hallittavuuden (sinun on käytettävä ylimääräistä palvelinta) ja palvelimien ostamisen kustannuksia.

Kaikenlaista verkkosovellusta kehitettäessä on tärkeää ottaa nämä keskeiset periaatteet huomioon, vaikka se olisi varmistua siitä, että projekti saattaa uhrata yhden tai useamman niistä.

1.2 Perustiedot

Kun harkitaan järjestelmäarkkitehtuuria, on käsiteltävä useita kysymyksiä, kuten mitä komponentteja käytetään, miten ne sopivat yhteen ja mitä kompromisseja voidaan tehdä. Skaalaamiseen sijoittaminen ilman selvää tarvetta ei ole fiksu liiketoimintapäätös. Suunnittelun ennakointi voi kuitenkin säästää paljon aikaa ja resursseja tulevaisuudessa.

Tämä osio keskittyy joihinkin perustekijöihin, jotka ovat välttämättömiä melkein kaikille suurille verkkosovelluksille: Palvelut,
redundanssi, segmentointi, Ja vikojen käsittely. Jokainen näistä tekijöistä sisältää valintoja ja kompromisseja, erityisesti edellisessä osiossa kuvattujen periaatteiden yhteydessä. Selvyyden vuoksi otetaan esimerkki.

Esimerkki: Kuvanhallintasovellus

Olet todennäköisesti julkaissut kuvia verkossa aiemmin. Suurille sivustoille, jotka tallentavat ja toimittavat useita kuvia, on haasteita luoda kustannustehokas, erittäin luotettava arkkitehtuuri, jolle on ominaista alhaiset vasteviiveet (nopea haku).

Kuvittele järjestelmä, jossa käyttäjät voivat ladata kuvansa keskuspalvelimelle ja kuvia voidaan pyytää verkkosivustolinkin tai API:n kautta, kuten Flickr tai Picasa. Kuvauksen yksinkertaistamiseksi oletetaan, että tällä sovelluksella on kaksi päätehtävää: kyky ladata (kirjoittaa) kuvia palvelimelle ja pyytää kuvia. Tehokas lataus on tietysti tärkeä kriteeri, mutta etusijalla on nopea toimitus käyttäjien pyynnöstä (esimerkiksi kuvia voidaan pyytää näytettäväksi verkkosivulla tai muussa sovelluksessa). Tämä toiminto on samanlainen kuin mitä web-palvelin tai CDN (Content Delivery Network) reunapalvelin voi tarjota. CDN-palvelin tallentaa tyypillisesti tietoobjekteja useisiin paikkoihin, joten niiden maantieteellinen/fyysinen sijainti on lähempänä käyttäjiä, mikä parantaa suorituskykyä.

muu tärkeitä näkökohtia järjestelmät:

Tallennettujen kuvien määrä voi olla rajoittamaton, joten tallennustilan skaalautuvuus on otettava huomioon tästä näkökulmasta.
Kuvien latausten/pyyntöjen viiveen pitäisi olla alhainen.
Jos käyttäjä lataa kuvan palvelimelle, hänen tietojensa on säilyttävä aina ehjinä ja saatavilla.
Järjestelmän tulee olla helppo ylläpitää (hallinta).
Koska kuvan isännöinti ei ole kovin kannattavaa, järjestelmän on oltava kustannustehokas.

Toinen tämän suunnittelun mahdollinen ongelma on, että verkkopalvelimella, kuten Apache tai lighttpd, on yleensä yläraja samanaikaiset yhteydet että se pystyy palvelemaan (oletusarvo on noin 500, mutta se voi olla paljon suurempi), ja suurella liikenteellä kirjoittaminen voi nopeasti käyttää tämän rajan. Koska lukeminen voi olla asynkronista tai hyödyntää muita suorituskyvyn optimointeja, kuten gzip-pakkausta tai ryhmittelyä, verkkopalvelin voi vaihtaa syötteen lukuja nopeammin ja vaihtaa asiakkaiden välillä palvellen paljon enemmän pyyntöjä kuin suurin sallittu määrä yhteyksiä (Apachella ja enimmäismäärällä yhteyksien arvoksi asetettu 500, on täysin mahdollista palvella useita tuhansia lukupyyntöjä sekunnissa). Kirjoitukset sen sijaan pitävät yhteyden auki koko latauksen ajan. Joten 1 Mt:n tiedoston siirtäminen palvelimelle voi kestää yli 1 sekunnin useimmissa kotiverkoissa, jolloin verkkopalvelin pystyy käsittelemään vain 500 yhtäaikaista kirjoitusta.

Kuva 1.2: Lukemisen ja kirjoittamisen erottaminen

Tällaisen mahdollisen ongelman ennakointi viittaa tarpeeseen erottaa luku- ja kirjoituskuvat itsenäisiksi palveluiksi, kuten kuvassa . Näin voimme paitsi skaalata jokaista niistä erikseen (koska on todennäköistä, että luemme aina enemmän kuin kirjoitamme), vaan myös olla tietoisia siitä, mitä kussakin palvelussa tapahtuu. Lopuksi se linjaa ongelmia, joita saattaa ilmetä tulevaisuudessa, mikä helpottaa hitaan lukukäytön ongelman diagnosointia ja arviointia.

Tämän lähestymistavan etuna on, että pystymme ratkaisemaan ongelmia toisistaan riippumatta - ilman, että meidän tarvitsee ajatella tarvetta kirjoittaa ja hakea uusia kuvia samassa yhteydessä. Molemmat palvelut käyttävät edelleen globaalia kuvakorpusta, mutta palvelukohtaisilla menetelmillä ne pystyvät optimoimaan omaa suorituskykyään (esim. jonottamalla pyyntöjä tai tallentamalla suosittuja kuvia välimuistiin - siitä lisää myöhemmin). Sekä ylläpidon että kustannusten osalta jokainen palvelu voidaan skaalata itsenäisesti tarpeen mukaan. Ja tämä on myönteinen tekijä, koska niiden yhdistäminen ja sekoittaminen voi vahingossa vaikuttaa niiden suorituskykyyn, kuten yllä kuvatussa skenaariossa.

Tietenkin yllä olevan mallin toiminta on optimaalista, jos siinä on kaksi erilaista päätepistettä (itse asiassa tämä on hyvin samanlainen kuin useat pilvitallennuspalvelujen tarjoajien ja sisällönjakeluverkkojen toteutukset). On monia tapoja ratkaista vastaavia ongelmia, ja jokaisessa tapauksessa voidaan löytää kompromissi.

Esimerkiksi Flickr ratkaisee tämän luku-kirjoitus-ongelman jakamalla käyttäjät eri moduuleille niin, että jokainen moduuli voi toimia vain rajoitettu määrä määritetyt käyttäjät, ja käyttäjien määrän kasvaessa klusteriin lisätään enemmän moduuleja (katso Flickr-zoom-esitys,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). Ensimmäisessä esimerkissä on helpompi skaalata laitteistoa todellisen käyttökuormituksen perusteella (lukujen ja kirjoitusten määrä koko järjestelmässä), kun taas Flickr skaalaa käyttäjäkunnan perusteella (se käyttää kuitenkin oletusta yhtenäisestä käytöstä eri käyttäjille, joten kapasiteetti on suunniteltava varauksella). Aiemmin jonkin palvelun epäkäytettävyys tai ongelma on poistanut koko järjestelmän toiminnallisuuden (esimerkiksi kukaan ei voi kirjoittaa tiedostoja), jolloin jonkin Flickr-moduulin epäkäytettävyys vaikuttaa vain siihen liittyviin käyttäjiin. Ensimmäisessä esimerkissä on helpompi suorittaa toimintoja koko tietojoukolle - esimerkiksi päivittää postipalvelu sisältämään uudet metatiedot tai hakea kaikista kuvan metatiedoista - kun taas Flickrin arkkitehtuurissa jokainen moduuli piti päivittää tai etsiä ( tai hakupalvelu oli luotava lajittelemaan tähän tarkoitukseen tarkoitettu metadata).

Näille järjestelmille ei ole ihmelääkettä, vaan tulee aina edetä tämän luvun alussa kuvatuista periaatteista: määritellä järjestelmän tarpeet (lataus "lue" tai "kirjoita" operaatioilla tai kaikki kerralla, rinnakkaisuuden taso , kyselyt tietojoukoista, alueista, triageista jne.), vertailla eri vaihtoehtoja toisiinsa, ymmärtää mahdolliset järjestelmävikaolosuhteet ja laatia kattava suunnitelma vian varalta.

Redundanssi

Jotta verkkoarkkitehtuuri voi käsitellä virheitä sulavasti, sen palveluissa ja tiedoissa on oltava redundanssi. Jos esimerkiksi yhdelle palvelimelle on tallennettu vain yksi kopio tiedostosta, kyseisen palvelimen katoaminen merkitsisi tiedoston katoamista. On epätodennäköistä, että tällaista tilannetta voidaan luonnehtia positiivisesti, ja se voidaan yleensä välttää tekemällä useita kopioita tai varmuuskopioita.

Sama periaate koskee palveluita. Yksittäisen solmun epäonnistumiselta voidaan suojautua tarjoamalla sovellukselle kiinteä toiminto, joka varmistaa, että sen useita kopioita tai versioita ovat käynnissä samanaikaisesti.

Luomalla redundanssia järjestelmässä voit päästä eroon heikkouksista ja tarjota varmuuskopioita tai redundantteja toimintoja hätätilanteessa. Esimerkiksi, jos tuotannossa on käynnissä kaksi saman palvelun esiintymää ja toinen niistä epäonnistuu kokonaan tai osittain, järjestelmä voi voittaa vian vaihtaa toimivaan esiintymään.
Vaihto voi olla automaattinen tai vaatia manuaalista puuttumista.

Toinen palveluiden redundanssin keskeinen rooli on luoda resurssienjakoarkkitehtuuri. Tämän arkkitehtuurin avulla jokainen solmu pystyy toimimaan itsenäisesti ja lisäksi keskusten "aivojen" puuttuessa hallitsemaan tiloja tai koordinoimaan muiden solmujen toimintaa. Se edistää skaalautuvuutta, koska uusien solmujen lisääminen ei vaadi erityisiä ehtoja tai tietoa. Ja mikä tärkeintä, näissä järjestelmissä ei ole kriittistä vikakohtaa, mikä tekee niistä paljon kestävämpiä vikaa vastaan.

Esimerkiksi kuvapalvelinsovelluksessamme kaikilla kuvilla olisi ylimääräiset kopiot jossain eri laitteistossa (mieluiten eri maantieteellisessä sijainnissa katastrofin, kuten maanjäristyksen tai datakeskuksen tulipalon, sattuessa), ja kuvien käyttöpalvelut olisivat tarpeeton, koska ne kaikki voisivat palvella pyyntöjä. (cm..)
Tulevaisuudessa kuormituksen tasaajat ovat loistava tapa tehdä tämä mahdolliseksi, mutta siitä lisää alla.

Kuva 1.3: Kuvan isännöintisovellus redundanssilla

Segmentointi

Tietojoukot voivat olla niin suuria, että niitä ei voi isännöidä yhdellä palvelimella. Voi myös käydä niin, että laskennalliset toiminnot vaativat liikaa tietokoneresursseja, mikä heikentää suorituskykyä ja tekee tarpeelliseksi lisätä tehoa. Joka tapauksessa sinulla on kaksi vaihtoehtoa: pysty- tai vaakasuora skaalaus.

Pystysuuntainen skaalaus tarkoittaa resurssien lisäämistä yhdelle palvelimelle. Joten erittäin suurelle tietojoukolle tämä tarkoittaisi lisää (tai enemmän) Kovalevyt, jolloin koko tietojoukko voitaisiin isännöidä yhdellä palvelimella. Laskentaoperaatioiden tapauksessa tämä tarkoittaisi laskennan siirtämistä suurempaan palvelimeen, jossa on nopeampi prosessori tai enemmän muistia. Joka tapauksessa vertikaalinen skaalaus suoritetaan, jotta yksi tietokonejärjestelmän resurssi pystyy siihen lisäkäsittely tiedot.

Horisontaalinen skaalaus sen sijaan sisältää lisää solmuja. Suuren tietojoukon tapauksessa tämä tarkoittaisi toisen palvelimen lisäämistä tallentamaan osan kokonaistiedoista, ja laskentaresurssille tämä tarkoittaisi työn tai kuorman jakamista joidenkin lisäsolmujen kautta. Jotta horisontaalisen skaalauksen potentiaalista saataisiin täysi hyöty, se on toteutettava muodossa sisäinen periaate järjestelmäarkkitehtuurin kehittäminen. Muuten vaakaskaalauksen edellyttämän kontekstin muuttaminen ja korostaminen voi olla ongelmallista.

Yleisin skaalaustapa on segmentoida palvelut sirpaleiksi tai paloiksi. Ne voidaan jakaa siten, että jokainen looginen toimintosarja toimii erikseen. Tämä voidaan tehdä maantieteellisten rajojen tai muiden kriteerien, kuten maksavien ja ei-maksavien käyttäjien, perusteella. Näiden järjestelmien etuna on, että ne tarjoavat palvelun tai tietovaraston parannetulla toiminnallisuudella.

Kuvapalvelinesimerkissämme on mahdollista, että kuvan tallentamiseen käytetty yksittäinen tiedostopalvelin voidaan korvata useilla tiedostopalvelimilla, joista jokainen sisältää oman ainutlaatuinen setti kuvia. (Katso .) Tämän arkkitehtuurin avulla järjestelmä voi täyttää jokaisen tiedostopalvelimen kuvilla ja lisää palvelimia levytilan täyttyessä. Suunnittelu vaatii nimeämismallin, joka yhdistää kuvatiedostonimen sen sisältävään palvelimeen. Kuvan nimi voidaan muodostaa palvelimiin liittyvästä johdonmukaisesta hajautusjärjestelmästä. Tai vaihtoehtoisesti jokaisella kuvalla voisi olla inkrementaalinen tunnus, jonka avulla toimituspalvelu pystyisi kuvaa pyytäessä käsittelemään vain kuhunkin palvelimeen liittyvän ID-alueen (indeksinä).

Kuva 1.4: Kuvan isännöintisovellus redundanssilla ja segmentoinnilla

Tietenkin on vaikeuksia jakaa tietoja tai toimintoja useiden palvelimien kesken. Yksi avainkysymyksistä on tietojen sijainti; hajautetuissa järjestelmissä, mitä lähempänä data on toiminta- tai laskentapistettä, sitä parempi on järjestelmän suorituskyky. Tästä johtuen tietojen jakaminen useille palvelimille voi olla ongelmallista, koska aina kun tietoja saatetaan tarvita, on olemassa riski, että niitä ei ehkä ole saatavilla pyydettäessä, palvelimen on suoritettava tarvittavien tietojen kallis nouto. verkko.

Toinen mahdollinen ongelma ilmenee muodossa
epäjohdonmukaisuudet (epäjohdonmukaisuudet).Kun eri palvelut lukevat ja kirjoittavat jaettuun resurssiin, mahdollisesti toiseen palveluun tai tietovarastoon, on olemassa "kilpaehtojen" mahdollisuus - joissa jotkin tiedot katsotaan päivitetyksi nykyiseen tilaan, mutta todellisuudessa ne luetaan ennen todellista aikaa - jolloin tiedot ovat epäjohdonmukaisia. Esimerkiksi kuvien isännöintiskenaariossa voi esiintyä kilpailutilanne, jos yksi asiakas lähettää koirakuvan päivittämispyynnön, jonka otsikko "Koira" on muutettu muotoon "Gizmo", kun toinen asiakas luki kuvaa. Tällaisessa tilanteessa ei ole selvää, minkä nimikkeen, "Koira" vai "Gizmo", toinen asiakas olisi saanut.

Tietenkin tietojen jakamiseen liittyy esteitä, mutta jakamisen avulla jokainen ongelma voidaan erottaa muista: tietojen, kuormituksen, käyttötapojen ja niin edelleen. hallittaviin lohkoihin. Tämä voi auttaa lisäämään skaalautuvuutta ja hallittavuutta, mutta riski on silti olemassa. On monia tapoja vähentää riskejä ja käsitellä epäonnistumisia; lyhyyden vuoksi niitä ei kuitenkaan käsitellä tässä luvussa. Jos haluat lisätietoja tästä aiheesta, sinun kannattaa katsoa vikasieto- ja valvontablogiviesti.

1.3. Nopean ja skaalautuvan tiedonsaannin rakenteelliset komponentit

Kun on käsitelty joitakin hajautettujen järjestelmien kehittämisen perusperiaatteita, siirrytään nyt vaikeampaan kohtaan - tietojen käytön skaalaamiseen.

Yksinkertaisimmat verkkosovellukset, kuten LAMP-pinosovellukset, ovat samanlaisia kuin kuvassa .

Kuva 1.5: Yksinkertaiset verkkosovellukset

Sovelluksen kasvaessa syntyy kaksi suurta haastetta: sovelluspalvelimen ja tietokantaan pääsyn skaalaus. Erittäin skaalautuvassa sovellussuunnittelussa verkkopalvelin tai sovelluspalvelin on yleensä minimoitu ja toteuttaa usein ei-jakamisen arkkitehtuurin. Tämä tekee järjestelmän sovelluspalvelinkerroksesta vaakasuunnassa skaalautuvan. Tämän mallin käytön seurauksena kova työ siirtyy alaspäin tietokantapalvelimeen ja tukipalveluihin; tässä tulevat esiin todelliset skaalaus- ja suorituskykyongelmat.

Tämän luvun loppuosassa keskitytään joihinkin yleisimpiin strategioihin ja tekniikoihin tällaisten palvelujen suorituskyvyn ja skaalautuvuuden parantamiseksi tarjoamalla nopean tiedonsaannin.

Kuva 1.6: Yksinkertaistettu verkkosovellus

Useimmat järjestelmät voidaan yksinkertaistaa kaavioiksi,
mikä on hyvä lähtökohta pohtimisen aloittamiselle. Jos sinulla on paljon dataa, voidaan olettaa, että haluat käyttää niitä yhtä helposti ja nopea pääsy kuin laatikko tikkuja ylimmässä laatikossasi. Vaikka tämä vertailu on liian yksinkertaistettu, se viittaa kahteen vaikeaan ongelmaan: tietovaraston skaalautuvuus ja nopea tiedon saatavuus.

Tässä osiossa oletetaan, että sinulla on useita teratavuja (TB) tietoa ja annat käyttäjien käyttää pieniä osia tiedosta satunnaisesti. (cm..)
Tähän liittyvä tehtävä on paikantaa kuvatiedosto jostain tiedostopalvelimelta esimerkkikuvan isännöintisovelluksessa.

Kuva 1.7: Pääsy tiettyihin tietoihin

Tämä on erityisen vaikeaa, koska teratavujen datan lataaminen muistiin voi olla erittäin kallista ja vaikuttaa suoraan levyn I/O-määrään. Levyltä lukemisen nopeus on useita kertoja pienempi kuin lukemisen nopeus RAM-muisti- Voit sanoa, että muistin käyttö on yhtä nopeaa kuin Chuck Norris, kun taas levyn käyttö on hitaampaa kuin klinikan linja. Tämä nopeusero on erityisen havaittavissa suurilla tietojoukoilla; kuivina lukuina, muistin käyttö on 6 kertaa nopeampi kuin levyn lukeminen peräkkäisissä lukemissa ja 100 000 kertaa nopeampi lukemisessa satunnainen järjestys(Katso The Patologies of Big Data, http://queue.acm.org/detail.cfm?id=1563874). Lisäksi jopa yksilöllisillä tunnisteilla pienen tiedon paikantaminen voi olla yhtä vaikeaa ratkaista kuin yrittää vetää viimeinen karamelli sadan muun karkin laatikosta katsomatta.

Onneksi asioiden yksinkertaistamiseksi on monia lähestymistapoja, joista neljä tärkeintä lähestymistapaa ovat välimuistien, välityspalvelinten, indeksien ja kuormituksen tasapainottajien käyttö. Tämän osan loppuosassa käsitellään sitä, kuinka kutakin näistä käsitteistä voidaan käyttää tiedon saamiseksi paljon nopeammin.

Välimuistit

Välimuistiin tallentaminen hyötyy perusperiaatteen ominaisuudesta, jonka mukaan äskettäin pyydettyjä tietoja tarvitaan todennäköisesti uudelleen. Välimuistia käytetään lähes kaikilla tietojenkäsittelyn tasoilla: laitteistoissa, käyttöjärjestelmissä, verkkoselaimissa, verkkosovelluksissa ja muissa. Välimuisti on kuin lyhytkestoinen muisti: Rajoitettu laajuus, mutta nopeampi kuin alkuperäinen tietolähde ja sisältää äskettäin avattuja kohteita. Välimuistit voivat olla arkkitehtuurin kaikilla tasoilla, mutta ne ovat usein käyttöliittymää lähimmällä tasolla, missä ne on toteutettu palauttamaan tiedot nopeasti ilman merkittävää taustakuormitusta.

Joten kuinka välimuistia voidaan käyttää nopeuttamaan tietojen käyttöä esimerkkisovellusliittymässämme? Tässä tapauksessa sopivia välimuistipaikkoja on useita. Yhtenä mahdollisista sijoitteluvaihtoehdoista voit valita solmuja kyselytasolla kuvan osoittamalla tavalla
.

Kuva 1.8: Välimuistin sijoittaminen pyyntötason solmuun

Välimuistin sijoittaminen suoraan pyyntökerroksen solmuun mahdollistaa vastaustietojen paikallisen tallennuksen. Aina kun palvelulle tehdään pyyntö, isäntä palauttaa nopeasti paikallisia välimuistiin tallennettuja tietoja, jos sellaisia on. Jos se ei ole välimuistissa, pyyntöisäntä pyytää tietoja levyltä. Yhden pyyntötason solmun välimuisti voi myös sijaita sekä muistissa (joka on erittäin nopea) että paikallinen levy isäntä (nopeampi kuin yrittää käyttää verkkotallennustilaa).

Kuva 1.9: Välimuistijärjestelmät

Mitä tapahtuu, kun hajaat välimuistin useisiin solmuihin? Kuten näet, jos pyyntökerros sisältää useita solmuja, on todennäköistä, että jokaisella solmulla on oma välimuisti. Jos kuormituksen tasapainotin kuitenkin jakaa pyynnöt satunnaisesti solmujen kesken, sama pyyntö siirtyy eri solmuihin, mikä lisää välimuistin menetyksiä. Kaksi tapaa voittaa tämä este ovat globaalit ja hajautetut välimuistit.

Globaali välimuisti

Globaalin välimuistin merkitys käy selväksi nimestä: kaikki solmut käyttävät samaa yksittäistä välimuistitilaa. Tässä tapauksessa lisätään jonkinlainen palvelin tai tiedostovarasto, joka on nopeampi kuin alkuperäinen varastosi ja joka on kaikkien pyyntötason solmujen käytettävissä. Jokainen pyyntösolmu pyytää välimuistia samalla tavalla kuin jos se olisi paikallinen. Tällainen välimuistimalli voi aiheuttaa ongelmia, koska yksittäinen välimuisti on erittäin helppo ylikuormittaa, jos asiakkaiden ja pyyntöjen määrä kasvaa. Samanaikaisesti tällainen järjestelmä on erittäin tehokas tietyissä arkkitehtuureissa (erityisesti sellaisissa, jotka liittyvät erikoislaitteistoihin, jotka tekevät tästä globaalista välimuistista erittäin nopean tai joissa on kiinteä joukko tietoja, jotka on tallennettava välimuistiin).

Kaavioissa on kaksi yleisten välimuistien vakiomuotoa. Tilanne on kuvattu, kun välimuistissa olevaa vastausta ei löydy välimuistista, välimuisti vastaa itse puuttuvan datan saamisesta taustalla olevasta varastosta. Se havainnollistaa pyyntösolmujen velvollisuutta hakea kaikki tiedot, joita ei löydy välimuistista.

Kuva 1.10: Yleinen välimuisti, jossa välimuisti vastaa noutamisesta

Kuva 1.11: Globaali välimuisti, jossa kyselysolmut ovat vastuussa hausta

Useimmat globaaleja välimuistia hyödyntävät sovellukset käyttävät yleensä ensimmäistä tyyppiä, jossa välimuisti itse hallinnoi korvaamista ja tietojen noutoa estääkseen asiakkaita täyttämästä samoja tietoja koskevia pyyntöjä. Joissakin tapauksissa toinen toteutus on kuitenkin järkevämpää. Jos välimuistia käytetään esimerkiksi erittäin suurille tiedostoille, alhainen korko onnistunut välimuistiosuma aiheuttaa puskurin välimuistin ylikuormituksen epäonnistuneilla välimuistiosumilla; tässä tilanteessa se auttaa suuri prosentti jaettu tietojoukko (tai kuuma tietojoukko) välimuistissa. Toinen esimerkki on arkkitehtuuri, jossa välimuistissa olevat tiedostot ovat staattisia eikä niitä pidä poistaa. (Tämä saattaa johtua tällaisen datan latenssin taustalla olevista suorituskykyominaisuuksista - ehkä joidenkin tietojen osien on oltava erittäin nopeita suuria tietojoukkoja varten - jolloin sovelluslogiikka ymmärtää korvausstrategian tai hotspotit paremmin kuin välimuisti.)

Hajautettu välimuisti

Nämä indeksit tallennetaan usein muistiin tai jonnekin hyvin paikalliseen asiakkaan saapuvan pyynnön mukaan. Berkeley DB (BDB) ja puutietorakenteet, joita käytetään yleisesti tietojen tallentamiseen järjestetyissä luetteloissa, ovat ihanteellisia indeksoituun käyttöön.

Usein on useita indeksitasoja, jotka toimivat karttana ja vievät sinut paikasta toiseen ja niin edelleen, kunnes saat tarvitsemasi tiedon. (cm.)

Kuva 1.17: Monitasoiset indeksit

Indeksejä voidaan käyttää myös useiden muiden näkymien luomiseen samoista tiedoista. Suurille tietojoukoille tämä on loistava tapa määrittää erilaisia suodattimia ja näkymiä ilman, että tiedoista tarvitsee tehdä monia lisäkopioita.

Oletetaan esimerkiksi, että yllä mainittu kuvanhallintajärjestelmä todella isännöi kuvia kirjan sivut, ja palvelu mahdollistaa asiakaspuolen kyselyt näissä kuvissa olevasta tekstistä ja etsivät kaikkea tiettyä aihetta koskevaa tekstisisältöä, aivan kuten hakukoneet mahdollistavat HTML-sisällön etsimisen. Tässä tapauksessa kaikki nämä kirjakuvat käyttävät niin monia palvelimia tiedostojen tallentamiseen, ja yhden sivun löytäminen käyttäjälle esitettäväksi voi olla melko vaikeaa. Aluksi käänteisten indeksien pitäisi olla helposti saatavilla mielivaltaisten sanojen ja sanajoukkojen kyselyä varten; sitten on tehtävä navigoida tarkalle sivulle ja paikkaan kyseisessä kirjassa ja hakea oikea kuva hakutuloksiin. Siten tässä tapauksessa käänteinen indeksi kartoittaisi sijaintiin (kuten kirjaan B), ja sitten B voisi sisältää indeksin, jossa on kaikki sanat, paikat ja esiintymien lukumäärä kussakin osassa.

Käänteinen indeksi, jota Index1 voisi edustaa yllä olevassa kaaviossa, näyttäisi suunnilleen tältä: jokainen sana tai sanajoukko toimii hakemistona niitä sisältäville kirjoille.

Välihakemisto näyttää samalta, mutta sisältää vain kirjan B sanat, sijainnin ja tiedot. Tämän monitasoisen arkkitehtuurin ansiosta jokainen hakemisto vie vähemmän tilaa kuin jos kaikki nämä tiedot tallennettaisiin yhteen suureen käänteiseen hakemistoon .

Ja tämä on avainasemassa suurissa järjestelmissä, koska jopa pakattuna nämä indeksit voivat olla melko suuria ja kalliita tallentaa. Oletetaan, että tässä järjestelmässä on monia kirjoja eri puolilta maailmaa - 100 000 000 (katso "Inside Google Books" -blogiviesti) ja että jokainen kirja on vain 10 sivua pitkä (laskennan yksinkertaistamiseksi) ja 250 sanaa sivulla : tämä antaa meille yhteensä 250 miljardia sanaa. Jos otamme sanan keskimääräiseksi merkkimääräksi 5 ja koodaamme jokaisen merkin 8 bitiksi (tai 1 tavuksi, vaikka jotkut merkit itse asiassa vievät 2 tavua), jolloin kulutetaan 5 tavua sanaa kohden, niin indeksi , joka sisältää jokaisen merkin. sana vain kerran, vaatisi yli 1 teratavun tallennustilaa. Joten voit nähdä, että indeksit, joissa on myös muuta tietoa, kuten sanajoukkoja, tietojen sijainti ja käyttömäärät, voivat kasvaa hyvin nopeasti.

Tällaisten väliindeksien luominen ja tietojen esittäminen pienempinä paloina helpottaa big data -ongelman ratkaisemista. Tiedot voidaan jakaa useille palvelimille ja olla samalla nopeasti käytettävissä. Hakemistot ovat tiedonhaun kulmakivi ja nykyaikaisten hakukoneiden perusta. Tietenkin tämä osio käsittelee vain indeksointia yleisesti, ja paljon on tutkittu, kuinka indeksejä voidaan tehdä pienemmiksi, nopeammiksi, informatiivisemmiksi (kuten osuvuudesta) ja saumattomasti päivitettäviksi. (Kilpailevien ehtojen hallinnassa sekä uusien tietojen lisäämiseen tai olemassa olevien tietojen muuttamiseen tarvittavien päivitysten määrässä on joitain ongelmia, varsinkin kun kyseessä on osuvuus tai pisteytys).

Tietojesi nopea ja helppo löytäminen on erittäin tärkeää, ja indeksit ovat yksinkertaisin ja tehokkain työkalu tämän saavuttamiseksi.

Kuormantasaajat

Lopuksi, toinen kriittinen osa minkä tahansa hajautetun järjestelmän on kuormituksen tasapainotin. Kuormantasaajat ovat olennainen osa mitä tahansa arkkitehtuuria, koska niiden tehtävänä on jakaa kuorma pyyntöjen palvelusta vastaavien solmujen kesken. Tämän ansiosta useat solmut voivat läpinäkyvästi palvella samaa toimintoa järjestelmässä. (Katso .) Niiden päätarkoitus on käsitellä monia samanaikaisia yhteyksiä ja reitittää ne yhdelle pyydetyistä solmuista, jolloin järjestelmä voi skaalata lisäämällä solmuja palvelemaan. Suuri määrä pyynnöt.

Kuva 1.18: Kuormantasauslaite

On olemassa monia erilaisia algoritmeja palvella pyyntöjä, mukaan lukien satunnaisen solmun valitseminen, syklinen algoritmi tai jopa valita solmun tiettyjen kriteerien, kuten suorittimen tai RAM-käytön, perusteella. Kuormantasaajat voidaan toteuttaa laitteistona tai ohjelmistona. Avoimen lähdekoodin kuormituksen tasaajista HAProxy on laajimmin käytetty.

Hajautetussa järjestelmässä kuormanjakolaitteet ovat usein järjestelmän "etulinjassa", joten kaikki saapuvat pyynnöt kulkevat suoraan niiden kautta. On hyvin todennäköistä, että monimutkaisessa hajautetussa järjestelmässä pyynnön on läpäistävä useita tasapainoimia, kuten kuvassa
.

Kuva 1.19: Useita kuormituksen tasauslaitteita

Kuten välityspalvelimet, jotkin kuormantasaajat voivat myös reitittää pyynnöt eri tavalla pyynnön tyypistä riippuen. Ne tunnetaan myös käänteisinä (käänteisinä) välityksin.

Tietyn käyttäjäistunnon tietojen hallinta on yksi haasteista kuormituksen tasaajia käytettäessä. Sivustolla verkkokauppa kun sinulla on vain yksi asiakas, on erittäin helppoa antaa käyttäjien laittaa tavaraa ostoskoriinsa ja tallentaa sisältö käyntien välillä (tämä on tärkeää, koska tuotteen myyntimahdollisuus kasvaa merkittävästi, jos tuote on edelleen ostoskorissa, kun käyttäjä palaa sivustolle) ). Jos käyttäjä kuitenkin ohjataan yhteen sivustoon ensimmäisen istunnon aikana ja sitten toiseen sivustoon seuraavan vierailunsa aikana, epäjohdonmukaisuuksia saattaa ilmetä, koska uusi solmu ei välttämättä ole tietoja kyseisen käyttäjän ostoskorin sisällöstä. (Etkö turhaudu, jos laitat Mountain Dew -paketin ostoskoriisi ja se on poissa, kun palaat?) Yksi ratkaisu voisi olla tehdä istunnoista "tahmeita" niin, että käyttäjä ohjataan aina samaan solmuun. Joidenkin luotettavuusominaisuuksien, kuten automaattisen vikasietoisuuden, hyödyntäminen on kuitenkin huomattavasti vaikeampaa. Tässä tapauksessa käyttäjän ostoskorissa on aina sisältöä, mutta jos tarrasolmu ei ole käytettävissä, tarvitaan erityistä varovaisuutta ja oletus ostoskorin sisällöstä ei enää pidä paikkaansa (vaikka tämä oletus ei toivottavasti tule sisään hakemus). Tämä ongelma voidaan tietysti ratkaista käyttämällä muita tässä luvussa kuvattuja strategioita ja työkaluja, kuten palveluita ja monia muita (kuten selaimen välimuistia, evästeitä ja URL-osoitteiden uudelleenkirjoittamista).

Jos järjestelmässä on vain muutama solmu, niin temput, kuten DNS-kiertoliittymät, ovat todennäköisesti käytännöllisempiä kuin kuormanjakolaitteet, jotka voivat olla kalliita ja lisätä järjestelmän monimutkaisuutta lisäämällä tarpeettoman kerroksen. Suurissa järjestelmissä on tietysti kaikenlaisia erilaisia aikataulutus- ja kuormitusalgoritmeja, mukaan lukien yksinkertaiset, kuten satunnaisvalinta- tai karusellialgoritmit ja paljon muuta. monimutkaiset mekanismit, jotka ottavat huomioon järjestelmän käyttömallin suorituskykyominaisuudet. Kaikki nämä algoritmit mahdollistavat liikenteen ja pyyntöjen jakamisen ja voivat tarjota hyödyllisiä työkaluja luotettavuus, kuten automaattinen vikasieto tai huonon solmun automaattinen poistaminen (esimerkiksi kun se lakkaa vastaamasta). Nämä edistyneet ominaisuudet voivat kuitenkin tehdä ongelmien diagnosoinnista hankalaa. Esimerkiksi tilanteissa, joissa korkea kuormitus, kuormituksen tasapainottimet poistavat solmut, jotka saattavat olla hitaita tai aikakatkaisuja (pyyntöjen tulvan vuoksi), mikä vain pahentaa muiden solmujen tilannetta. Näissä tapauksissa laaja ohjaus on tärkeää, koska vaikka järjestelmän kokonaisliikenne ja kuormitus näyttävät laskevan (koska solmut palvelevat vähemmän pyyntöjä), yksittäiset solmut voidaan silti työntää äärirajoille.

Kuormantasaajat ovat helppo tapa lisätä järjestelmän kapasiteettia. Kuten muutkin tässä artikkelissa kuvatut menetelmät, sillä on olennainen rooli hajautetun järjestelmän arkkitehtuurissa. Kuormantasaajat tarjoavat myös kriittiset toiminnot solmun kuntotarkastuksiin. Jos tällaisen tarkistuksen seurauksena solmu ei vastaa tai ylikuormitetaan, se voidaan poistaa pyyntöjen käsittelyvarannosta, ja järjestelmäsi redundanssin vuoksi kuorma jaetaan uudelleen jäljellä olevien työsolmujen kesken.

Jonot

Tähän mennessä olemme pohtineet monia tapoja lukea tietoja nopeasti. Samaan aikaan toinen tärkeä osa tietokerroksen skaalausta on tehokas hallinta levyjä. Kun järjestelmät ovat yksinkertaisia ja niille on ominaista vähäinen käsittelykuorma ja pienet tietokannat, kirjoittaminen voi olla ennustettavan nopeaa. Monimutkaisemmissa järjestelmissä tämä prosessi voi kuitenkin kestää äärettömän pitkän ajan. Joten esimerkiksi tiedot on ehkä kirjoitettava useisiin paikkoihin erilaisia palvelimia tai indeksejä, tai järjestelmä voi yksinkertaisesti olla raskaan kuormituksen alainen. Tapauksissa, joissa kirjoittaminen tai edes mikä tahansa tehtävä kestää kauan, suorituskyvyn ja käytettävyyden saavuttaminen edellyttää asynkronisuuden rakentamista järjestelmään. Yleinen tapa tehdä tämä on järjestää pyyntöjono.

Kuva 1.20: Synkroninen pyyntö

Kuvittele järjestelmä, jossa jokainen asiakas pyytää tehtävää etäpalvelu. Jokainen näistä asiakkaista lähettää pyyntönsä palvelimelle, joka suorittaa tehtävät mahdollisimman nopeasti ja palauttaa tulokset asianmukaisille asiakkaille. Pienissä järjestelmissä, joissa yksi palvelin (tai looginen palvelu) voi palvella saapuvia asiakkaita yhtä nopeasti kuin ne saapuvat, tällaisten tilanteiden pitäisi toimia hyvin. Kuitenkin, kun palvelin vastaanottaa enemmän pyyntöjä kuin se pystyy käsittelemään, jokaisen asiakkaan on odotettava muiden asiakkaiden pyyntöjen valmistumista, ennen kuin se tuottaa vastauksen omaan pyyntöönsä. Tämä on esimerkki synkronisesta pyynnöstä, joka on kuvattu .

Tällainen synkroninen käyttäytyminen voi merkittävästi heikentää asiakkaan suorituskykyä; itse asiassa käyttämättömänä, asiakas joutuu odottamaan, kunnes se saa vastauksen pyyntöön. Palvelimien lisääminen järjestelmän kuormituksen käsittelemiseksi ei todellakaan ratkaise ongelmaa; Vaikka tehokas kuormituksen tasapainotus on käytössä, on erittäin vaikeaa tarjota tasainen ja oikeudenmukainen kuormituksen jakautuminen, jota tarvitaan asiakkaan suorituskyvyn maksimoimiseksi. Lisäksi, jos palvelin ei ole käytettävissä käsittelemään tätä pyyntöä (tai se on epäkunnossa), myös siihen yhdistetty asiakas lakkaa toimimasta. Tämän ongelman tehokas ratkaiseminen edellyttää abstraktiota asiakkaan pyynnön ja sen palvelemiseksi tehtävän työn välillä.

Kuva 1.21: Jonojen käyttö pyyntöjen hallintaan

Kirjautumisjonot. Jonon mekanismi on hyvin yksinkertainen: tehtävä saapuu, menee jonoon ja sitten "työntekijät" hyväksyvät seuraavan tehtävän heti, kun heillä on mahdollisuus käsitellä se. (Katso .) Nämä tehtävät voivat olla yhtä yksinkertaisia kuin kirjoittaminen tietokantaan tai jotain niin monimutkaista kuin esikatselukuvan luominen asiakirjalle. Kun asiakas lähettää tehtäväpyyntöjä jonoon, sen ei enää tarvitse odottaa suorituksen tuloksia; sen sijaan pyynnöt on vain vahvistettava, että ne on vastaanotettu asianmukaisesti. Tämä vahvistus voi myöhemmin toimia linkkinä työn tuloksiin asiakkaan sitä pyytäessä.

Jonot antavat asiakkaille mahdollisuuden työskennellä asynkronisesti tarjoamalla strategisen abstraktion asiakkaan pyynnöstä ja vastauksesta. Toisaalta synkronisessa järjestelmässä pyynnön ja vastauksen välillä ei ole eroa, joten niitä ei voida hallita erikseen. Asynkronisessa järjestelmässä asiakas lähettää tehtävän, palvelu vastaa viestillä, joka vahvistaa, että tehtävä on vastaanotettu, ja sitten asiakas voi ajoittain tarkistaa tehtävän tilan ja pyytää tulosta vasta sen valmistuttua. Kun asiakas tekee asynkronisen pyynnön, hän voi vapaasti tehdä muuta työtä ja jopa tehdä asynkronisia pyyntöjä muille palveluille. Jälkimmäinen on esimerkki jonojen ja viestien toiminnasta hajautetuissa järjestelmissä.

Jonot tarjoavat myös jonkin verran suojaa palvelun keskeytyksiltä ja häiriöiltä. On esimerkiksi melko helppoa luoda erittäin kestävä jono, joka voi yrittää uudelleen palvelupyyntöjä, jotka epäonnistuvat lyhyiden palvelinkatkosten vuoksi. On parempi käyttää jonoa palvelun laatutakuiden toteuttamiseen kuin paljastaa asiakkaille tilapäisiä palvelukatkoksia, jotka edellyttävät monimutkaista ja usein epäjohdonmukaista virheenkäsittelyä asiakaspuolelta.

Jonot ovat perusperiaate hajautetun tiedonsiirron hallinnassa minkä tahansa laajamittaisen hajautetun järjestelmän eri osien välillä, ja niiden toteuttamiseen on monia tapoja. On olemassa useita avoimen lähdekoodin jonototeutuksia, kuten RabbitMQ.
ActiveMQ,
BeanstalkD , mutta jotkut käyttävät myös palveluita, kuten

skaalaus

hajautettua laskentaa

verkkokehitys

Kate Matsudaira

Lisää tageja

5.1.1 Verkkopalvelujen perusteet

Web palvelut on uusi tulevaisuuteen katsova arkkitehtuuri, joka tarjoaa uuden jakelutason. Komponenttien kehittämisen tai ostamisen ja IS:ään upottamisen sijaan ehdotetaan niiden käyttöajan ostamista ja ohjelmistojärjestelmän muodostamista, joka tekee menetelmäkutsuja itsenäisten palveluntarjoajien omistamista ja ylläpitämistä komponenteista. Verkkopalveluiden avulla minkä tahansa verkon ohjelman toiminnallisuus voidaan asettaa saataville Internetin kautta. Yksinkertaisin esimerkki verkkopalvelusta on Hotmailin Passport-järjestelmä, jonka avulla voit luoda käyttäjätunnistusta omalle sivustollesi.

Verkkopalvelut perustuvat seuraaviin universaaleihin teknologioihin:

TCP/IP on yleinen protokolla, jota kaikki verkkolaitteet ymmärtävät keskustietokoneista matkapuhelimiin ja PDA-laitteisiin.

HTML on yleinen merkintäkieli, jota käytetään tietojen näyttämiseen käyttäjän laitteilla.

XML (Extensible Markup Language) on universaali kieli kaikentyyppisten tietojen käsittelyyn.

Näiden teknologioiden monipuolisuus on perusta verkkopalveluiden ymmärtämiselle. Ne perustuvat vain yleisesti hyväksyttyihin, avoimiin ja muodollisesti toimittajariippumattomiin teknologioihin. Vain tätä kautta saavutetaan verkkopalvelujen tärkein etu hajautetun IS:n rakentamisen konseptina - niiden monipuolisuus, eli kyky käyttää mihin tahansa käyttöjärjestelmään, ohjelmointikieliin, sovelluspalvelimiin jne. Näin verkkopalvelut ratkaisevat alkuperäisen ongelman - luonteeltaan erilaisten sovellusten tehtäväintegraatio ja hajautetun IS:n rakentaminen. Tämä on tärkein perustavanlaatuinen ero verkkopalvelujen ja niiden edeltäjien välillä.

Verkkopalvelut ovat XML-sovelluksia, jotka sitovat tietoja ohjelmiin, objekteihin, tietokantoihin tai kokonaisiin liiketapahtumiin. Verkkopalvelun ja ohjelman välillä XML-dokumentteja vaihdetaan viestien muodossa. Verkkopalvelustandardit määrittelevät tällaisten viestien muodon, rajapinnan, johon viesti välitetään, säännöt viestin sisällön sitomiseksi palvelun toteuttavaan sovellukseen ja sieltä pois sekä mekanismit rajapintojen julkaisemiseen ja etsimiseen.

Verkkopalveluita voidaan käyttää monissa sovelluksissa. Käytitpä ne sitten asiakaspöytäkoneista tai kannettavista tietokoneista, verkkopalveluilla voidaan käyttää verkkopohjaisia sovelluksia, kuten ennakkotilausjärjestelmää tai tilausten toimitusjärjestelmää. Verkkopalvelut soveltuvat B2B- (business-to-business) -integraatioon, jolloin eri organisaatioiden käytössä olevat sovellukset lukitaan yhteen tuotantoprosessiin. Verkkopalvelut voivat myös ratkaista laajemman Enterprise Application Integration (EAI) -ongelman yhdistämällä useita sovelluksia yhdestä yrityksestä useisiin muihin sovelluksiin. Kaikissa näissä tapauksissa verkkopalveluteknologiat ovat "linkki", joka kokoaa yhteen erilaisia ohjelmistoja.

Kuten kuvasta näkyy. 5.1, verkkopalvelut ovat kääre, joka tarjoaa standardin tavan olla vuorovaikutuksessa sovellusohjelmistoympäristöjen, kuten tietokannan hallintajärjestelmien (DBMS), .NET:n, J2EE:n (Java2 Platform, Enterprise Edition), CORBA:n (Common Object Request Broker Architecture), välittäjien kanssa. Resource Planning (ERP) -paketit, integraatiovälittäjät jne.

Kuva 5.1. Verkkopalvelut ovat vuorovaikutuksessa sovellusjärjestelmien kanssa

Verkkopalvelurajapinnat vastaanottavat tavallisia XML-viestejä verkkoympäristöstä, muuntavat XML-tiedot tietyn sovellusohjelmistojärjestelmän "ymmärtämään" muotoon ja lähettävät vastausviestin (jälkimmäinen on valinnainen). Verkkopalveluiden ohjelmistototeutus (perusohjelmisto, alempi taso) voidaan luoda millä tahansa ohjelmointikielellä millä tahansa käyttöjärjestelmällä ja millä tahansa väliohjelmistolla (middleware).

Yksinkertainen esimerkki: tiedon etsiminen

Tällä hetkellä useimmat palvelut vedetään verkon kautta syöttämällä tiedot HTML-lomakkeisiin ja lähettämällä tiedot palveluun lisäämällä ne Uniform Resource Locator (URL) -merkkijonoon:

http://www.google.com/search?q=Skate+boots&btnG=Google+Search

Tämä esimerkki havainnollistaa verkkovuorovaikutuksen yksinkertaisuutta (kuten haku, osakkeiden ostaminen tai reittiohjeiden pyytäminen), jossa parametrit ja avainsanat upotetaan suoraan URL-osoitteeseen. Tässä tapauksessa Google-hakukoneen kyselymerkkijonossa esitetään yksinkertainen hakukysely luistinkengät (luistimet saappaat). Hakuavainsana edustaa käytettävää palvelua, ja Skate+boots -parametri on hakumerkkijono, joka syötettiin Googlen verkkosivun HTML-lomakkeeseen. Google-hakupalvelu välittää tämän kyselyn useille hakukoneille, jotka palauttavat luettelon URL-osoitteista sivuille, jotka vastaavat Skate+boots -hakuparametria. Tämä tehoton tapa etsiä Webistä perustuu täysin määritetyn tekstijonon ja indeksoitujen HTML-sivujen yhteensovittamiseen.

XML on paras tapa lähettää tietoja. XML tarjoaa merkittäviä etuja siirrettäessä tietoja Internetin kautta. Nyt edellinen pyyntö voidaan esittää XML-dokumenttina:

xmlns:s="www.xmlbus.com/SearchService">

Luistella

saappaat

koko 7.5

Pyynnön lähettämisellä XML-dokumenttina on seuraavat edut: kyky määritellä tietotyyppejä ja rakenteita, suurempi joustavuus ja laajennettavuus. XML voi edustaa strukturoitua dataa tai tietyn tyyppistä dataa (esimerkiksi kokokentän (koko) arvon määrittäminen joko numerosarjana tai liukulukuna) ja sisältää enemmän tietoa kuin URL-osoite sallii. .

Tämä esimerkki on SOAP-sanoman (Simple Object Access Protocol) muodossa, joka on XML-viestinnän vakiomuoto, joka on yksi verkkopalveluiden taustalla olevista tekniikoista. SOAP-sanomassa pyydetty palvelun nimi ja syöttöparametrit esitetään erillisinä XML-elementteinä. Tämä esimerkki havainnollistaa myös XML-nimiavaruuden (xmlns:) käyttöä, joka on toinen tärkeä verkkopalveluiden osa. Koska XML-dokumentit tukevat useita tietotyyppejä, monimutkaisia rakenteita ja skeemojen yhdistämistä, nykyaikaiset verkkopalvelutekniikat tarjoavat merkittävän edun verrattuna olemassa olevaan mahdollisuuteen käyttää ohjelmistosovelluksia HTML:n ja URL-osoitteiden kautta.

Seuraavan sukupolven verkko

Webin seuraavan sukupolven tulee perustumaan ohjelmistopohjaiseen vuorovaikutukseen. Verkkopalveluiden oletetaan käyttävän ihmisten vuorovaikutukseen luotuja globaaleja verkkoja aivan eri tarkoituksiin.

Verkkopalveluiden käyttö on kaupallisesti erittäin kannattavaa. Verkkopalveluiden yleistyessä internetistä on tulossa entistä tehokkaampi erityisesti kaupallisissa asioissa. Yhdistämällä suoran pääsyn ohjelmistosovelluksiin ja kaupallisiin asiakirjoihin, Webin seuraavan sukupolven verkkopalvelut tarjoavat täysin automatisoituja vuorovaikutuksia, jotka mahdollistavat pääsyn ohjelmatietoihin suoraan tuttuja verkkosivuja huomioimatta. Lisäksi verkkopalveluiden ydinkomponentit tarjoavat ja julkaisevat todennäköisesti monet erilaiset yksittäisiin toiminnallisiin elementteihin (valtuustiedot, tapahtumien koordinointi, tilinhallinta) erikoistuneet yritykset. Tämä tarjoaa suoran sovellusten välisen vuorovaikutuksen, joka on verkkopalveluiden taustalla oleva periaate ja määrittelee niiden olemuksen ja toteutuksen.

YLEINEN YMMÄRTÄMINEN

Verkkopalveluteknologia on olemassa erittäin korkealla abstraktiotasolla, mikä mahdollistaa useiden samanaikaisten määritelmien tukemisen, jotka joskus ovat epäjohdonmukaisia. Yksinkertaisimmalla tasolla verkkopalveluita voidaan pitää verkkopohjaisina tekstiintegroinnin välittäjinä. Mitä tahansa dataa voidaan muuntaa ASCII-tekstiin ja siitä, ja tämä lähestymistapa on pitkään ollut yhteinen nimittäjä grafiikan tulostusjärjestelmille ja tietokannan hallintajärjestelmille. Tekstilähtöiset järjestelmät ovat myös Internetin onnistuneen kehityksen taustalla, jolle verkkopalveluiden lisäabstrahoituminen perustuu. Mikä tahansa tietokone tai käyttöjärjestelmä voi tukea HTML:ää, selaimia ja verkkopalveluita. ja vastaanottaessaan tiedostoja verkon kautta, he ovat täysin välinpitämättömiä eivätkä edes tiedä, minkä tyyppisen sovellusjärjestelmän kanssa he ovat vuorovaikutuksessa.

Verkkopalveluiden edut ja haitat.

Hyötyihin Web palvelut voi sisältää seuraavat:

Verkkopalveluiden avulla yritys voi integroida liiketoimintaprosessinsa liikekumppaneiden ja asiakkaiden kanssa halvemmalla kuin muilla integraatiotekniikoilla. Tällaisten verkkopalveluihin perustuvien ratkaisujen hinta on saatavilla jopa pk-yrityksille (Small and Medium Business), mikä avaa tällaisille yrityksille uusia kehitysmahdollisuuksia;

Koska verkkopalvelut on järjestetty julkisiin rekistereihin (UDDI-rekisterit, ebXML-rekisterit tai muut), jotka ovat saatavilla kiinnostuneet henkilöt ympäri maailmaa yritysten kynnys päästä uusille markkinoille laskee, kun taas mahdollisuudet asiakaskunnan kasvattamiseen päinvastoin kasvavat;

Verkkopalvelut tuovat jatkuvuutta suhteessa yrityksessä jo olemassa olevaan IP:hen, eli voidaan sanoa, että verkkopalvelut rakentuvat edellä olemassa oleva IP-osoite, mutta ei sijasta niitä. Näin IT-infrastruktuuriin jo tehtyjen investointien turvallisuus varmistetaan eikä tarvittavat investoinnit kasva, koska radikaaleja muutoksia ei tarvita;

Uusien yritysratkaisujen rakentaminen verkkopalveluilla on nopeampaa ja kumulatiivisesti halvempaa, koska painopiste on ratkaisun liiketoimintalogiikan luomisessa, itse verkkopalvelujen ohjelmointi "kehystää" tämän prosessin vain tarvittaessa, ilman tehokkaan käytön vuoksi suuria työvoimakustannuksia. uudelleen käytettävää koodia ja mukautettuja kehitystyökaluja (IDE ja SDK).

Verkkopalveluiden haittoja (haittoja) ovat:

Liiketoimintaprosessien integrointistandardit, tapahtumanhallintakysymykset sekä yhtenäisten liiketoiminta- ja IT-käytäntöjen kehittäminen verkkopalveluiden kautta vuorovaikutuksessa oleville yrityksille ovat edelleen kehitteillä (huomioimme seuraavat aloitteet: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (lyhenne "BPEL" lausutaan "piippaukseksi")) IBM Corporationilta, XLANG Microsoft Corporationilta, ja WS-Coordination- ja WS-Transaction-määritykset ovat tulosta IBM:n, Microsoftin ja BEA:n yhteistyöstä). On selvää, että ilman niiden selkeää virallistamista ja julkaisemista verkkopalveluihin perustuvan IS:n rakentaminen voi sujua vain vaihtelevalla menestyksellä;

Verkkopalveluiden yritysrekisterien tiedon dynaaminen käyttö, verkkopalveluihin soittaminen, edellyttää eri yritysrekisterien välisten luottamusongelmien ratkaisemista. Lisäksi erimuotoisten yritysrekisterien jakamisessa on vaikeuksia (esim. tietyn verkkopalvelun etsiminen UDDI-rekisteristä ja ebXML-rekisteristä vaatii erilaisia lähestymistapoja, koska samaa verkkopalvelua kuvaavissa XML-dokumenteissa on eroja. jokainen näistä rekistereistä, vaikka on syytä huomata, että tätä ongelmaa yritetään ratkaista luomalla yksi rekisteriselain, esimerkiksi Sun Microsystemsin graafinen apuohjelma Registry Browser, joka toteuttaa joukon rajapintoja JAXR (Java API for XML Registries). );

Verkkopalveluntarjoajan toiminnallisuuden lisääminen sovelluspalvelimen toimintoihin voi teknologioiden uutuuden vuoksi aiheuttaa tiettyjä vaikeuksia;

Verkkopalveluihin perustuvan IS:n toiminnan turvallisuuskysymyksiä ei ole vielä täysin ratkaistu. WS-Security-spesifikaatio, IBM- ja Microsoft-yritysten toiminnan tuote, on tällä hetkellä varsin nuori, ei "selvitetty" ja on vielä osittain viimeistelemässä. WS-Security-spesifikaatioiden yleisyyden vuoksi seuraavaa turvallisuusasioihin omistettua eritelmää valmistellaan kuitenkin julkaistavaksi: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust , Web Services Secure Conversation, Web Services Federation .

Edut edustavat siis yritysten strategisia liiketoimintaetuja ja haitat ovat teknologisia ja teknologioiden uutuuden vuoksi näiden ongelmien ratkaiseminen on vain ajan kysymys.

Verkkopalvelun määritelmä

Soitetaan palvelua resurssi, joka toteuttaa liiketoimintatoiminnon ja jolla on seuraavat ominaisuudet:

on uudelleenkäytettävä;

määritellään yhdellä tai useammalla eksplisiittisellä teknologiasta riippumattomalla rajapinnalla;

liitetty löyhästi muihin samankaltaisiin resursseihin ja niitä voidaan kutsua viestintäprotokollien kautta, jotka sallivat resurssien olla vuorovaikutuksessa toistensa kanssa.

verkkopalvelu(Katso W3C-dokumentti "Web-services arkkitehtuurivaatimukset") on ohjelmistojärjestelmä, joka tunnistetaan URI-merkkijonolla, jonka rajapinnat ja sidokset määritellään ja kuvataan XML:llä. Tämän ohjelmistojärjestelmän kuvauksen voivat löytää muut ohjelmistojärjestelmät, jotka voivat olla vuorovaikutuksessa sen kanssa tämän kuvauksen mukaisesti XML-pohjaisten ja Internet-protokollia käyttäen välitettyjen sanomien kautta.