Overzicht
Componentgebaseerd programmeren is populairder dan ooit. Er wordt tegenwoordig bijna geen applicatie meer gebouwd zonder gebruik te maken van componenten in een of andere vorm, meestal van verschillende leveranciers. Naarmate applicaties geavanceerder zijn geworden, is ook de behoefte gegroeid om gebruik te maken van componenten die gedistribueerd worden op externe machines.
Een voorbeeld van een componentgebaseerde toepassing is een end-to-end e-commerceoplossing. Een e-commerce toepassing die zich op een webfarm bevindt, moet bestellingen doorsturen naar een back-end Enterprise Resource Planning (ERP) toepassing. In veel gevallen bevindt de ERP-applicatie zich op andere hardware en draait misschien op een ander besturingssysteem.
Het Microsoft Distributed Component Object Model (DCOM), een gedistribueerde objectinfrastructuur waarmee een toepassing Component Object Model (COM) componenten kan aanroepen die geïnstalleerd zijn op een andere server, is geport naar een aantal niet-Windows platformen. Maar DCOM is nooit breed geaccepteerd op deze platformen, dus het wordt zelden gebruikt om de communicatie tussen Windows en niet-Windows computers te vergemakkelijken. ERP softwareleveranciers maken vaak componenten voor het Windows platform die communiceren met het back-end systeem via een eigen protocol.
Sommige diensten die door een e-commerce applicatie worden gebruikt, bevinden zich misschien helemaal niet in het datacenter. Als de e-commerce applicatie bijvoorbeeld creditcardbetalingen accepteert voor goederen die door de klant zijn gekocht, moet het de diensten van de zakenbank gebruiken om de creditcardgegevens van de klant te verwerken. Maar voor alle praktische doeleinden zijn DCOM en aanverwante technologieën zoals CORBA en Java RMI beperkt tot applicaties en componenten die geïnstalleerd zijn in het datacenter van het bedrijf. De twee belangrijkste redenen hiervoor zijn dat deze technologieën standaard gebruik maken van propriëtaire protocollen en dat deze protocollen inherent verbindingsgericht zijn.
Clients die via het Internet met de server communiceren worden geconfronteerd met talloze potentiële barrières om met de server te communiceren. Beveiligingsbewuste netwerkbeheerders over de hele wereld hebben bedrijfsrouters en firewalls geïmplementeerd om praktisch elk type communicatie over het Internet te verhinderen. Er is vaak een daad van God voor nodig om een netwerkbeheerder zover te krijgen dat hij poorten opent die verder gaan dan het absolute minimum.
Als je het geluk hebt dat een netwerkbeheerder de juiste poorten opent om je dienst te ondersteunen, dan is de kans groot dat je klanten minder geluk hebben. Als gevolg hiervan zijn propriëtaire protocollen zoals die gebruikt worden door DCOM, CORBA en Java RMI niet praktisch voor Internet scenario's.
Het andere probleem, zoals ik al zei, met deze technologieën is dat ze inherent verbindingsgericht zijn en daarom niet netjes kunnen omgaan met netwerkonderbrekingen. Omdat je geen directe controle hebt over het Internet, kun je geen aannames doen over de kwaliteit of betrouwbaarheid van de verbinding. Als er een netwerkonderbreking optreedt, kan de volgende oproep van de client aan de server mislukken.
De verbindingsgerichte aard van deze technologieën maakt het ook een uitdaging om de load-balanced infrastructuren te bouwen die nodig zijn om een hoge schaalbaarheid te bereiken. Als de verbinding tussen de client en de server eenmaal verbroken is, kun je het volgende verzoek niet eenvoudigweg naar een andere server routeren.
Ontwikkelaars hebben geprobeerd deze beperkingen te omzeilen door gebruik te maken van een model genaamd staatloos programmering, maar ze hebben beperkt succes gehad omdat de technologieën vrij zwaar zijn en het duur maakt om een verbinding met een object op afstand opnieuw tot stand te brengen.
Omdat de verwerking van de creditcard van een klant wordt uitgevoerd door een externe server op het internet, is DCOM niet ideaal om de communicatie tussen de e-commerce client en de creditcardverwerkende server te vergemakkelijken. Net als bij een ERP-oplossing wordt er vaak een component van een derde partij geïnstalleerd in het datacenter van de klant (in dit geval door de leverancier van de creditcardverwerkingsoplossing). Deze component dient als weinig meer dan een proxy die de communicatie tussen de e-commerce software en de merchant bank vergemakkelijkt via een propriëtair protocol.
Zie je hier een patroon? Vanwege de beperkingen van bestaande technologieën in het faciliteren van communicatie tussen computersystemen, hebben softwareleveranciers vaak hun toevlucht genomen tot het bouwen van hun eigen infrastructuur. Dit betekent dat middelen die gebruikt hadden kunnen worden om verbeterde functionaliteit toe te voegen aan het ERP-systeem of het creditcardverwerkingssysteem in plaats daarvan zijn besteed aan het schrijven van propriëtaire netwerkprotocollen.
In een poging om dergelijke internetscenario's beter te ondersteunen, koos Microsoft aanvankelijk voor de strategie om zijn bestaande technologieën uit te breiden, waaronder COM Internet Services (CIS), waarmee je een DCOM-verbinding tot stand kunt brengen tussen de client en de component op afstand via poort 80. CIS werd om verschillende redenen niet algemeen aanvaard. Om verschillende redenen werd CIS niet algemeen aanvaard.
Het werd duidelijk dat er een nieuwe aanpak nodig was. Dus besloot Microsoft het probleem van onderaf aan te pakken. Laten we eens kijken naar enkele eisen waaraan de oplossing moest voldoen om succesvol te zijn.
- Interoperabiliteit De service op afstand moet gebruikt kunnen worden door clients op andere platforms.
- Internetvriendelijkheid De oplossing zou goed moeten werken voor het ondersteunen van clients die toegang hebben tot de service op afstand vanaf het internet.
- Sterk getypeerde interfaces Er mag geen onduidelijkheid bestaan over het type gegevens dat wordt verzonden naar en ontvangen van een externe dienst. Verder zouden datatypes gedefinieerd door de remote service redelijk goed moeten overeenkomen met datatypes gedefinieerd door de meeste procedurele programmeertalen.
- Mogelijkheid om gebruik te maken van bestaande internetstandaarden De implementatie van de remote service moet zoveel mogelijk gebruik maken van bestaande internetstandaarden en het opnieuw uitvinden van oplossingen voor problemen die al opgelost zijn vermijden. Een oplossing die gebouwd is op breed geaccepteerde internetstandaarden kan gebruik maken van bestaande toolsets en producten die gemaakt zijn voor de technologie.
- Ondersteuning voor elke taal De oplossing moet niet strak gekoppeld zijn aan een bepaalde programmeertaal. Java RMI is bijvoorbeeld nauw verbonden met de Java taal. Het zou moeilijk zijn om functionaliteit op een Java-object op afstand aan te roepen vanuit Visual Basic of Perl. Een client moet een nieuwe webservice kunnen implementeren of een bestaande webservice kunnen gebruiken, ongeacht de programmeertaal waarin de client is geschreven.
- Ondersteuning voor elke gedistribueerde componenteninfrastructuur De oplossing zou niet strak gekoppeld moeten zijn aan een bepaalde componenteninfrastructuur. In feite zou je niet verplicht moeten zijn om een gedistribueerde objectinfrastructuur aan te schaffen, te installeren of te onderhouden alleen maar om een nieuwe service op afstand te bouwen of een bestaande service te gebruiken. De onderliggende protocollen moeten een basisniveau van communicatie mogelijk maken tussen bestaande gedistribueerde object infrastructuren zoals DCOM en CORBA.
Gezien de titel van dit boek zal het geen verrassing zijn dat de oplossing die Microsoft heeft gemaakt bekend staat als Webservices. Een webservice biedt een interface om een bepaalde activiteit uit te voeren in naam van de klant. Een client heeft toegang tot de webservice via internetstandaarden.
Bouwstenen voor webservices
De volgende afbeelding toont de belangrijkste bouwstenen die nodig zijn om communicatie op afstand tussen twee applicaties mogelijk te maken.
Laten we het doel van elk van deze bouwstenen bespreken. Omdat veel lezers bekend zijn met DCOM, zal ik ook het DCOM-equivalent van elke bouwsteen noemen.
- Ontdekking De clienttoepassing die toegang nodig heeft tot functionaliteit die door een webservice wordt aangeboden, heeft een manier nodig om de locatie van de service op afstand te bepalen. Dit wordt bereikt door een proces dat over het algemeen wordt aangeduid als ontdekking. Ontdekken kan zowel via een gecentraliseerde directory als via meer ad hoc methoden. In DCOM levert de Service Control Manager (SCM) zoekdiensten.
- Beschrijving Zodra het eindpunt voor een bepaalde webservice is bepaald, heeft de client voldoende informatie nodig om er op de juiste manier mee te kunnen communiceren. De beschrijving van een webservice omvat gestructureerde metagegevens over de interface die bedoeld is om te worden geconsumeerd door een clienttoepassing, evenals schriftelijke documentatie over de webservice, inclusief gebruiksvoorbeelden. Een DCOM component stelt gestructureerde metadata over zijn interfaces bloot via een typebibliotheek (typelib). De metagegevens in de typelib van een component worden opgeslagen in een propriëtair binair formaat en zijn toegankelijk via een propriëtaire application programming interface (API).
- Berichtformaat Om gegevens uit te wisselen, moeten een client en een server het eens worden over een gemeenschappelijke manier om de berichten te coderen en te formatteren. Een standaard manier om gegevens te coderen zorgt ervoor dat gegevens die door de client zijn gecodeerd op de juiste manier door de server worden geïnterpreteerd. In DCOM worden berichten tussen een client en een server geformatteerd zoals gedefinieerd door het DCOM Object RPC (ORPC) protocol.
Zonder een standaard manier om de berichten te formatteren, is het ontwikkelen van een toolset om de ontwikkelaar te abstraheren van de onderliggende protocollen bijna onmogelijk. Door een abstractielaag te creëren tussen de ontwikkelaar en de onderliggende protocollen, kan de ontwikkelaar zich meer richten op het bedrijfsprobleem en minder op de infrastructuur die nodig is om de oplossing te implementeren.
- Codering De gegevens die worden verzonden tussen de client en de server moeten worden gecodeerd in de body van het bericht. DCOM gebruikt een binair coderingsschema om de gegevens in de parameters die worden uitgewisseld tussen de client en de server te serialiseren.
- Transport Nadat het bericht is geformatteerd en de gegevens zijn geserialiseerd in de body van het bericht, moet het bericht worden overgedragen tussen de client en de server via een transportprotocol. DCOM ondersteunt een aantal eigen protocollen gebonden aan een aantal netwerkprotocollen zoals TCP, SPX, NetBEUI en NetBIOS over IPX.
Ontwerpbeslissingen voor webservices
Laten we enkele van de ontwerpbeslissingen achter deze bouwstenen voor webservices bespreken.
Transportprotocollen kiezen
De eerste stap was bepalen hoe de client en de server met elkaar zouden communiceren. De client en de server kunnen zich op hetzelfde LAN bevinden, maar de client kan mogelijk via het internet met de server communiceren. Daarom moet het transportprotocol even geschikt zijn voor LAN omgevingen als voor het Internet.
Zoals ik al eerder zei, zijn technologieën als DCOM, CORBA en Java RMI niet geschikt om de communicatie tussen de client en de server over het Internet te ondersteunen. Protocollen als Hypertext Transfer Protocol (HTTP) en Simple Mail Transfer Protocol (SMTP) zijn beproefde internetprotocollen. HTTP definieert een verzoek/antwoord berichtpatroon voor het indienen van een verzoek en het krijgen van een bijbehorend antwoord. SMTP definieert een routeerbaar berichtenprotocol voor asynchrone communicatie. Laten we eens onderzoeken waarom HTTP en SMTP zeer geschikt zijn voor het internet.
Webapplicaties op basis van HTTP zijn inherent stateloos. Ze vertrouwen niet op een continue verbinding tussen de client en de server. Dit maakt HTTP een ideaal protocol voor configuraties met hoge beschikbaarheid zoals firewalls. Als de server die de oorspronkelijke aanvraag van de cliënt heeft afgehandeld onbeschikbaar wordt, kunnen volgende aanvragen automatisch naar een andere server worden gerouteerd zonder dat de cliënt dat weet of er iets om geeft.
Bijna alle bedrijven hebben een infrastructuur die SMTP ondersteunt. SMTP is zeer geschikt voor asynchrone communicatie. Als de service wordt verstoord, zorgt de e-mailinfrastructuur automatisch voor nieuwe pogingen. In tegenstelling tot HTTP kun je SMTP-berichten doorsturen naar een lokale mailserver die zal proberen het mailbericht namens jou af te leveren.
Het andere belangrijke voordeel van zowel HTTP als SMTP is hun alomtegenwoordigheid. Werknemers zijn gaan vertrouwen op zowel e-mail als hun webbrowsers, en netwerkbeheerders hebben een hoge mate van comfort bij het ondersteunen van deze diensten. Technologieën zoals network address translation (NAT) en proxyservers bieden een manier om toegang te krijgen tot het Internet via HTTP vanuit anders geïsoleerde bedrijfs-LAN's. Beheerders stellen vaak een SMTP-server beschikbaar die zich binnen de firewall bevindt. Berichten die naar deze server worden gestuurd, worden dan via het internet naar hun eindbestemming geleid.
In het geval van software voor het verwerken van creditcards is er een onmiddellijk antwoord nodig van de zakenbank om te bepalen of de bestelling moet worden doorgegeven aan het ERP-systeem. HTTP, met zijn request/response berichtpatroon, is zeer geschikt voor deze taak.
De meeste ERP-softwarepakketten zijn niet in staat om grote volumes orders te verwerken die mogelijk vanuit de e-commercetoepassing kunnen worden aangestuurd. Bovendien is het niet noodzakelijk dat de orders in realtime bij het ERP-systeem worden ingediend. Daarom kan SMTP worden gebruikt om orders in een wachtrij te plaatsen, zodat ze serieel kunnen worden verwerkt door het ERP-systeem.
Als het ERP-systeem gedistribueerde transacties ondersteunt, is een andere optie om gebruik te maken van Microsoft Message Queue Server (MSMQ). Zolang de e-commerce applicatie en het ERP-systeem zich binnen hetzelfde LAN bevinden, is connectiviteit via niet-internet protocollen minder een probleem. Het voordeel van MSMQ ten opzichte van SMTP is dat berichten geplaatst en verwijderd kunnen worden uit de wachtrij binnen het bereik van een transactie. Als een poging om een bericht te verwerken dat uit de wachtrij is gehaald mislukt, wordt het bericht automatisch terug in de wachtrij geplaatst wanneer de transactie wordt afgebroken.
Een coderingsschema kiezen
HTTP en SMTP bieden een manier om gegevens te verzenden tussen de client en de server. Geen van beide specificeert echter hoe de gegevens in de body van het bericht moeten worden gecodeerd. Microsoft had een standaard, platformneutrale manier nodig om gegevens te coderen die tussen de client en de server worden uitgewisseld.
Omdat het doel was om gebruik te maken van internetprotocollen, was XML (Extensible Markup Language) de logische keuze. XML biedt veel voordelen, waaronder platformonafhankelijke ondersteuning, een gemeenschappelijk type systeem en ondersteuning voor industriestandaard tekensets.
Binaire coderingsschema's zoals die gebruikt worden door DCOM, CORBA en Java RMI moeten compatibiliteitsproblemen tussen verschillende hardwareplatforms aanpakken. Verschillende hardwareplatforms hebben bijvoorbeeld verschillende interne binaire representaties van multi-byte getallen. Intel-platforms ordenen de bytes van een multi-byte getal volgens de little endian conventie; veel RISC-processors ordenen de bytes van een multi-byte getal volgens de big endian conventie.
XML vermijdt binaire coderingsproblemen omdat het een op tekst gebaseerd coderingsschema gebruikt dat gebruik maakt van standaard tekensets. Bovendien kunnen sommige transportprotocollen, zoals SMTP, alleen op tekst gebaseerde berichten bevatten.
Binaire coderingsmethoden, zoals die door DCOM en CORBA worden gebruikt, zijn omslachtig en vereisen een ondersteunende infrastructuur om de ontwikkelaar te abstraheren van de details. XML is veel lichter en gemakkelijker te hanteren omdat het kan worden gemaakt en geconsumeerd met behulp van standaard tekst-parsing technieken.
Daarnaast zijn er verschillende XML-parsers beschikbaar om het maken en gebruiken van XML-documenten op vrijwel elk modern platform verder te vereenvoudigen. XML is licht en wordt uitstekend ondersteund door tools, dus XML codering maakt een ongelooflijk bereik mogelijk omdat praktisch elke client op elk platform kan communiceren met je webservice.
Een opmaakconventie kiezen
Het is vaak nodig om extra metadata op te nemen in de body van het bericht. U kunt bijvoorbeeld informatie willen opnemen over het type services dat een webservice moet leveren om aan uw verzoek te voldoen, zoals het aanmelden bij een transactie of routeringsinformatie. XML biedt geen mechanisme om de hoofdtekst van het bericht te onderscheiden van de bijbehorende gegevens.
Transportprotocollen zoals HTTP bieden een uitbreidbaar mechanisme voor headergegevens, maar sommige gegevens die geassocieerd zijn met het bericht zijn mogelijk niet specifiek voor het transportprotocol. De cliënt kan bijvoorbeeld een bericht sturen dat gerouteerd moet worden naar meerdere bestemmingen, mogelijk over verschillende transportprotocollen. Als de routeringsinformatie in een HTTP header zou worden geplaatst, zou het vertaald moeten worden voordat het via een ander transportprotocol, zoals SMTP, naar de volgende tussenpersoon wordt gestuurd. Omdat de routeringsinformatie specifiek is voor het bericht en niet voor het transportprotocol, moet deze deel uitmaken van het bericht.
Simple Object Access Protocol (SOAP) biedt een protocol-nagnostische manier om header-informatie te koppelen aan de body van het bericht. Elk SOAP-bericht moet een envelop definiëren. De envelop heeft een body die de payload van het bericht bevat en een header die metadata kan bevatten die geassocieerd zijn met het bericht.
SOAP legt geen beperkingen op aan hoe de body van het bericht geformatteerd kan worden. Dit is een potentieel probleem, want zonder een consistente manier om de gegevens te coderen, is het moeilijk om een toolset te ontwikkelen die je abstraheert van de onderliggende protocollen. Het kan zijn dat je veel tijd moet besteden om de interface van de webservice onder de knie te krijgen in plaats van het bedrijfsprobleem op te lossen.
Wat nodig was, was een standaard manier om een remote procedure call (RPC) bericht te formatteren en de lijst met parameters te coderen. Dit is precies wat sectie 7 van de SOAP specificatie biedt. Het beschrijft een standaard naamgevingsconventie en coderingsstijl voor procedure-georiënteerde berichten.
Omdat SOAP een standaardformaat biedt voor het seriëren van gegevens in een XML-bericht, kunnen platformen zoals ASP.NET en Remoting de details voor je wegabstraheren.
Beschrijvingsmechanismen kiezen
SOAP biedt een standaardmanier voor het formatteren van berichten die worden uitgewisseld tussen de webservice en de client. De client heeft echter aanvullende informatie nodig om het verzoek correct te serialiseren en het antwoord te interpreteren. XML Schema biedt een manier om schema's te maken die kunnen worden gebruikt om de inhoud van een bericht te beschrijven.
XML Schema biedt een kernset van ingebouwde datatypes die kunnen worden gebruikt om de inhoud van een bericht te beschrijven. Je kunt ook je eigen datatypes maken. De zakenbank kan bijvoorbeeld een complex datatype maken om de inhoud en structuur te beschrijven van de body van een bericht dat wordt gebruikt om een creditcardbetalingsaanvraag in te dienen.
Een schema bevat een set datatype- en elementdefinities. Een webservice gebruikt het schema niet alleen om het type gegevens te communiceren dat verwacht wordt in een bericht, maar ook om inkomende en uitgaande berichten te valideren.
Een schema alleen geeft echter niet genoeg informatie om een webservice effectief te beschrijven. Het schema beschrijft niet de berichtpatronen tussen de client en de server. Een client moet bijvoorbeeld weten of hij een antwoord kan verwachten wanneer een order in het ERP-systeem wordt geplaatst. Een client moet ook weten via welk transportprotocol de webservice verwacht verzoeken te ontvangen. Tot slot moet de client weten op welk adres de webservice bereikbaar is.
Deze informatie wordt geleverd door een WSDL-document (Web Services Description Language). WSDL is een XML-document dat een bepaalde webservice volledig beschrijft. Tools zoals ASP.NET WSDL.exe en Remoting SOAPSUDS.exe kunnen WSDL consumeren en automatisch proxies bouwen voor de ontwikkelaar.
Zoals bij elke component die gebruikt wordt om software te bouwen, moet een webservice ook vergezeld zijn van geschreven documentatie voor ontwikkelaars die tegen de webservice programmeren. De documentatie zou moeten beschrijven wat de webservice doet, welke interfaces hij blootstelt en enkele voorbeelden van hoe de service gebruikt kan worden. Goede documentatie is vooral belangrijk als de webservice wordt blootgesteld aan clients via het internet.
Ontdekkingsmechanismen kiezen
Als je eenmaal een webservice hebt ontwikkeld en gedocumenteerd, hoe kunnen potentiële klanten deze dan vinden? Als de webservice is ontworpen om te worden gebruikt door een lid van je ontwikkelteam, kan je aanpak vrij informeel zijn, zoals het delen van de URL van het WSDL-document met je collega een paar kantoorhokjes verderop. Maar als potentiële klanten op het internet zitten, is het een heel ander verhaal om effectief reclame te maken voor je webservice.
Wat nodig is, is een gemeenschappelijke manier om webservices te adverteren. Universal Description, Discovery and Integration (UDDI) biedt zo'n mechanisme. UDDI is een industriestandaard gecentraliseerde directoryservice die kan worden gebruikt om webservices te adverteren en te vinden. Met UDDI kunnen gebruikers zoeken naar webservices aan de hand van een groot aantal zoekcriteria, waaronder bedrijfsnaam, categorie en type webservice.
Webservices kunnen ook worden geadverteerd via DISCO, een eigen XML-documentindeling gedefinieerd door Microsoft waarmee websites de services die ze aanbieden kunnen adverteren. DISCO definieert een eenvoudig protocol voor het faciliteren van een hyperlinkstijl voor het lokaliseren van bronnen. De primaire gebruiker van DISCO is Microsoft Visual Studio.NET. Een ontwikkelaar kan zich richten op een bepaalde webserver en navigeren door de verschillende webservices die door de server worden aangeboden.
Wat ontbreekt er in Web Services?
Het is je misschien opgevallen dat een aantal belangrijke onderdelen van een gedistribueerde componenteninfrastructuur niet gedefinieerd zijn door webservices. Twee van de meest opvallende omissies zijn een goed gedefinieerde API voor het creëren en consumeren van webservices en een set van component services, zoals ondersteuning voor gedistribueerde transacties. Laten we elk van deze ontbrekende onderdelen bespreken.
- Webservicespecifieke API De meeste gedistribueerde component infrastructuren definiëren een API om taken uit te voeren zoals het initialiseren van de runtime, het aanmaken van een instantie van een component en het weergeven van de metadata die gebruikt worden om de component te beschrijven. Omdat de meeste programmeertalen op hoog niveau een zekere mate van interoperabiliteit met C bieden, wordt de API meestal weergegeven als een vlakke set van C methodehandtekeningen. RMI gaat zelfs zo ver dat het zijn API nauw koppelt met één enkele high-level taal, Java.
In een poging om ervoor te zorgen dat webservices programmeertaalagnostisch zijn, heeft Microsoft het aan individuele softwareleveranciers overgelaten om ondersteuning voor webservices te binden aan een bepaald platform. Later in het boek bespreek ik twee webservice-implementaties voor het NET-platform, ASP.NET en Remoting.
- Onderdelendiensten Het Web services platform voorziet niet in veel van de diensten die gewoonlijk worden aangetroffen in gedistribueerde componenteninfrastructuren, zoals het beheer van de levensduur van objecten op afstand, object pooling en ondersteuning voor gedistribueerde transacties. Het implementeren van deze diensten wordt overgelaten aan de gedistribueerde componenteninfrastructuur.
Sommige diensten, zoals ondersteuning voor gedistribueerde transacties, kunnen later worden geïntroduceerd als de technologie volwassen wordt. Andere, zoals object pooling en mogelijk object lifetime management, kunnen worden beschouwd als een implementatiedetail van het platform. Remoting definieert bijvoorbeeld uitbreidingen om ondersteuning te bieden voor object lifetime management, en Microsoft Component Services biedt ondersteuning voor object pooling.
Samenvatting
Componentgebaseerd programmeren heeft bewezen een zegen te zijn voor de productiviteit van ontwikkelaars, maar sommige services kunnen niet worden ingekapseld door een component dat zich in het datacenter van de klant bevindt. Oude technologieën zoals DCOM, CORBA en Java RMI zijn niet geschikt om clients toegang te geven tot services via het internet, dus Microsoft vond het nodig om van onderaf te beginnen en een industriestandaard manier te ontwikkelen om toegang te krijgen tot services op afstand.
Webservices is een overkoepelende term die een verzameling industriestandaardprotocollen en -diensten beschrijft die worden gebruikt om een basisniveau van interoperabiliteit tussen toepassingen mogelijk te maken. De steun van de industrie voor Web services is ongekend. Nooit eerder hebben zoveel toonaangevende technologiebedrijven een standaard ondersteund die interoperabiliteit tussen applicaties mogelijk maakt, ongeacht het platform waarop ze draaien.
Een van de factoren die bijdragen aan het succes van webservices is dat ze zijn gebaseerd op bestaande internetstandaarden zoals XML en HTTP. Hierdoor kan elk systeem dat tekst kan parsen en communiceren via een standaard internet transportprotocol communiceren met een webservice. Bedrijven kunnen ook gebruikmaken van de investeringen die ze al in deze technologieën hebben gedaan.