Hvad er webtjenester? Architecture, Typer, Eksempel

Hvad er webservice?

Webtjeneste er et standardiseret medie til at udbrede kommunikation mellem klient- og serverapplikationer på WWW (World Wide Web). En webservice er et softwaremodul, der er designet til at udføre et bestemt sæt opgaver.

• Webtjenester i cloud computing kan søges efter over netværket og kan også aktiveres i overensstemmelse hermed.
• Når den påberåbes, vil webtjenesten være i stand til at levere funktionaliteten til klienten, som påkalder denne webtjeneste.

Hvordan fungerer webtjenester?

Ovenstående diagram viser et meget forenklet billede af, hvordan en webtjeneste rent faktisk ville fungere. Klienten ville påkalde en række webservicekald via anmodninger til en server, som ville være vært for den faktiske webservice.

Disse anmodninger foretages via det, der kaldes fjernprocedurekald. Fjernprocedurekald (RPC) er kald til metoder, der hostes af den relevante webtjeneste.

Som et eksempel, Amazon leverer en webservice, der giver priser for produkter, der sælges online via amazon.com. Frontend eller præsentationslaget kan være i .Net eller Java, men begge programmeringssprog ville have mulighed for at kommunikere med webtjenesten.

Hovedkomponenten i et webservicedesign er de data, der overføres mellem klienten og serveren, og det er XML. XML (udvideligt markeringssprog) er en pendant til HTML og et letforståeligt mellemsprog, der forstås af mange programmeringssprog.

Så når applikationer kommunikerer med hinanden, kommunikerer de faktisk i XML. Dette giver en fælles platform for applikationer udviklet i forskellige programmeringssprog, så de kan kommunikere med hinanden.

Webtjenester bruger noget kendt som SOAP (Simple Object Access Protocol) til at sende XML-data mellem applikationer. Dataene sendes over normal HTTP. De data, der sendes fra webtjenesten til applikationen, kaldes en SOAP-besked. SOAP-meddelelsen er intet andet end et XML-dokument. Da dokumentet er skrevet i XML, kan klientapplikationen, der kalder webservicen, skrives i et hvilket som helst programmeringssprog.

Hvorfor har du brug for en webservice?

Moderne forretningsapplikationer bruger en række forskellige programmeringsplatforme til at udvikle webbaserede applikationer. Nogle applikationer kan være udviklet i Java, andre i .Net, mens nogle andre i Angular JS, Node.js osv.

Disse heterogene applikationer har oftest brug for en form for kommunikation mellem dem. Da de er bygget med forskellige udviklingssprog, bliver det virkelig vanskeligt at sikre præcis kommunikation mellem applikationer.

Det er her, webtjenester kommer ind i billedet. Webtjenester giver en fælles platform, der tillader flere applikationer bygget på forskellige programmeringssprog at have evnen til at kommunikere med hinanden.

Typer af webtjenester

Der er primært to typer webtjenester:

1. SOAP webtjenester.
2. RESTful webtjenester.

For at en webtjeneste kan være fuldt funktionel, er der visse komponenter, der skal være på plads. Disse komponenter skal være til stede uanset hvilket udviklingssprog der bruges til programmering af webtjenesten. Lad os se nærmere på disse komponenter.

SOAP (Simple Object Access Protocol)

SOAP er kendt som en transportuafhængig meddelelsesprotokol. SOAP er baseret på overførsel af XML-data som SOAP-meddelelser. Hver meddelelse har noget, der kaldes et XML-dokument. Kun strukturen af ​​XML-dokumentet følger et specifikt mønster, men ikke indholdet. Det bedste ved webtjenester og SOAP er, at det hele sendes via HTTP, som er standardwebprotokollen.

Her er hvad en SOAP-besked består af:

• Hvert SOAP-dokument skal have et rodelement kendt som element. Rodelementet er det første element i et XML-dokument.
• "Konvolutten" er til gengæld delt i 2 dele. Den første er overskriften, og den næste er kroppen.
• Headeren indeholder routingdataene, som grundlæggende er den information, der fortæller XML-dokumentet, hvilken klient det skal sendes til.
• Brødteksten vil indeholde selve beskeden.

Diagrammet nedenfor viser et simpelt eksempel på kommunikation via SOAP.

