Oversigt<\/b>
\nKomponentbaseret programmering er blevet mere popul\u00e6rt end nogensinde. Der bliver n\u00e6sten ikke bygget et program i dag, som ikke involverer komponenter i en eller anden form, som regel fra forskellige leverand\u00f8rer. Efterh\u00e5nden som programmerne er blevet mere sofistikerede, er behovet for at udnytte komponenter, der er distribueret p\u00e5 eksterne maskiner, ogs\u00e5 vokset.<\/p>\n
<\/p>\n
Et eksempel p\u00e5 en komponentbaseret applikation er en end-to-end e-handelsl\u00f8sning. En e-handelsapplikation, der ligger p\u00e5 en webfarm, skal sende ordrer til en back-end Enterprise Resource Planning (ERP)-applikation. I mange tilf\u00e6lde ligger ERP-applikationen p\u00e5 en anden hardware og k\u00f8rer m\u00e5ske p\u00e5 et andet operativsystem.<\/p>\n
Microsofts Distributed Component Object Model (DCOM), en infrastruktur for distribuerede objekter, der g\u00f8r det muligt for et program at kalde Component Object Model (COM)-komponenter, der er installeret p\u00e5 en anden server, er blevet overf\u00f8rt til en r\u00e6kke ikke-Windows-platforme. Men DCOM har aldrig vundet bred accept p\u00e5 disse platforme, s\u00e5 det bruges sj\u00e6ldent til at lette kommunikationen mellem Windows- og ikke-Windows-computere. ERP-softwareleverand\u00f8rer skaber ofte komponenter til Windows-platformen, som kommunikerer med back-end-systemet via en propriet\u00e6r protokol.<\/p>\n
Nogle af de tjenester, som en e-handelsapplikation benytter sig af, ligger m\u00e5ske slet ikke i datacentret. Hvis e-handelsapplikationen f.eks. accepterer kreditkortbetaling for varer, som kunden har k\u00f8bt, skal den bruge den handlende banks tjenester til at behandle kundens kreditkortoplysninger. Men i praksis er DCOM og besl\u00e6gtede teknologier som CORBA og Java RMI begr\u00e6nset til applikationer og komponenter, der er installeret i virksomhedens datacenter. To prim\u00e6re \u00e5rsager til dette er, at disse teknologier som standard anvender propriet\u00e6re protokoller, og at disse protokoller i sagens natur er forbindelsesorienterede.<\/p>\n
Klienter, der kommunikerer med serveren via internettet, st\u00e5r over for mange potentielle barrierer for at kommunikere med serveren. Sikkerhedsbevidste netv\u00e6rksadministratorer over hele verden har implementeret virksomhedsroutere og firewalls for at afvise praktisk talt enhver form for kommunikation over internettet. Det kr\u00e6ver ofte en Guds handling at f\u00e5 en netv\u00e6rksadministrator til at \u00e5bne porte ud over det absolutte minimum.<\/p>\n
Hvis du er heldig nok til at f\u00e5 en netv\u00e6rksadministrator til at \u00e5bne de relevante porte til at underst\u00f8tte din tjeneste, er der gode chancer for, at dine klienter ikke er lige s\u00e5 heldige. Derfor er propriet\u00e6re protokoller som dem, der bruges af DCOM, CORBA og Java RMI, ikke praktiske i internetscenarier.<\/p>\n
Det andet problem med disse teknologier er som sagt, at de i sagens natur er forbindelsesorienterede og derfor ikke kan h\u00e5ndtere netv\u00e6rksafbrydelser p\u00e5 en elegant m\u00e5de. Fordi internettet ikke er under din direkte kontrol, kan du ikke g\u00f8re nogen antagelser om forbindelsens kvalitet eller p\u00e5lidelighed. Hvis der opst\u00e5r en netv\u00e6rksafbrydelse, kan det n\u00e6ste opkald, klienten foretager til serveren, mislykkes.<\/p>\n
Den forbindelsesorienterede karakter af disse teknologier g\u00f8r det ogs\u00e5 udfordrende at opbygge de belastningsbalancerede infrastrukturer, der er n\u00f8dvendige for at opn\u00e5 h\u00f8j skalerbarhed. N\u00e5r forbindelsen mellem klienten og serveren er afbrudt, kan man ikke bare sende den n\u00e6ste anmodning videre til en anden server.<\/p>\n
Udviklere har fors\u00f8gt at overvinde disse begr\u00e6nsninger ved at udnytte en model, der hedder tilstandsl\u00f8s <\/i>Programmering<\/i>, men de har haft begr\u00e6nset succes, fordi teknologierne er ret tunge og g\u00f8r det dyrt at genoprette en forbindelse med et fjerntliggende objekt.<\/p>\n
Da behandlingen af en kundes kreditkort udf\u00f8res af en fjernserver p\u00e5 internettet, er DCOM ikke ideel til at lette kommunikationen mellem e-handelsklienten og kreditkortsbehandlingsserveren. Ligesom i en ERP-l\u00f8sning installeres der ofte en tredjepartskomponent i klientens datacenter (i dette tilf\u00e6lde af udbyderen af kreditkortbehandlingen). Denne komponent fungerer som lidt mere end en proxy, der letter kommunikationen mellem e-handelssoftwaren og den handlende bank via en propriet\u00e6r protokol.<\/p>\n
Kan du se et m\u00f8nster her? P\u00e5 grund af de eksisterende teknologiers begr\u00e6nsninger, n\u00e5r det g\u00e6lder kommunikation mellem computersystemer, har softwareleverand\u00f8rerne ofte v\u00e6ret n\u00f8dt til at bygge deres egen infrastruktur. Det betyder, at ressourcer, der kunne have v\u00e6ret brugt til at tilf\u00f8je forbedret funktionalitet til ERP-systemet eller kreditkortsystemet, i stedet er blevet brugt til at skrive propriet\u00e6re netv\u00e6rksprotokoller.<\/p>\n
I et fors\u00f8g p\u00e5 bedre at underst\u00f8tte s\u00e5danne internetscenarier valgte Microsoft oprindeligt at udvide sine eksisterende teknologier, herunder COM Internet Services (CIS), som g\u00f8r det muligt at etablere en DCOM-forbindelse mellem klienten og fjernkomponenten via port 80. Af forskellige \u00e5rsager blev CIS ikke bredt accepteret.<\/p>\n
Det blev klart, at der var brug for en ny tilgang. S\u00e5 Microsoft besluttede at l\u00f8se problemet nedefra og op. Lad os se p\u00e5 nogle af de krav, l\u00f8sningen skulle opfylde for at blive en succes.<\/p>\n
I betragtning af titlen p\u00e5 denne bog b\u00f8r det ikke komme som nogen overraskelse, at den l\u00f8sning, Microsoft skabte, er kendt som Webtjenester<\/i>. En webtjeneste udstiller en gr\u00e6nseflade til at p\u00e5kalde en bestemt aktivitet p\u00e5 vegne af klienten. En klient kan f\u00e5 adgang til webservicen gennem brug af internetstandarder.<\/p>\n
Byggeklodser til webservices<\/b>
\nF\u00f8lgende grafik viser de centrale byggesten, der er n\u00f8dvendige for at muligg\u00f8re fjernkommunikation mellem to applikationer.<\/p>\n
Lad os diskutere form\u00e5let med hver af disse byggesten. Da mange l\u00e6sere er fortrolige med DCOM, vil jeg ogs\u00e5 n\u00e6vne DCOM-\u00e6kvivalenten for hver byggesten.<\/p>\n
Uden en standardiseret m\u00e5de at formatere meddelelserne p\u00e5 er det n\u00e6sten umuligt at udvikle et v\u00e6rkt\u00f8jss\u00e6t, der abstraherer udvikleren fra de underliggende protokoller. Ved at skabe et abstraktionslag mellem udvikleren og de underliggende protokoller kan udvikleren fokusere mere p\u00e5 det aktuelle forretningsproblem og mindre p\u00e5 den infrastruktur, der kr\u00e6ves for at implementere l\u00f8sningen.<\/p>\n
Beslutninger om design af webtjenester<\/b><\/p>\n
Lad os diskutere nogle af de designbeslutninger, der ligger bag disse byggesten til webtjenester.<\/p>\n
Valg af transportprotokoller<\/b><\/p>\n
Det f\u00f8rste skridt var at fastl\u00e6gge, hvordan klienten og serveren skulle kommunikere med hinanden. Klienten og serveren kan befinde sig p\u00e5 det samme LAN, men klienten kan potentielt ogs\u00e5 kommunikere med serveren via internettet. Derfor skal transportprotokollen v\u00e6re lige s\u00e5 velegnet til LAN-milj\u00f8er som til internettet.<\/p>\n
Som jeg n\u00e6vnte tidligere, er teknologier som DCOM, CORBA og Java RMI d\u00e5rligt egnet til at underst\u00f8tte kommunikation mellem klienten og serveren via internettet. Protokoller som Hypertext Transfer Protocol (HTTP) og Simple Mail Transfer Protocol (SMTP) er gennempr\u00f8vede internetprotokoller. HTTP definerer et anmodnings-\/svar-kommunikationsm\u00f8nster til at sende en anmodning og modtage et tilh\u00f8rende svar. SMTP definerer en routbar meddelelsesprotokol til asynkron kommunikation. Lad os se n\u00e6rmere p\u00e5, hvorfor HTTP og SMTP er velegnede til internettet.<\/p>\n
HTTP-baserede webapplikationer er i sagens natur stateless. De er ikke afh\u00e6ngige af en kontinuerlig forbindelse mellem klienten og serveren. Dette g\u00f8r HTTP til en ideel protokol til konfigurationer med h\u00f8j tilg\u00e6ngelighed, s\u00e5som firewalls. Hvis den server, der behandlede klientens oprindelige anmodning, bliver utilg\u00e6ngelig, kan efterf\u00f8lgende anmodninger automatisk omdirigeres til en anden server, uden at klienten bem\u00e6rker det eller t\u00e6nker over det.<\/p>\n
N\u00e6sten alle virksomheder har en infrastruktur, der underst\u00f8tter SMTP. SMTP er velegnet til asynkron kommunikation. Hvis tjenesten afbrydes, s\u00f8rger e-mail-infrastrukturen automatisk for at gentage fors\u00f8gene. I mods\u00e6tning til HTTP kan man videresende SMTP-beskeder til en lokal mailserver, som vil fors\u00f8ge at levere e-mailen p\u00e5 ens vegne.<\/p>\n
Den anden v\u00e6sentlige fordel ved b\u00e5de HTTP og SMTP er deres udbredelse. Medarbejderne er kommet til at stole p\u00e5 b\u00e5de e-mail og deres webbrowsere, og netv\u00e6rksadministratorer f\u00f8ler sig meget trygge ved at underst\u00f8tte disse tjenester. Teknologier som Network Address Translation (NAT) og proxyservere giver mulighed for at f\u00e5 adgang til internettet via HTTP fra ellers isolerede virksomheds-LAN'er. Administratorer vil ofte stille en SMTP-server til r\u00e5dighed, der befinder sig inden for firewallen. Beskeder, der sendes til denne server, vil derefter blive videresendt til deres endelige destination via internettet.<\/p>\n
N\u00e5r det drejer sig om software til kreditkortbehandling, er der behov for et \u00f8jeblikkeligt svar fra forretningsbanken for at afg\u00f8re, om ordren skal sendes videre til ERP-systemet. HTTP, med sit m\u00f8nster af anmodnings- og svarmeddelelser, er velegnet til denne opgave.<\/p>\n
De fleste ERP-softwarepakker er ikke i stand til at h\u00e5ndtere store ordrem\u00e6ngder, som potentielt kan stamme fra e-handelsapplikationen. Desuden er det ikke absolut n\u00f8dvendigt, at ordrerne sendes til ERP-systemet i realtid. Derfor kan SMTP udnyttes til at s\u00e6tte ordrer i k\u00f8, s\u00e5 de kan behandles sekventielt af ERP-systemet.<\/p>\n
Hvis ERP-systemet underst\u00f8tter distribuerede transaktioner, er en anden mulighed at benytte Microsoft Message Queue Server (MSMQ). S\u00e5 l\u00e6nge e-handelsapplikationen og ERP-systemet befinder sig p\u00e5 det samme LAN, er forbindelsen via protokoller, der ikke er baseret p\u00e5 internettet, ikke noget stort problem. Fordelen ved MSMQ i forhold til SMTP er, at meddelelser kan placeres i og fjernes fra k\u00f8en inden for rammerne af en transaktion. Hvis et fors\u00f8g p\u00e5 at behandle en meddelelse, der er hentet fra k\u00f8en, mislykkes, placeres meddelelsen automatisk tilbage i k\u00f8en, n\u00e5r transaktionen afbrydes.<\/p>\n
Valg af kodningsskema<\/b><\/p>\n
HTTP og SMTP giver mulighed for at sende data mellem klienten og serveren. Ingen af dem angiver dog, hvordan dataene i meddelelsens br\u00f8dtekst skal kodes. Microsoft havde brug for en standardiseret, platformsuafh\u00e6ngig metode til at kode de data, der udveksles mellem klienten og serveren.<\/p>\n
Da m\u00e5let var at udnytte internetbaserede protokoller, var Extensible Markup Language (XML) det oplagte valg. XML byder p\u00e5 mange fordele, herunder platformsuafh\u00e6ngig underst\u00f8ttelse, et f\u00e6lles typesystem og underst\u00f8ttelse af tegns\u00e6t, der er standard i branchen.<\/p>\n
Bin\u00e6re kodningssystemer, s\u00e5som dem der anvendes af DCOM, CORBA og Java RMI, skal tage h\u00f8jde for kompatibilitetsproblemer mellem forskellige hardwareplatforme. Forskellige hardwareplatforme har for eksempel forskellige interne bin\u00e6re repr\u00e6sentationer af multibyte-tal. Intel-platforme ordner byterne i et multibyte-tal efter little-endian-konventionen, mens mange RISC-processorer ordner byterne i et multibyte-tal efter big-endian-konventionen.<\/p>\n
XML undg\u00e5r problemer med bin\u00e6r kodning, da det anvender et tekstbaseret kodningssystem, der bygger p\u00e5 standardtegns\u00e6t. Desuden kan visse transportprotokoller, s\u00e5som SMTP, kun indeholde tekstbaserede meddelelser.<\/p>\n
Bin\u00e6re kodningsmetoder, s\u00e5som dem der anvendes af DCOM og CORBA, er besv\u00e6rlige og kr\u00e6ver en underst\u00f8ttende infrastruktur for at sk\u00e6rme udvikleren fra detaljerne. XML er langt mere letv\u00e6gtig og nemmere at h\u00e5ndtere, fordi det kan oprettes og bruges ved hj\u00e6lp af standardteknikker til tekstanalyse.<\/p>\n
Derudover findes der en r\u00e6kke forskellige XML-parsere, der yderligere forenkler oprettelsen og brugen af XML-dokumenter p\u00e5 stort set alle moderne platforme. XML er letv\u00e6gtigt og har fremragende v\u00e6rkt\u00f8jsunderst\u00f8ttelse, s\u00e5 XML-kodning giver en utrolig bred r\u00e6kkevidde, da stort set enhver klient p\u00e5 enhver platform kan kommunikere med din webservice.<\/p>\n
Valg af formateringsstandard<\/b><\/p>\n
Det er ofte n\u00f8dvendigt at medtage yderligere metadata sammen med meddelelsens hovedtekst. Man kan f.eks. \u00f8nske at medtage oplysninger om, hvilke typer tjenester en webservice skal levere for at im\u00f8dekomme ens anmodning, s\u00e5som deltagelse i en transaktion eller routingoplysninger. XML indeholder ingen mekanisme til at skelne mellem meddelelsens hovedtekst og de tilknyttede data.<\/p>\n
Transportprotokoller som HTTP tilbyder en udvidelig mekanisme til header-data, men visse data knyttet til meddelelsen er muligvis ikke specifikke for transportprotokollen. For eksempel kan klienten sende en meddelelse, der skal videresendes til flere destinationer, eventuelt via forskellige transportprotokoller. Hvis routingoplysningerne blev placeret i en HTTP-header, ville de skulle overs\u00e6ttes, f\u00f8r de blev sendt til den n\u00e6ste mellemstation via en anden transportprotokol, s\u00e5som SMTP. Da routingoplysningerne er specifikke for meddelelsen og ikke for transportprotokollen, b\u00f8r de v\u00e6re en del af selve meddelelsen.<\/p>\n
Simple Object Access Protocol (SOAP) tilbyder en protokoluafh\u00e6ngig metode til at knytte headeroplysninger til meddelelsens br\u00f8dtekst. Hver SOAP-meddelelse skal definere en konvolut. Konvolutten har en br\u00f8dtekst, der indeholder meddelelsens nyttelast, og en header, der kan indeholde metadata knyttet til meddelelsen.<\/p>\n
SOAP stiller ingen krav til, hvordan meddelelsens indhold skal formateres. Dette kan v\u00e6re et problem, da det uden en ensartet m\u00e5de at kode dataene p\u00e5 er vanskeligt at udvikle et v\u00e6rkt\u00f8jss\u00e6t, der abstraherer brugeren fra de underliggende protokoller. Du risikerer at skulle bruge en del tid p\u00e5 at s\u00e6tte dig ind i webservicens gr\u00e6nseflade i stedet for at l\u00f8se det aktuelle forretningsproblem.<\/p>\n
Der var behov for en standardmetode til formatering af en RPC-meddelelse (Remote Procedure Call) og kodning af dens parameterliste. Det er netop det, afsnit 7 i SOAP-specifikationen omhandler. Her beskrives en standardnavngivningskonvention og en standardkodningsmetode for procedureorienterede meddelelser.<\/p>\n
Da SOAP tilbyder et standardformat til serialisering af data til en XML-meddelelse, kan platforme som ASP.NET og Remoting h\u00e5ndtere detaljerne for dig.<\/p>\n
Valg af beskrivelsesmekanismer<\/b><\/p>\n
SOAP tilbyder en standardmetode til formatering af meddelelser, der udveksles mellem webservicen og klienten. Klienten har dog brug for yderligere oplysninger for at kunne serialisere anmodningen korrekt og fortolke svaret. XML-skema giver mulighed for at oprette skemaer, der kan bruges til at beskrive indholdet af en meddelelse.<\/p>\n
XML Schema indeholder et s\u00e6t indbyggede datatyper, der kan bruges til at beskrive indholdet af en besked. Du kan ogs\u00e5 oprette dine egne datatyper. For eksempel kan handelsbanken oprette en kompleks datatype til at beskrive indholdet og strukturen i br\u00f8dteksten af en besked, der bruges til at indsende en anmodning om kreditkortbetaling.<\/p>\n
Et skema indeholder en r\u00e6kke definitioner af datatyper og elementer. En webservice bruger skemaet ikke kun til at angive, hvilken type data der forventes at v\u00e6re i en besked, men ogs\u00e5 til at validere indg\u00e5ende og udg\u00e5ende beskeder.<\/p>\n
Et skema alene giver dog ikke tilstr\u00e6kkelige oplysninger til effektivt at beskrive en webservice. Skemaet beskriver ikke meddelelsesm\u00f8nstrene mellem klienten og serveren. En klient skal for eksempel vide, om den kan forvente et svar, n\u00e5r en ordre indsendes til ERP-systemet. En klient skal ogs\u00e5 vide, via hvilken transportprotokol webservicen forventer at modtage anmodninger. Endelig skal klienten kende adressen, hvor webservicen kan n\u00e5s.<\/p>\n
Disse oplysninger leveres via et WSDL-dokument (Web Services Description Language). WSDL er et XML-dokument, der indeholder en fuldst\u00e6ndig beskrivelse af en bestemt webservice. V\u00e6rkt\u00f8jer som f.eks. ASP.NET WSDL.exe og Remoting SOAPSUDS.exe kan l\u00e6se WSDL-dokumenter og automatisk oprette proxyer til udvikleren.<\/p>\n
Ligesom alle andre komponenter, der bruges til at udvikle software, b\u00f8r en webservice ogs\u00e5 ledsages af skriftlig dokumentation til de udviklere, der programmerer med udgangspunkt i webservicen. Dokumentationen b\u00f8r beskrive, hvad webservicen g\u00f8r, hvilke gr\u00e6nseflader den stiller til r\u00e5dighed, samt give nogle eksempler p\u00e5, hvordan den bruges. God dokumentation er is\u00e6r vigtig, hvis webservicen stilles til r\u00e5dighed for klienter via internettet.<\/p>\n
Valg af opdagelsesmekanismer<\/b><\/p>\n
N\u00e5r du har udviklet og dokumenteret en webservice, hvordan kan potentielle kunder s\u00e5 finde den? Hvis webservicen er beregnet til at blive brugt af et medlem af dit udviklingsteam, kan du n\u00f8jes med en ret uformel fremgangsm\u00e5de, f.eks. ved at dele URL\u2019en til WSDL-dokumentet med din kollega et par skriveborde l\u00e6ngere nede. Men n\u00e5r potentielle kunder befinder sig p\u00e5 internettet, er det en helt anden sag at markedsf\u00f8re din webservice effektivt.<\/p>\n
Der er brug for en f\u00e6lles metode til at annoncere webtjenester. Universal Description, Discovery, and Integration (UDDI) tilbyder netop en s\u00e5dan mekanisme. UDDI er en centraliseret katalogtjeneste, der er baseret p\u00e5 en industristandard, og som kan bruges til at annoncere og finde webtjenester. UDDI giver brugerne mulighed for at s\u00f8ge efter webtjenester ved hj\u00e6lp af en r\u00e6kke s\u00f8gekriterier, herunder firmanavn, kategori og type webtjeneste.<\/p>\n
Webtjenester kan ogs\u00e5 annonceres via DISCO, et propriet\u00e6rt XML-dokumentformat defineret af Microsoft, som g\u00f8r det muligt for websteder at annoncere de tjenester, de stiller til r\u00e5dighed. DISCO definerer en enkel protokol, der muligg\u00f8r en hyperlink-lignende metode til at finde ressourcer. Den prim\u00e6re bruger af DISCO er Microsoft Visual Studio.NET. En udvikler kan m\u00e5lrette mod en bestemt webserver og navigere gennem de forskellige webservices, som serveren stiller til r\u00e5dighed.<\/p>\n
Hvad mangler der ved webservices?<\/b><\/p>\n
Du har m\u00e5ske bem\u00e6rket, at nogle centrale elementer i en infrastruktur med distribuerede komponenter ikke er defineret af webservices. To af de mest i\u00f8jnefaldende mangler er et veldefineret API til oprettelse og brug af webservices samt et s\u00e6t komponenttjenester, s\u00e5som underst\u00f8ttelse af distribuerede transaktioner. Lad os se n\u00e6rmere p\u00e5 hver af disse manglende elementer.<\/p>\n
For at sikre, at webservices er uafh\u00e6ngige af programmeringssprog, har Microsoft overladt det til de enkelte softwareudbydere at knytte underst\u00f8ttelsen af webservices til en bestemt platform. Senere i bogen vil jeg gennemg\u00e5 to implementeringer af webservices til .NET-platformen, nemlig ASP.NET og Remoting.<\/p>\n
Nogle tjenester, s\u00e5som underst\u00f8ttelse af distribuerede transaktioner, kan indf\u00f8res senere, efterh\u00e5nden som teknologien modnes. Andre, s\u00e5som objektpooling og muligvis styring af objekters levetid, kan betragtes som en implementeringsdetalje i platformen. For eksempel definerer Remoting udvidelser, der giver mulighed for styring af objekters levetid, og Microsoft Component Services underst\u00f8tter objektpooling.<\/p>\n
Resum\u00e9<\/b><\/p>\n
Komponentbaseret programmering har vist sig at v\u00e6re en stor fordel for udviklernes produktivitet, men visse tjenester kan ikke indkapsles i en komponent, der befinder sig i klientens datacenter. \u00c6ldre teknologier som DCOM, CORBA og Java RMI er uegnede til at give klienter adgang til tjenester via internettet, s\u00e5 Microsoft fandt det n\u00f8dvendigt at starte fra bunden og udvikle en industristandard for adgang til fjernbetjente tjenester.<\/p>\n
Webtjenester<\/i> er et samlebegreb, der beskriver en samling af branchestandardprotokoller og -tjenester, der anvendes til at sikre et grundl\u00e6ggende niveau af interoperabilitet mellem applikationer. Den opbakning, som webtjenester har f\u00e5et fra branchen, er uden fortilf\u00e6lde. Aldrig f\u00f8r har s\u00e5 mange f\u00f8rende teknologivirksomheder g\u00e5et sammen om at st\u00f8tte en standard, der fremmer interoperabilitet mellem applikationer, uanset hvilken platform de k\u00f8rer p\u00e5.<\/p>\n
En af de faktorer, der bidrager til webservicernes succes, er, at de bygger p\u00e5 eksisterende internetstandarder s\u00e5som XML og HTTP. Det betyder, at ethvert system, der kan fortolke tekst og kommunikere via en standard internettransportprotokol, kan kommunikere med en webservice. Virksomhederne kan desuden udnytte de investeringer, de allerede har foretaget i disse teknologier.<\/p>","protected":false},"excerpt":{"rendered":"
Overview Component-based programming has become more popular than ever. Hardly an application is built today that does not involve leveraging components in some form, usually from different vendors. As applications have grown more sophisticated, the need to leverage components distributed on remote machines has also grown.<\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-231","post","type-post","status-publish","format-standard","hentry","category-smtp-servers"],"_links":{"self":[{"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/da\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}