Hva er en webtjeneste. Organisering av arbeidet med webtjenester
Vi har gitt ut en ny bok, Social Media Content Marketing: How to Get Inside Your Followers' Heads and Make Them Fall in Love with Your Brand.
Webtjeneste (tjeneste) er et program som organiserer interaksjon mellom nettsteder. Informasjon fra en portal overføres til en annen.
For eksempel er det et flyselskap. Hun har mange flyreiser, noe som betyr at hun har mange billetter. Den overfører informasjon gjennom en nettjeneste til et reisesamlernettsted. En bruker som får tilgang til aggregatoren vil kunne kjøpe billetter til dette flyselskapet direkte der.
Et annet eksempel på nettjenester er et værsporingsnettsted som inneholder informasjon om værforhold i en bestemt by eller land som helhet. Denne informasjonen også ofte brukt av tredjeparter.
Informasjonen på Internett er variert. Nettsteder administreres av forskjellige systemer. Ulike overførings- og krypteringsprotokoller brukes. Webtjenester forenkler utveksling av informasjon mellom ulike nettsteder.
Webtjenesters arkitektur og protokoller
Du kan definere 3 myndigheter som samhandler med hverandre: katalog, entreprenør og kunde. Etter å ha opprettet tjenesten, registrerer entreprenøren den i katalogen, og kunden finner tjenesten der.
Datautvekslingsmekanismen er dannet i webtjenestebeskrivelsen. Dette er en spesifikasjon som dekker videresendingsformater, innholdstyper, transportprotokoller som brukes i prosessen med å utveksle informasjon mellom kunden og tjenestetransportøren.
I dag brukes flere teknologier oftest for å implementere ulike webtjenester:
- TCP/IP er en protokoll som er forstått av nesten alle nettverksutstyr, fra stormaskiner til bærbare enheter og PDAer.
- HTML er et universelt merkespråk som brukes til å vise innhold på forbrukerenheter.
- XML er et universelt verktøy for behandling av alle typer data. Andre inkan fungere på dens basis: SOAP og WSDL.
- UDDI er en universell kilde til anerkjennelse, integrering og beskrivelse. Det fungerer som regel i private nettverk og har ennå ikke funnet tilstrekkelig distribusjon.
Allsidigheten til de presenterte teknologiene er grunnlaget for å forstå webtjenester. De jobber for standard teknologier, uavhengig av applikasjonsleverandører og andre nettverksressurser. Kan brukes i alle operativsystemer, applikasjonsservere, programmeringsspråk osv.
Fordeler
- Skape nødvendige forutsetninger for samhandling programvarekomponenter uavhengig av plattform.
- Webtjenester er basert på åpne standardprotokoller. På grunn av introduksjonen av XML er opprettelsen og konfigureringen av webtjenester forenklet.
- Bruken av HTTP garanterer samhandling av systemene gjennom internettarbeid.
Feil
- Lav ytelse og stort trafikkvolum, sammenlignet med RMI, CORBA, DCOM-systemer, på grunn av bruk av XML-meldinger i tekstsammenheng.
- Sikkerhetsnivå. Alle moderne webtjenester må implementere koding og krever brukerautorisasjon. Hvorvidt HTTPS er nok her eller det trengs mer pålitelige protokoller, som XML-kryptering, SAML osv., avgjøres under utviklingen.
Oppgaver for nettjenester
Webtjenester kan brukes på mange områder.
B2B-transaksjoner
Integrering av prosesser skjer umiddelbart, uten deltakelse fra mennesker. For eksempel oppdatering av nettbutikkkatalogen med nye produkter. De bringes til lageret, og lagerholderen noterer ankomsten i databasen. Informasjonen overføres automatisk til nettbutikken. Og kjøperen, i stedet for å merke "Ikke på lager" på produktkortet, ser antallet.
Integrasjon av bedriftstjenester
Hvis bedriften bruker bedriftsprogrammer, vil webtjenesten hjelpe med å sette opp deres felles arbeid.
Opprette et klient-serversystem
Tjenester brukes til å konfigurere driften av klienten og serveren. Dette gir fordeler:
- du kan ikke selge den selv programvare, men gjør tilgang til nettjenesten betalt;
- Det er lettere å løse problemer ved å bruke tredjepartsprogramvare;
- det er lettere å organisere tilgangen til innholdet og materialet på serveren.
En webtjeneste er en applikasjon som forenkler det tekniske oppsettet av ressursinteraksjon.
Hvor skal vi begynne? Og rett fra kunde-utfører-kontakten: telefonen ringer i internettstudioet. Kontosjefen tar telefonen og hilser på deg. Fra den siden høres det omtrent slik ut:
- God ettermiddag. Jeg trenger en nettside, en enkel. Hva er prisen? (samme historie med webapplikasjoner).
Dette er virkelig en hodepine for hver konto. Men han er ikke nervøs og forklarer at nettsteder varierer i kompleksitet, funksjonalitet osv. Klargjør hva klienten trenger og hva "enkelt" betyr i hans forståelse. Han får for eksempel følgende svar:
- Vel, du skjønner, jeg har en bedrift som selger vinduer. Det ville vært fint å lage et nettsted slik at du kan lage et "virtuelt" vindu for deg selv. Velg farge, materialer, størrelser. Angi mengde. Se hvordan det vil se ut. Vel, da ville spesialistene våre gå til stedet. Avtalt?
Dette er allerede interessant. Men det er ikke alt:
– Og ja, jeg har et annet ønske. Vi har en avdeling i Moskva, St. Petersburg og Novosibirsk. Personalet er stort, det er papirarbeid, vel, du forstår. Du kan gjøre noe som... et lite sosialt nettverk inne på siden, eller hva? Det vil være mer praktisk for oss å kommunisere på denne måten, uten noen "aser". Og lagre dokumenter i en "sky" - jeg hørte at de gjør dette.
Kontoansvarlig skriver ned alt, gjør et grovt estimat og navngir kostnadene. Potensiell klient himler med øynene (du kan høre dette selv på telefonen), sier "prisene dine er bare gale" og legger høflig på.
Selvfølgelig er dette en mega-overdrevet situasjon, men dette skjer hele tiden både ved programmering av Internett-applikasjoner og ved opprettelse av nettsider. Målet vårt er å finne ut hvorfor dette skjer.
Hva er en webtjeneste?
Utvikling av en webtjeneste er i det store og hele den samme utviklingen av en nettside. Men det er ett stort "MEN": i motsetning til kampanjesidene og bedriftsarrangementene som allerede er kjent for alle, har nettjenesten unik funksjonalitet. Dette kan være en produktdesigner (som i eksempelet ovenfor), fotohosting, et lukket sosialt nettverk for bedriftsbruk, et åpent sosialt nettverk (danedaiboh), en oppslagstavle...
Stort sett er de som bestemmer seg for å lage en nettjeneste de som er avhengige av innovasjon, bekvemmelighet og moderne nettteknologi. I dette tilfellet fungerer den unike funksjonaliteten som "trumfkortet" til virksomheten, med dets hjelp er det ment å kvele konkurrenter og øke kundebasen.
Og alt dette betyr er at:
- Det vil ta litt tid å finne ut av alle mulighetene for det fremtidige prosjektet. Vanligvis mye tid.
- En detaljert studie vil være nødvendig teknisk oppgave. Eller enda bedre, en prototype.
- Du må utvikle selve webtjenesten (uventet, ikke sant?). Gjør det fra bunnen av eller bruk eksisterende utviklinger. Men i alle fall vil det være umulig å "montere" den på knærne, ut av esken, i henhold til en mal og "raskt".
- Produktet må testes grundig før utgivelse.
Som et resultat vil prisen for å lage en webtjeneste (sammen med dens programmering) svinge. Men det vil alltid være høyere enn for et nettsted med et "typisk" sett med funksjoner.
For vårt eksempel: når klienten nevnte internt sosialt nettverk, skylagring for data og en vindusdesigner – til sammen ble det mulig å kalle det en webtjeneste. Derfor ble kostnaden kalt "uventet" for kunden.
"Space"-priser ved utvikling av Internett-tjenester er et berettiget tiltak. Dette er objektivt sett vanskelig og langvarig arbeid.
Hvorvidt en bedrift trenger en slik tjeneste er en oppgave for dine markedsførere.
Et spesielt og favorittemne for alle er sosiale nettverk.
Her skjer det ganske morsomme ting. Dessuten spilles disse komediene med et seriøst ansikt. For eksempel vil en viss aktiv prosentandel av skolebarn, "avanserte" VKontakte-brukere, stadig ha sitt eget spill. Til svimlende suksess. Og for ikke å bry seg.
Som et resultat mottar vi tonnevis av brev i innboksen vår og i fellesskapet med teksten «selg/utvikle en forretningsapplikasjon/spill/noe annet for oss». Noe sånt som dette:
Ja, 5000 rubler for flere ukers arbeid - ok. Vi snakker nå kun om passende eksemplarer, og ikke om de som får et publikum på 200 brukere og visner bort.
Hvis du likevel blir forbigått av manien for å lage en vellykket klone, så tenk i det minste på hvor mye det kostet forfatterne av originalen å promotere og promotere en nettapplikasjon eller tjeneste (vanligvis er dette utviklingsbudsjettet multiplisert med ti).
Ikke gjør feil. Beregn styrken din. Start vellykkede Internett-prosjekter. Amen.
Emnetittelen er egentlig et spørsmål, fordi... Selv vet jeg ikke hva det er, og for første gang vil jeg prøve å jobbe med det innenfor rammen av denne artikkelen. Det eneste jeg kan garantere er at koden presentert nedenfor vil fungere, men mine setninger vil kun være antagelser og gjetninger om hvordan jeg selv forstår alt dette. Så la oss gå...
Introduksjon
Vi må starte med hvorfor konseptet med webtjenester ble opprettet. Da dette konseptet dukket opp i verden, eksisterte allerede teknologier som tillot applikasjoner å samhandle på avstand, der ett program kunne kalle en metode i et annet program, som kunne lanseres på en datamaskin som ligger i en annen by eller til og med land. Alt dette er forkortet til RPC (Remote Procedure Calling). Eksempler inkluderer CORBA-teknologier, og for Java - RMI (Remote Method Invoking). Og alt ser ut til å være bra i dem, spesielt i CORBA, fordi... Du kan jobbe med det i alle programmeringsspråk, men noe manglet fortsatt. Jeg tror at ulempen med CORBA er at den fungerer gjennom noe av seg selv nettverksprotokoller i stedet for enkel HTTP, som vil komme gjennom enhver brannmur. Ideen med webtjenesten var å lage en RPC som skulle settes inn i HTTP-pakker. Dermed begynte utviklingen av standarden. Hva er de grunnleggende konseptene i denne standarden:- SÅPE. Før du ringer en ekstern prosedyre, må du beskrive denne samtalen XML-fil e SOAP-format. SOAP er rett og slett en av de mange XML-markeringene som brukes i webtjenester. Alt vi ønsker å sende et sted via HTTP blir først gjort om til XML SÅPEbeskrivelse, deretter stappes den inn i en HTTP-pakke og sendes til en annen datamaskin på nettverket via TCP/IP.
- WSDL. Det finnes en webtjeneste, dvs. et program hvis metoder kan kalles eksternt. Men standarden krever at dette programmet ledsages av en beskrivelse som sier at "ja, du har rett - dette er virkelig en nettjeneste, og du kan kalle slike og slike metoder fra den." Denne beskrivelsen er representert av en annen XML-fil, som har et annet format, nemlig WSDL. De. WSDL er bare en XML-fil som beskriver en webtjeneste og ingenting mer.
Generell tilnærming
I webtjenester er det alltid en klient og en server. Serveren er vår webtjeneste og kalles noen ganger endepunktet (som i, endepunktet der SOAP-meldinger fra klienten når). Vi må gjøre følgende:- Beskriv grensesnittet til vår webtjeneste
- Implementer dette grensesnittet
- Start vår nettjeneste
- Skriv en klient og eksternt ring ønsket nettjenestemetode
Server
La oss lansere IDEA og lage nytt prosjekt Opprett nytt prosjekt. La oss angi navnet HelloWebService og trykk på knappen Neste, deretter knappen Bli ferdig. I mappe src la oss lage en pakke ru.javarush.ws. I denne pakken vil vi lage HelloWebService-grensesnittet: pakke ru. javarush. ws; // dette er merknader, dvs. en måte å markere våre klasser og metoder, // relatert til nettjenesteteknologi importer javax. jws. WebMethod; importer javax. jws. Nettjeneste; importer javax. jws. såpe. SOAPBinding; // vi sier at grensesnittet vårt vil fungere som en webtjeneste@Nettjeneste // vi sier at webtjenesten vil bli brukt til å ringe metoder@SOAPBinding (stil = SOAPBinding. Style. RPC) offentlig grensesnitt HelloWebService ( // vi sier at denne metoden kan kalles eksternt@WebMethod offentlig streng getHelloString(strengnavn) ; ) I denne koden er WebService- og WebMethod-klassene såkalte merknader og gjør ingenting annet enn å merke grensesnittet vårt og metoden som en webtjeneste. Det samme gjelder SOAPBinding-klassen. Den eneste forskjellen er at SOAPBinding er en merknad med parametere. I dette tilfellet brukes stilparameteren med en verdi som indikerer at webtjenesten ikke vil fungere gjennom dokumentmeldinger, men som en klassisk RPC, dvs. å kalle en metode. La oss implementere grensesnittlogikken vår og lage en HelloWebServiceImpl-klasse i pakken vår. Forresten, jeg bemerker at å avslutte en klasse med Impl er en konvensjon i Java, ifølge hvilken implementeringen av grensesnitt er utpekt slik (Impl - fra ordet implementering, dvs. implementering). Dette er ikke et krav og du står fritt til å navngi klassen hva du vil, men god oppførsel krever det: pakke ru. javarush. ws; // samme merknad som når du beskriver grensesnittet, importer javax. jws. Nettjeneste; // men her brukes den med endpointInterface-parameteren, // indikerer fullt navn grensesnittklassen til vår nettjeneste@WebService(endepunktgrensesnitt= "ru.javarush.ws.HelloWebService") offentlig klasse HelloWebServiceImpl implementerer HelloWebService ( @Override public String getHelloString (String name) ( // bare returner hilsenen returner "Hei, " + navn + "!" ; ) ) La oss lansere vår nettjeneste som en uavhengig server, dvs. uten deltagelse av noen Tomcat og applikasjonsservere (dette er et emne for en egen diskusjon). For å gjøre dette, i prosjektstrukturen i mappen src La oss lage en pakke ru.javarush.endpoint, og i den vil vi lage en HelloWebServicePublisher-klasse med hovedmetoden: pakke ru. javarush. endepunkt; // klasse for å kjøre en webserver med webtjenester importer javax. xml. ws. endepunkt; // klasse av vår nettjeneste import ru. javarush. ws. HelloWebServiceImpl; offentlig klasse HelloWebServicePublisher ( public static void main (String... args) ( // start webserveren på port 1986 // og til adressen spesifisert i det første argumentet, // start webtjenesten som ble sendt i det andre argumentet Endepunkt. publisere( "http://localhost:1986/wss/hello", ny HelloWebServiceImpl () ); ) ) La oss nå kjøre denne klassen ved å klikke Shift+F10. Ingenting vil vises i konsollen, men serveren kjører. Du kan bekrefte dette ved å skrive inn linjen http://localhost:1986/wss/hello?wsdl i nettleseren din. Siden som åpnes, beviser på den ene siden at vi har en webserver (http://) som kjører på port 1986 på datamaskinen vår (localhost), og viser på den annen side en WSDL-beskrivelse av vår webtjeneste. Hvis du stopper applikasjonen, blir beskrivelsen utilgjengelig, det samme vil webtjenesten selv, så vi vil ikke gjøre dette, men gå videre til å skrive klienten.Klient
I prosjektmappen src La oss lage en pakke ru.javarush.client , og i den HelloWebServiceClient-klassen med hovedmetoden: pakke ru. javarush. klient; // nødvendig for å få wsdl-beskrivelse og gjennom den // nå selve webtjenesten importer java. nett. URL; // dette unntaket vil oppstå når du arbeider med et URL-objekt importer java. nett. Misformet URLEunntak; // klasser for å analysere xml med wsdl-beskrivelse // og nå servicekoden i den importer javax. xml. navneområde. QName; importer javax. xml. ws. Service; // grensesnittet til webtjenesten vår (vi trenger mer) import ru. javarush. ws. HelloWebService; offentlig klasse HelloWebServiceClient ( offentlig statisk void main (String args) kaster MalformedURLEexception ( // opprett en lenke til wsdl-beskrivelse URL url= ny URL ( "http://localhost:1986/wss/hello?wsdl") ; // Vi ser på parametrene til neste konstruktør i den aller første taggen i WSDL-beskrivelsen - definisjoner // se på det første argumentet i targetNamespace-attributtet // se på det andre argumentet i navnattributtet QName qname = new QName ("http://ws.site/" , "HelloWebServiceImplService" ) ; // Nå kan vi nå servicekoden i wsdl-beskrivelsen, Service service= Service. opprette (url, qname); // og deretter opp til port-taggen som er nestet i den, slik at // få en lenke til et webtjenesteobjekt eksternt fra oss HelloWebService hei = tjeneste. getPort(HelloWebService.class); // Hurra! Du kan nå kalle den eksterne metoden System. ute. println (hei. getHelloString ("JavaRush") ); ) ) Jeg ga maksimale kommentarer til koden i oppføringen. Jeg har ingenting å legge til, så la oss kjøre (Shift+F10). Vi bør se teksten i konsollen: Hei, JavaRush! Hvis du ikke så det, har du sannsynligvis glemt å starte nettjenesten.Konklusjon
Dette emnet ga en kort utflukt til webtjenester. Nok en gang vil jeg si at mye av det jeg skrev er min gjetning om hvordan det fungerer, og derfor bør du ikke stole for mye på meg. Jeg vil være takknemlig om kunnskapsrike folk korrigerer meg, for da lærer jeg noe. UPD.Alexander Kachanov
Ideen om webtjenester ble utviklet av dataindustriens giganter som Sun, Oracle, HP, Microsoft og IBM. Denne ideen er ikke noe nytt, men det er et stort skritt fremover mot enklere tilgang til programmer over nettet. Basert på standard kommunikasjonsformater kan webtjenester fullstendig endre måten vi tenker på hvordan vi skal lage nettsider.
Hva er en webtjeneste?
Takket være webtjenester kan funksjonene til ethvert program gjøres tilgjengelig over Internett. Dermed kan programmer som PHP, ASP, JSP-skript, JavaBeans, COM-objekter og alle våre andre favorittprogrammeringsverktøy nå få tilgang til et eller annet program som kjører på en annen server (dvs. en webtjeneste) og bruke svaret mottatt fra henne på nettstedet hennes, eller applikasjon.
La oss si at hvis jeg trenger å utføre en programmeringsoppgave, og jeg er for opptatt (eller ute av tankene til å finne opp hjulet selv igjen), kan jeg bruke tjenestene til en nettjeneste som nettstedet mitt vil få tilgang til via Internett. Ved å sende en forespørsel med parametere til webtjenesten forventer jeg å motta et svar som inneholder resultatet av å utføre forespørselen min.
Alle som noen gang har jobbet i I det siste Med Hotmail, har allerede delvis møtt webtjenester: Passport-brukerautentiseringssystemet er en av tjenestene som er inkludert i Microsoft .NET-initiativet. Det er for øyeblikket tilgjengelig gratis, så nettstedskapere kan enkelt implementere brukerautentisering på nettstedet deres.
Grunnleggende
Prinsippene bak webtjenester er overraskende enkle. Og de tilfører ingenting nytt til verden av distribuert databehandling og Internett:
- den ansvarlige for nettjenesten bestemmer formatet på forespørsler til sin nettjeneste og svarene på den
- enhver datamaskin på nettverket sender en forespørsel til en nettjeneste
- en nettjeneste behandler en forespørsel, utfører en handling og sender deretter et svar
Denne handlingen kan for eksempel være å vise en aksjekurs, vise prisen på et bestemt produkt, lagre en oppføring i en avtalekalender, oversette tekst fra ett språk til et annet eller sjekke et kredittkortnummer.
Standarder i kjernen
Grunnen til at vi alle plutselig er interessert i webtjenester er at de er basert på standarder, åpne protokoller for datautveksling og overføring.
Før dette utviklet mange selskaper sine egne proprietære standarder og formater. Og nå er alt vi trenger å vite for å jobbe enkel XML(eXtensible Markup Language), som overføres over den gamle kjente HTTP-protokollen. Dette betyr at informasjon om hvordan webtjenester fungerer er tilgjengelig for alle, og webutviklere som er kjent med disse teknologiene av yrke kan begynne å leke med webtjenester i dag.
Forskjellen mellom webtjenester og andre teknologier som utviklere har møtt (for eksempel DCOM, named pipes, RMI) er at webtjenester er basert på åpne standarder, de er enkle å lære, og disse standardene støttes bredt over hele verden. Unix og Windows-plattformer.
Simple Object Access Protocol (SOAP) er en standardprotokoll utviklet av W3C. Den definerer formatet for forespørsler til webtjenester.
Meldinger mellom en nettjeneste og dens bruker er pakket i SOAP-konvolutter. Meldinger inneholder enten en forespørsel om å utføre en handling, eller et svar - resultatet av å utføre denne handlingen. Konvolutten og dens innhold er kodet i XML og er ganske lett å forstå. Slik ser en enkel SOAP-forespørsel ut når den sendes via HTPP til en nettjeneste:
xmlns:m="http://www.somesite.com/Postcode">
Nøkkelelementene i en SOAP-konvolutt er ganske enkle å finne ut: dette er to parametere (
Og svaret vil se slik ut:
xmlns:m="http://www.somesite.com/Postcode">
Denne meldingen er enda enklere å tyde. Element
Nå om UDDI
Selv om SOAP-protokollen er enkel, ville webtjenester vært til liten nytte hvis vi ikke hadde noen måte å finne dem på. Heldigvis gikk IBM, Microsoft og Ariba opp og opprettet UDDI-prosjektet (Universal Description, Discovery and Integration), som de håper vil bli en felles katalog over alle nettjenester på nettet.
UDDI-systemet gjør det mulig for bedrifter å eksponere sin webtjeneste for publikum. Denne katalogen fungerer som telefonbok alle webtjenester. Registrering i UDDI-katalogen er gratis, og grunnleggerne av prosjektet håper at denne katalogen vil inneholde beskrivelser av alle, alle, alle tjenester over hele nettet, slik at for å finne den ønskede nettjenesten, trenger du bare å henvende deg til én UDDI katalog.
Hvordan fungerer det hele
Så hvordan finner jeg riktig nettjeneste?
La oss forestille oss at jeg er en nettstedsutvikler, og klienten min ba meg legge til nettstedet ny funksjon: Du må legge til en postnummersjekk i registreringsskjemaet.
For å utføre denne kontrollen, må jeg opprette en database med alle postnumre i alle 30 landene der selskapet vårt driver virksomhet, og deretter sjekke at postnummeret tilsvarer byen som er spesifisert i registreringen ved registrering. Men jeg har ikke disse dataene, og jeg tror at det å samle inn slike data vil måtte bruke en betydelig sum penger.
I stedet for å betale ut penger for å kjøpe en database, skrive koden selv, sikre integriteten og korrektheten til alle dataene og feilsøke skriptene, går jeg bare til UDDI-katalogen og ser om det finnes en webtjeneste som kan gjøre jobben for meg. Når jeg kommer til nettstedet http://www.uddi.org/, starter jeg et søk og finner en utmerket tjeneste fra XYZ Corp.
Jeg går nøye gjennom definisjonen av webtjenesteformatet (definisjonen er skrevet i WSDL (Web Services Description Language), og sørger for at tjenesten gjør akkurat det jeg trenger. Deretter sjekker jeg med mine kolleger om ryktet til XYZ Corp., og finner ut av det. at den er solid , og kontakt deretter XYZ Corp. angående priser. Hvis prisen for å få tilgang til tjenesten er innenfor budsjettet mitt, skriver jeg en enkel JSP-side for nettstedet mitt som kaller XYZ Corp. sin nettjeneste, og se, umiddelbar bekreftelse vises på nettstedets postnummer.
Det er verdt tiden din
Selv om du ikke har noe med programmering eller utviklingsteknologier å gjøre, er webtjenester verdt å lære mer om. Se for deg et bilde av hvordan du diskuterer en ny nettside med en klient, og diskuterer alle funksjonene til det nye prosjektet. Alt går bra: Budsjettet oppfyller kundens forventninger, han likte skissen av stedsplanen og likte grensesnitteksemplene. Alt ser ut til å fungere.
Og plutselig husker de en veldig kompleks funksjon. Ved bare omtale av det blir nettutviklerens ansikt grønt og han begynner å kveles og hoste. Dette er utvikleren som gir deg et signal om at utvikling av denne funksjonen vil kreve mye penger og tid, eller at det rett og slett ikke er mulig med et slikt budsjett.
Slipp frykten! Jeg er klar til å garantere at det allerede er en webtjeneste på Internett som er klar til å gi deg den nødvendige funksjonen, og kostnadene ved å bruke denne webtjenesten vil være mye lavere enn kostnadene ved å utvikle sin analoge uavhengig. På denne måten sparer du utvikleren din fra unødvendig hodepine, klienten din fra å kaste bort penger ved å bruke et par minutter på å bla gjennom UDDI-katalogen.
Tjenesteutvikling
Utviklere trenger selvfølgelig ikke være fornøyd med bare nettjenester laget av andre. Ved å bruke en av følgende verktøysett kan du lage din egen webtjeneste og tilby tjenester til andre Internett-brukere.
Valget av verktøy for å utvikle webtjenester er omfattende. Den inkluderer verktøy fra selskaper som Sun (Open Net), Microsoft (.NET), (e-tjenester) og IBM (Web Services). Det finnes også rammeverk med åpen kildekode. Mono-prosjektet har for eksempel som mål å erstatte Microsofts .NET-verktøysett ved å tilby kompilatorer, kjøretid og biblioteker for å kjøre de samme webtjenestene på alle plattformer, inkludert Unix.
Til tross for variasjonen av servere og utviklingsverktøy for webtjenester, støtter de alle den samme SOAP-protokollen, XML-språket og UDDI-systemet.
Minuser
Før jeg fullstendig forlater karrieren som programmerer og vier meg til å bruke nettjenester, må jeg stille meg selv spørsmålet: "Det er et for rosenrødt bilde. Hva er galt med det?" Dessverre har det store potensialet til webtjenester en pris:
- Bruk av XML som dataoverføringsformat resulterer i at meldingene dine blir veldig store: XML-koder tar mye plass, og dette legger en viss belastning på oss for å skape, overføre og tolke budskap.
- Siden vi bruker eksterne datamaskiner Vi er helt avhengige av Internett for å utføre visse funksjoner, noe som skaper for mange upålitelige lenker i kjeden mellom vår webserver og webtjenesten.
- I dag er det få bedrifter som lager webtjenester, og få bedrifter bruker dem. Feilsøking og forbedring av nettjenestesystemet krever fortsatt lang tid.
- Systemet med lisensiering og betaling for bruk av nettjenester har ennå ikke blitt akseptert av utviklere. På grunn av det faktum at det fortsatt er for få webtjenester, prøver de fleste bedrifter å gjøre et godt inntrykk på sine potensielle kunder ved bevisst å redusere kostnadene for tjenester og tilby gunstige lisensvilkår. Det vil fortsatt ta en stund før de reelle kostnadene for webtjenester blir klare.
Når nettjenester tar deres plass og blir tilgjengelige for alle, vil de bli en uvurderlig hjelp for nettutviklere. De vil gi oss fleksibel tilgang til den fulle kraften til alle datamaskiner på nettverket. Det er på tide at nettstedbyggere blir interessert i nettjenester og lærer mer om hva de kan få ut av dem.
Emnetittelen er egentlig et spørsmål, fordi... Selv vet jeg ikke hva det er, og for første gang vil jeg prøve å jobbe med det innenfor rammen av denne artikkelen. Det eneste jeg kan garantere er at koden presentert nedenfor vil fungere, men mine setninger vil kun være antagelser og gjetninger om hvordan jeg selv forstår alt dette. Så la oss gå...
Introduksjon
Vi må starte med hvorfor konseptet med webtjenester ble opprettet. Da dette konseptet dukket opp i verden, eksisterte allerede teknologier som tillot applikasjoner å samhandle på avstand, der ett program kunne kalle en metode i et annet program, som kunne lanseres på en datamaskin som ligger i en annen by eller til og med land. Alt dette er forkortet til RPC (Remote Procedure Calling). Eksempler inkluderer CORBA-teknologier, og for Java - RMI (Remote Method Invoking). Og alt ser ut til å være bra i dem, spesielt i CORBA, fordi... Du kan jobbe med det i alle programmeringsspråk, men noe manglet fortsatt. Jeg tror at ulempen med CORBA er at den fungerer gjennom noen av sine egne nettverksprotokoller i stedet for enkel HTTP, som passer gjennom enhver brannmur. Ideen med webtjenesten var å lage en RPC som skulle settes inn i HTTP-pakker. Dermed begynte utviklingen av standarden. Hva er de grunnleggende konseptene i denne standarden:- SÅPE. Før du kaller en ekstern prosedyre, må du beskrive denne samtalen i en XML-fil i SOAP-format. SOAP er rett og slett en av de mange XML-markeringene som brukes i webtjenester. Alt vi ønsker å sende et sted via HTTP blir først konvertert til en XML SOAP-beskrivelse, deretter stappet inn i en HTTP-pakke og sendt til en annen datamaskin på nettverket via TCP/IP.
- WSDL. Det finnes en webtjeneste, dvs. et program hvis metoder kan kalles eksternt. Men standarden krever at dette programmet ledsages av en beskrivelse som sier at "ja, du har rett - dette er virkelig en nettjeneste, og du kan kalle slike og slike metoder fra den." Denne beskrivelsen er representert av en annen XML-fil, som har et annet format, nemlig WSDL. De. WSDL er bare en XML-fil som beskriver en webtjeneste og ingenting mer.
Generell tilnærming
I webtjenester er det alltid en klient og en server. Serveren er vår webtjeneste og kalles noen ganger endepunktet (som i, endepunktet der SOAP-meldinger fra klienten når). Vi må gjøre følgende:- Beskriv grensesnittet til vår webtjeneste
- Implementer dette grensesnittet
- Start vår nettjeneste
- Skriv en klient og eksternt ring ønsket nettjenestemetode
