Minder DCOM en meer XML in Windows Longhorn

Microsoft is bezig met de ontwikkeling van een nieuw besturingssysteem, Windows Longhorn genaamd. In deze Windows-versie zullen een drietal zaken grondig gaan veranderen: (1) het bestandssysteem wordt aangepakt en krijgt meer relationele mogelijkheden (WinFS), (2) de grafische engine gaat op de schop en deze krijgt de mogelijkheid om allerlei effecten uit te voeren (Avalon) en (3) het communicatiesysteem tussen applicaties zal grondig veranderd gaan worden (Indigo). Over dit laatste onderdeel heeft C|Net een artikel geschreven waarin uitgelegd wordt wat de voornaamste veranderingen zullen gaan zijn. Meer informatie over Indigo is terug te vinden op deze MSDN-pagina's. Bij MSDN is ook meer informatie te vinden over WinFS en Avalon.

Op dit moment maken veel programma's gebruik van het Component Object Model (COM) en het Distributed Component Object Model (DCOM) om gegevens en objecten tussen programma's te kunnen delen. Indigo gaat hier, als uitbreiding op .NET, echter verandering in brengen. Microsoft heeft besloten om deze programmeermodellen achter zich te laten en zich te gaan richten op een nieuw model. Dit nieuwe model zal veel gebruik maken van XML om gegevens uit te wisselen tussen programma's. Dit uitwisselen van data zal overigens niet meer via objecten verlopen, maar via services. Dit programmeermodel, waarbij de aandacht is gericht op services, staat tegenover de Java 2 Enterprise Edition-standaard, die vooral de nadruk legt op objecten.

Don Box, software architect bij Microsoft, heeft dit tijdens de Developing Software for the Future Microsoft Platform-conferentie afgelopen maandag toegelicht. Volgens hem heeft het object georiënteerde programmeren niet alle voordelen gebracht die beloofd werden. In de jaren negentig van de vorige eeuw werd gezegd dat bijna alles mogelijk was met de objecten, dit bleek echter niet zo te zijn. Objecten konden bijvoorbeeld maar met matig succes ingezet worden als distributiemedium. Om communicatie mogelijk te maken tussen programma's waren altijd class-, jar- of dll-bestanden nodig. Hierdoor leek het wel alsof programma's onderling goed communiceerden, maar uiteindelijk bleek toch dat de verschillende programma's te dicht bij elkaar moesten komen om communicatie mogelijk te maken.

Om dit probleem op te lossen heeft Microsoft het services-idee ontwikkeld. Programma's kunnen alleen met elkaar samenwerken door het versturen en ontvangen van berichten. Ieder programma dat gegevens aan een ander programma kan en wil leveren, wordt een service genoemd. Programma's of applicaties die deze gegevens bij het andere programma komen halen, worden clients genoemd. Een systeem van services en clients heeft de naam 'connected system' meegekregen. Programma's zullen samen kunnen werken, ook al is de onderliggende programmacode verschillend. Dit is mogelijk doordat er gebruik gemaakt wordt van XML als distributiemedium.

Reacties (56)

[nika]