Vi vil diskutere SOAP i detaljer i dette tutorial.

WSDL (Web Services Descriptionsprog)

En webtjeneste kan ikke bruges, hvis den ikke kan findes. Klienten, der kalder webtjenesten, skal vide, hvor webtjenesten rent faktisk befinder sig.

For det andet skal klientapplikationen vide, hvad webtjenesten rent faktisk gør, så den kan kalde den rigtige webtjeneste. Dette gøres ved hjælp af WSDL'en, kendt som Web Services. Description-sprog. WSDL-filen er igen en XML-baseret fil, der grundlæggende fortæller klientapplikationen, hvad webtjenesten gør. Ved at bruge WSDL-dokumentet vil klientapplikationen være i stand til at forstå, hvor webtjenesten er placeret, og hvordan den kan bruges.

Eksempel på webservice

Et webserviceeksempel på en WSDL-fil er givet nedenfor.

<definitions>
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>

   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>

         <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

De vigtige aspekter at bemærke om ovenstående WSDL-erklæringseksempler på webtjenester er som følger:

1. – Meddelelsesparameteren i WSDL-definitionen bruges til at definere de forskellige dataelementer for hver handling, der udføres af webtjenesten. Så i ovenstående webtjenesteeksempel har vi to beskeder, der kan udveksles mellem webtjenesten og klientapplikationen: den ene er "TutorialRequest", og den anden er handlingen "TutorialResponse". TutorialRequest indeholder et element kaldet "TutorialID", som er af typen streng. Tilsvarende indeholder TutorialResponse-handlingen et element kaldet "TutorialName", som også er en type streng.
2. – Dette beskriver faktisk den handling, som kan udføres af webtjenesten, som i vores tilfælde kaldes Tutorial. Denne handling kan tage imod 2 beskeder: den ene er en inputbesked, og den anden er outputbeskeden.
3. – Dette element indeholder den protokol, der bruges. Så i vores tilfælde definerer vi den til at bruge HTTP (http://schemas.xmlsoap.org/soap/http). Vi specificerer også andre detaljer for operationens brødtekst, såsom navnerummet og om meddelelsen skal kodes.

Vi vil diskutere "WSDL" i detaljer i dette tutorial.

Universal Description, opdagelse og integration (UDDI)

UDDI er en standard til at beskrive, publicere og opdage de webtjenester, der leveres af en bestemt tjenesteudbyder. Det giver en specifikation, som hjælper med at hoste oplysningerne på webtjenester.

Nu diskuterede vi i det forrige emne om WSDL, og hvordan det indeholder information om, hvad webtjenesten rent faktisk gør. Men hvordan kan en klientapplikation finde en WSDL-fil for at forstå de forskellige operationer, der tilbydes af en webtjeneste? Så UDDI er svaret på dette og giver et lager, hvorpå WSDL-filer kan hostes. Så klientapplikationen vil have fuld adgang til UDDI, der fungerer som en database, der indeholder alle WSDL-filerne.

Ligesom en telefonbog indeholder navn, adresse og telefonnummer på en bestemt person, vil UDDI-registret indeholde de relevante oplysninger til webtjenesten., så en klientapplikation ved, hvor den kan findes.

Fordele ved webtjenester

Vi forstår allerede, hvorfor webtjenester opstod i første omgang, hvilket var for at levere en platform, der kunne give forskellige applikationer mulighed for at kommunikere med hinanden. Men lad os se på listen over fordele ved webtjenester for at forstå, hvorfor det er vigtigt at bruge webtjenester.

1. Eksponering af forretningsfunktionalitet på netværket – En webtjeneste er en enhed af administreret kode, der leverer en form for funktionalitet til klientapplikationer eller slutbrugere. Denne funktionalitet kan kaldes via HTTP-protokollen, hvilket betyder, at den også kan kaldes via internettet. Nu om dage er alle applikationer på internettet, hvilket gør formålet med webtjenester mere nyttigt. Det betyder, at webtjenesten kan være hvor som helst på internettet og levere den nødvendige funktionalitet efter behov.
2. Interoperabilitet mellem applikationer – Webtjenester tillader forskellige applikationer at kommunikere med hinanden og dele data og tjenester indbyrdes. Alle typer applikationer kan kommunikere med hinanden. Så i stedet for at skrive specifik kode, som kun kan forstås af specifikke applikationer, kan man nu skrive generisk kode, der kan forstås af alle applikationer.
3. En standardiseret protokol, som alle forstår – Webtjenester bruger en standardiseret brancheprotokol til kommunikationen. Alle fire lag (servicetransport, XML-beskeder, service Description- og Service Discovery-lag) bruger veldefinerede protokoller i webservices-protokolstakken.
4. Reduktion i omkostninger til kommunikation – Webtjenester bruger SOAP over HTTP-protokol, så du kan bruge dit eksisterende lavprisinternet til at implementere webtjenester.

Web Services Architecture

Ethvert framework har brug for en eller anden form for arkitektur for at sikre, at hele frameworket fungerer som ønsket. Tilsvarende gælder det i webtjenester, at Web Services Architecture består af tre forskellige roller som angivet nedenfor:

1. Provider – Udbyderen opretter webtjenesten og stiller den til rådighed for klientapplikationer, der ønsker at bruge den.
2. Anmoder – En anmoder er intet andet end klientapplikationen, der skal kontakte en webservice. Klientapplikationen kan være en .Net, Java, eller enhver anden sprogbaseret applikation, der søger efter en eller anden form for funktionalitet via en webtjeneste.
3. Broker – Brokeren er intet andet end den applikation, der giver adgang til UDDI. UDDI, som diskuteret i det tidligere emne, gør det muligt for klientapplikationen at finde webtjenesten.

Diagrammet nedenfor viser, hvordan tjenesteudbyderen, tjenesteanmoderen og tjenesteregistret interagerer med hinanden.

1. Udgiv – En udbyder informerer mægleren (serviceregisteret) om webtjenestens eksistens ved at bruge mæglerens publiceringsgrænseflade for at gøre tjenesten tilgængelig for klienter.
2. Finde – Anmoderen konsulterer mægleren for at finde en offentliggjort webtjeneste.
3. Binde – Med de oplysninger, der er indhentet fra mægleren (tjenesteregistret) om webtjenesten, kan anmoderen binde eller påkalde webtjenesten.

Webtjenestens egenskaber

Webtjenester har følgende særlige adfærdsmæssige egenskaber:

1. De er XML-baserede – Webtjenester bruger XML til at repræsentere dataene på repræsentations- og datatransportlagene. Brug af XML eliminerer enhver afhængighed af netværk, operativsystem eller platform, da XML er det fælles sprog, der forstås af alle.
2. Løst forbundet – Løst koblet betyder, at klienten og webservicen ikke er bundet til hinanden, hvilket betyder, at selvom webservicen ændrer sig over tid, bør den ikke ændre den måde, klienten kalder webservicen på. Vedtagelse af en løst koblet arkitektur har en tendens til at gøre softwaresystemer mere håndterbare og tillader enklere integration mellem forskellige systemer.
3. Synchronous eller asynkron funktionalitet - Synchronicity henviser til klientens binding til udførelsen af ​​tjenesten. I synkrone operationer vil klienten faktisk vente på, at webtjenesten fuldfører en operation. Et eksempel på dette er sandsynligvis et scenarie, hvor en databaselæse- og skriveoperation udføres. Hvis data læses fra én database og efterfølgende skrives til en anden, så skal operationerne udføres på en sekventiel måde. Asynkrone operationer giver en klient mulighed for at påkalde en tjeneste og derefter udføre andre funktioner parallelt. Dette er en af ​​de almindelige og sandsynligvis mest foretrukne teknikker til at sikre, at andre tjenester ikke stoppes, når en bestemt operation udføres.
4. Mulighed for at understøtte Remote Procedure Calls (RPC'er) – Webtjenester gør det muligt for klienter at påberåbe sig procedurer, funktioner og metoder på fjernobjekter ved hjælp af en XML-baseret protokol. Fjernprocedurer afslører input- og outputparametre, som en webservice skal understøtte.
5. Understøtter dokumentudveksling – En af de vigtigste fordele ved XML er dens generiske måde at repræsentere ikke kun data på, men også komplekse dokumenter. Disse dokumenter kan være så enkle som at repræsentere en aktuel adresse, eller de kan være lige så komplekse som at repræsentere en hel bog.

Ofte Stillede Spørgsmål