C++ og SOAP - fremtiden for Windowskommunikation?
Nytår starter den 1. juli i Microsoft og det giver medarbejderne et lille vakuum til at forberede sig på det ny år og se hvilke kompetencer man skal tillægge sig eller genopfriske.
Den afdeling jeg sidder i, skal kigge på ny teknologi, som rammer markedet inden for de næste 12-18 måneder. Hvis der er produkter eller services, som kræver at man opgraderer sine kompetencer, så er sommerperioden det helt rigtige tidspunkt til den slags.
Hvor skal man så kigge hen for at finde de teknologier, som man skal se nærmere på' Et meget godt bud er "Professional Developers Conference". Her giver programmet og sessionernes overskrifter en meget fin pejling. I dag læste jeg for første gang på de annoncerede sessioner og der fik jeg en umiddelbar "WTF'"-oplevelse:
"Windows 7: Web Services in Native Code Windows 7 introduces a new networking API with support for building SOAP based web services in native code. This session discusses the programming model, interoperability aspects with other implementations of WS-* protocols, and demonstrates various services and applications built using this API."
Hvorfor? ...er det første spørgsmål, som presser sig på.
Jeg har selv et par bud, men først vil jeg gerne høre hvorfor I andre tror at .Net tilsyneladende ikke længere er "nok" til at dække webservice kommunikationen hos Microsoft.
Kommentarer (5)
Der findes vel en række grund til at man ønsker at understøtter native code. Efter min opfattelse må den tungeste grund være at mange eksisterende systemer kører i omgivelser hvor man ikke umiddelbart har lyst til at rulle .NET ud - og man har specielt ikke lyst til at omskrive native code så længe det virker efter hensigten :-)
En anden grund kunne være at der findes mange konservative udviklere der ikke ønsker at adoptere .NET og hellere vil hacke i native-land (f.eks. foretrækker jeg native code til mine hobbyprojejkter).
-
0 -
0
Ja, enig! Hvis native udvikling er en "in-house" ressource så er der vel ingen grund til at flytte sit udviklingshold på .Net med mindre man kan se en umiddelbar produktivitetsforøgelse.
Andre mulige grunde jeg kunne komme på ...
Performance - hvis Windows 7 skal have et multitouch UI så kunne det være tanken at serialisering af indkommende SOAP beskeder i et managed .Net er for langsomt og for "stor" en omkostning og der skal spares hvor spares kan!
Politik - Hvordan undgår man endnu en EU sag? Eller opnår compliance med de krav and organisationer evt måtte have i forbindelse med kommunikation med Windows? Et native API med SOAP som laveste fællesnævner er det politisk "rigtige" signal.
-
0
-
0
Politik - Hvordan undgår man endnu en EU sag? Eller opnår compliance med de krav and organisationer evt måtte have i forbindelse med kommunikation med Windows? Et native API med SOAP som laveste fællesnævner er det politisk "rigtige" signal.
Hvis den "native code" alene holdes på webserveren og ikke kræver at klienten er en Windows maskine, så har jeg meget svært ved at se hvor monopolsagen skulle kunne opstå.
Apache har f.eks supporteret CGI skrevet i native code siden 14.4 modems var "helt vild teknologi" og ingen monopolmyndighed har nogensinde interesseret sig for serversiden.
Hvis den "native code" derimod skal køre på klienten, så er det den dummeste ide Microsofts Markitekter er kommet op med siden "Microsoft Bob" eller for den sags skyld: den forhadte papirklips.
Poul-Henning
-
0
-
0
Whaaaat.. Vil man skrive operativsystemet som en serie services der kommunikerer via SOAP - altså en XML-protokol?
Dét vil jeg gerne se før jeg tror det :-)
-
0
-
0
Det vil i så fald være den største misforståelse af SOAP og XML som et RPC-paradigme: Nemlig at det skal kunne erstatte systemkald. SOAP og XML skal holdes til højniveau-operationer, og det er jeg sikker på, at phk er helt enig i.
-
0
-
0