Ik neem aan dat als een object een service vraagt om informatie, dat er nog steeds een object wordt aangemaakt op de server (net als DCOM). En dat dit object informatie uitwisselt met de client via XML.
Wat is het verschil, afgezien dat er mijnsinziens alleen meer data verstuurd moet worden (alle XML overhead?

[mindcrash]

En dat dit object informatie uitwisselt met de client via XML.

Nee, zoals ik al een paar keer eerder noemde is Indigo != XML Webservices, sterker nog XML Webservices maken deel uit van Indigo.

Indigo kan namelijk geheel zelf beslissen op de eigenschappen die vooraf door de developer zijn ingesteld hoe de client met de server communiceert met de server en vice versa.

Indigo kan hierbij een keuze maken uit alle communicatievormen die Microsoft in het verleden heeft geintroduceerd, dus: COM, DCOM, COM+, MSMQ, XML Web services, Enterprise Services en Remoting en op basis van de eerdergenoemde configuratie van deze service kan hij dan de beste keus maken uit bovengenoemde technologieen om de output over het netwerk te transporten. En dit alles gebeurt geheel transparant m.b.t. de client en server! (En dat is dus een van de redenen waarom ik persoonlijk Indigo een erg cool stukje technologie vind )

[Dennis van der Stelt]

Eén probleem van .NET Remoting, dat schijnt een beetje op de schop te gaan. De 'standaard' .NET remoting blijft, maar channels en sinks worden niet meer ondersteund... Dus als je je applicatie wilt laten werken in .NET 2.0 moet je maar 's nadenken als je dat nu gebruikt... Maar da's toch al.

Het verhaal van Microsoft is, dat als je NU webservices gebruikt, het straks relatief een eitje is om je applicatie om te zetten naar Indigo.

[Jace / TBL]

Dat niet meer elke app van een eigen dataformaat afhankelijk is. Nou ja, nog steeds wel natuurlijk, alleen door overal XML ipv random binaire shit te gebruiken heb je wat minder kans dat versieverschillen e.d. ertoe leiden dat data ineens niet meer uitwisselbaar is.

Maar inderdaad, ik zie de TONNEN aan overhead al weer aankomen. Begint die hardware eindelijk een keer echt snel te worden, weet MS het ongetwijfeld wel weer te verspillen (want geloof maar niet dat al deze nieuwe systemen erg bloat-free gaan worden)

[mindcrash]

Jaçon, lees mijn eerdere posts door deze draad eens... en je zult zien dat Indigo meer kan dan alleen XML (en de daarbijhorende overhead) door de lucht of over de draad sturen... binaire data is dus ook nog steeds mogelijk!

[Verwijderd]

i.p.v. inmformatie versturen via een skeleton-stub kun je nu gewoon xml posten bijv via http.

[mindcrash]

Indigo gaat hier, als uitbreiding op .NET, echter verandering in brengen. Microsoft heeft besloten om deze programmeermodellen achter zich te laten en zich te gaan richten op een nieuw model. Dit nieuwe model zal veel gebruik maken van XML om gegevens uit te wisselen tussen programma's.

Het gebruik van XML binnen Indigo zal wel meevallen, aangezien Indigo veel meer behelst dan de XML Webservices waarmee .NET zo bekend mee is geworden.

Naast XML Web Services zijn er binnen het .NET platform namelijk ook opvolgers geintroduceerd voor COM/DCOM en COM+ in de vorm van Enterprise Services en Remoting.

Daarnaast is het mogelijk om binnen .Net nog steeds gebruik te maken van COM objecten, en .Net assemblies kunnen op hun beurt weer geexposed worden als COM objecten. Dit om ervoor te zorgen dat delen van bestaande business apps die gebaseerd zijn op .Net te kunnen migreren naar dit platform zonder een volledig nieuwe omgeving te schrijven, aangezien de functionaliteit van de nieuwe .Net objecten nog steeds kan worden gebruikt in de oude omgeving (en vice versa kunnen oude onderdelen weer hergebruikt worden in een nieuwe omgeving).

Maar wat is Indigo dan wel? Indigo omvat alles wat met communicatie op het Windows platform te maken heeft, van "raw" access op de socket tot en met communicatie op de hoge niveau's middels alle(!) vormen die MS tot op heden aan de developers heeft gegeven: dus van COM en MSMQ tot XML Webservices en dit alles wordt qua API aangestuurd via objecten die leven binnen de System.Net namespace.

Zie ook de officiele Indigo FAQ op MSDN, waar trouwens ook veel meer nuttige informatie over de techniek achter Longhorn te vinden is

[Dennis van der Stelt]

Wat ik ervan begrepen heb is dat Indigo voor jou gaat kiezen welk protocol deze moet gaan gebruiken. Dit kan de directe benadering zijn, maar kunnen ook webservices worden. Dat hangt af van de situatie, die Indigo zelf schijnt te kunnen onderkennen.

[mindcrash]

Dat hangt af van de situatie, die Indigo zelf schijnt te kunnen onderkennen.

Nope, dat doet Indigo nou weer net niet... je zult zelf de behaviours van het communicatiekanaal d.m.v. attributes die je meegeeft aan je Indigo service moeten instellen, en aan de hand daarvan zal hij uiteindelijk bepalen welke technologie hij zal gaan gebruiken en over welk transportmiddel dat gebeurt.

[Tjeerd]

Mooi, als het via services moet gaan en XML, dan betekent het dat concurrenten alleen maar de XML-specificaties e.d. hoeven te weten en dan kunnen ze zo ook onderling gegevens uitwisselen, prachtig

[SWINX]

als er geen patenten waren ja....
maar natuurlijk heeft MS daar ook aan gedacht

[Luuk1983]

Ik denk niet dat het verkeerd is om van scratch een OS te gaan maken die op een ander principe gebaseerd is. Microsoft heeft echt wel veel tijd en onderzoek besteed aan dit systeem en ik denk dat het best wel eens kan gaan werken. XML vind ik ook niet zo'n verkeerde keuze: ik denk dat veel meer dingen met XML gaan werken, omdat het een goede manier is om gegevens te ordenen.

We moeten echter de praktijk nog even afwachten

[Stephan Oudmaijer]

Gegevens te ordenen. Ja leuk, maar lijkt me niet het hoofddoel. Voordeel van XML is dat in elke taal op elk platform op een gestandaardiseerde wijze een XML bestand kan worden ingelezen/weggeschreven.

Je kan XML prima gebruiken om data flink chaotisch en onleesbaar te maken, zat mooie voorbeelden gezien

[Dennis van der Stelt]

Lijkt me niet helemaal juist. CSV (Comma Seperated Values) kunnen óók door elk systeem ingelezen worden, dus waarom zou XML dan beter zijn?

Ten eerste om je weet wat waar staat en m.b.v. schema's kun je nog veel meer functionaliteit toevoegen. Als resultaat dat je gegevens aan iemand opvraagt en je weet precies wat er allemaal in staat en waaraan de informatie die je terug stuurt moet voldoen. En dat in een formaat dat iedereen aan kan. Dat samen is een ENORM voordeel t.o.v. andere methodes.

[Verwijderd]

CSV's zijn 2 dimensionaal, leuk om tables en spreadsheetjes in op te slaan, maar daar houdt 't echt op...

[Dennis van der Stelt]

Hehehe, je moet eens weten wat ik allemaal voorbij heb zien komen in CSV's!!!

[Verwijderd]

gegevens ordenen ? daar hebben we relationele databases voor (dat kan XML _niet_ vervangen), waarvan de implementatie iedereen een worst zal wezen zolang we er met SQL tegen kunnen praten.

[Anoniem: 97949]

ooit al van de xml-db van oracle gehoord ? slaat xml perfect relationeel op.

http://otn.oracle.com/sample_code/tutorials/cmsxdb/maintoc.htm

hier whitepaper te vinden
http://otn.oracle.com/tech/xml/xmldb/pdf/XMLDB_Technical_Whitepaper.pd f

[JeroenB]

Indigo gaat hier, als opvolger van .NET, echter verandering in brengen.

Indigo is niet de opvolger van .NET. Zoals Microsoft zelf schrijft:

"Indigo" is a set of .NET technologies for building and running connected systems.

Het is dus technologie die gemaakt is om gebruikt te worden op het .NET platform. Voor de programmeurs: een API.

[mindcrash]

Het is dus technologie die gemaakt is om gebruikt te worden op het .NET platform. Voor de programmeurs: een API.

Zover ik heb gezien via het online materiaal van de PC en zelf bij de DevDays is Indigo veel meer dan een API. Ja, het is de opvolger van (D)COM/COM+/Enterprise Services/Remoting/XML Webservices en de interactie met applicaties wordt via de bekende System.Net namespace in .NET geregeld, maar Indigo is blijkbaar ook verantwoordelijk voor al het netwerkverkeer op applicatieniveau.

Kort samengevat: Indigo neemt in een klap al die losse onderdelen over die de huidige netwerk stack in Windows vormen en ja, dat is een good thing

Ik heb begrepen dat het enige wat niet door het Indigo team qua communicatie wordt geregeld is bijvoorbeeld lowlevel toegang tot de netwerkkaart want dat is meer de verantwoordelijkheid van het Fundamentals team, die o.a. over de driverarchitectuur gaat.

[j.meijers]

Inderdaad, ik ben nu al zeer te spreken over de manier waarop Remoting bijvoorbeeld werkt in .NET. Daarmee kun je al op redelijk makkelijke wijze communicatie tussen bijvoorbeeld een server en een client maken (dit systeem gebruiken wij bij ons werk).

Als je echter met services kunt werken (zoals nu webservices al bestaan in .NET), dan wordt dit nog veel simpeler te realiseren. Klinkt dus als een zeer interessante ontwikkeling.

[Venator]

Programma's zullen samen kunnen werken, ook al is de onderliggende programmacode verschillend. Dit is mogelijk doordat er gebruik gemaakt wordt van XML als distributiemedium.

Hmm MS heeft net een patent op het implementeren van XML in hun applicaties.. Als anderen dus op dezelfde manier XML willen implementeren in hun software om bepaalde functies te gebruiken die MS pakketten (gaan)bieden die net even afwijken van de vastgelegde XML standaard, ben ik bang dat dit toch op een developer-license model zal uitdraaien waarin je moet betalen om een volledig compatible service op te zetten..

[Harm]

Hmm MS heeft net een patent op het implementeren van XML in hun applicaties.. Als anderen dus op dezelfde manier XML willen implementeren in hun software om bepaalde functies te gebruiken die MS pakketten (gaan)bieden die net even afwijken van de vastgelegde XML standaard, ben ik bang dat dit toch op een developer-license model zal uitdraaien waarin je moet betalen om een volledig compatible service op te zetten..

Het nieuwsbericht waar jij naar verwijst gaat over een compleet andere implementatie van XML en heeft dus erg weinig, zeg maar niets, te maken met de implementatie van XML zoals die in dit verband beschreven is en gebruikt gaat worden. Het zijn twee verschillende dingen: (1) XML als manier om documenten op te slaan inclusief eventuele opmaak enerzijds en (2) aan de andere kant XML als manier om data tussen applicaties te delen. Twee verschillende toepassingen, dus dat Office-XML-patent zal geen invloed hebben op de implementatie zoals die in Indigo geldt.

[Franckey]

Klinkt nieuw maar is het niet... Ik zie in SOAP een goede vervanging voor (D)COM... Waarschijnlijk wil Microsoft hier ook SOAP voor gebruiken, maar doen ze weer net alsof ze zelf iets moois bedacht hebben...

[spoonman]

>Waarschijnlijk wil Microsoft hier ook SOAP voor
>gebruiken, maar doen ze weer net alsof ze zelf iets
>moois bedacht hebben...

Dus als je iets "nieuw" wil noemen mag je niet voortbouwen op bestaande technologieën?

[Anoniem: 87832]

Het grappige hiervan is dat SOAP voor 90% door Microsoft bedacht is!

Ik heb hier op werk ooit een SOAP server gebouwd en ik kan je verzekeren dat SOAP bij lange na niet overal voor geschikt is; net zoals bij elk XML formaat is vooral performance de bottleneck, vandaar dat het mij ook zo verbaast dat Microsoft voor een XML-based protocol kiest.

Maar net zoals de halve wereld als gedweëe schaapjes achter OO aanhobbelden (zie ook artikel) zal straks ook wel XML door de mand vallen; net zoals met elke techniek duurt het even voordat men doorheeft dat geen énkele technologie het ei van columbus is voor elke mogelijke toepassing.

Waarom voert MS eigenlijk bij zowat elke nieuwe versie van Windows een nieuw IPC/RPC protocol toe?

[Anoniem: 94043]

Logisch dat Microsoft COM/DCOM langzaam overboord zet voor de communicatie tussen applicaties. Maar waarom een applicatie die gegevens levert nou weer een service moet heten? Ze noemen de applicaties die de gegevens binnenhalen ook clients dus waarom niet server

[Dennis van der Stelt]

Omdat het hele services verhaal uit Service Orientated Architecture komt, wat momenteel in architectuurland een waanzinnige hype is.

Zoek maar op het "Microsoft architectural journal" om te lezen wat SOA is. Verhalen zijn in dat document niet echt eenvoudig, dus wees gewaarschuwd. Anders moet je gewoon naar Microsoft Patterns & Practices gaan en daar wat documenten lezen. Ben je voorlopig onder de pannen! ;-)

[McBoom]

Zoek maar op het "Microsoft architectural journal" om te lezen wat SOA is.

Sexueel overdraagbare aandoening? Dat klinkt niet best

[DannyVersluis]

Soort virus dus

[Verwijderd]

Ceeewl nu krijgen we straks een server os met een interface met filmpjes

De Windows Server 2003 ++ Editie.

[Anoniem: 81293]

Uiteraard zal metadata meer overhead genereren dan binaire data. De vraag is alleen of je dat erg moet vinden.... echt serieus.... het introduceren en ontwikkelen van een nieuwe communicatie vorm als deze tussen applicaties als standaard neem veel meer tijd in beslag dan dat het hardware fabrikanten kost om die overhead goed te maken met snellere hardware. uiteindelijk zal het gebruiksgemak en de logische structuur van een systeem het winnen van de argumenten dat het zo snel mogelijk moet. Ik ben wat dat betreft een groot voorstander van XML.