SOA & Interop @ Microsoft France : Interop

[TechDays 2009] Tour d'horizon REST en environnement Microsoft et hétérogène

Steve SFARTZ — Tue, 17 Feb 2009 13:45:00 GMT

Afin de faire un tour d’horizon de l’architecture REST et son implémentation en environnement hétérogène .Net et Java, cette session a été co-animée avec Thierry Boileau de la société Noelios Technologies, spécialistes REST et concepteurs du framework Restlet.

Nous avons choisi de consacrer 30 minutes aux principes d’architecture REST et à la méthodologie ROA/D préconisée par Noelios : identification des ressources, constitution des URI, choix des méthodes, conception des représentations, définition des statuts HTTP. En conclusion, de cette première partie, REST est un style d’architecture, chacun doit se positionner depuis les positions les plus pragmatiques ou plus puristes (au sens respectueuses de la thèse de Roy Fielding).

Nous avons ensuite parcouru les implémentations proposées par Microsoft et Noelios, en présentant des implémentations permettant de parcourir et mettre à jour une liste de clients :

WCF : depuis la version 3.5, WCF propose un binding adapté au style REST (WebHttpBinding) qui permet de construire ses URI (URI template), de définir ses styles de représentation (XML, JSON…) et de spécifier ses Méthodes (GET, PUT, POST, DELETE). WCF constitue ainsi une fondation pour les frameworks cités ci-après.

WCF REST Starter Kit : annoncé en octobre 2008, ce framework opensource proposé sur CodePlex implémente les scénarios REST les plus courants, à savoir exposer une ressource sous format XML ou JSON, une collection de ressources, un flux Atom… Le kit est complété de template Visual Studio.

ADO.NET Data Services : Ce framework est une extension standard de .Net 3.5 et de Silverlight 2, et une API javascript est aussi disponible. En pratique, il s’agit ici d’exposer et consommer des ressources très facilement au travers d’interfaces REST qui permettent de parcourir le graphe de ressources, avec une intégration de sources de données relationnelles au travers du framework ADO.Net Entity. Remarque : il est aussi possible d’exposer des sources de données mémoires. Ce framework est largement utilisé par les services en ligne Microsoft (notamment Azure Storage et SQL Services), et il a le gros avantage de simplifier la manipulation des ressources côté client au travers d’une API dédiée (qui permet de s’affranchir de l’écriture de requêtes REST, mais aussi de la gestion des états des données – notion de “Unit of Work / Persistance Unit” pour les familiers de TopLink / JPA). Les flux échangés sont de type Atom pour les collections et possibilité de choisir XML/JSON pour les éléments atomiques.

Restlet : le framework opensource Java de Noelios a la caractéristique d’implémenter l’ensemble du paradigme REST, en étant nativement orienté Composants et Connecteurs. En pratique, une application expose des Ressources qui proposent des représentations.

Nous avons ensuite présenté une synthèse qui positionne ces implémentations. Remarque : s’il est possible d’accéder en REST à l’API ADO.NET Data Services, cette communication sera simplifiée si on utilise une API client ADO.NET Data Services.

Figure : Synthèse REST en environnement hétérogène

Nous avons conclu en présentant 2 scénarios d’interopérabilité :

Une application Silverlight qui accède à des ressources REST exposées en Java Restlet. Dans la mesure où la technologie Silverlight limite les méthodes HTTP à POST et GET, nous avons du surcharger l’URI de mise à jour avec une extension Restlet pour supporter le PUT (?method=PUT). Pour une meilleure interopérabilité, je vous invite à utiliser l’extensibilité HTTP au travers d'un header X-HTTP-Method-Override.

Une intégration Restlet des queues de messages de Windows Azure, qui permet donc de manipuler les queues de messages en Java, cad, pousser et retirer des messages mais aussi créer et supprimer des queues. Cette démonstration a été réalisée grâce à l’intégration de la technologie d’authentification SharedKey et SharedKeyLite par les équipes Noelios Technologies dans les derniers builds de la version 1.2. (unstable build du 16 février).

"Big SOA" non merci => place aux Services

Steve SFARTZ — Wed, 07 Jan 2009 01:07:00 GMT

L’année 2009 débute par ce billet “SOA is Dead; Long Live Services” de Anne-Thomas Manes du Burton Group (citée précédemment dans le billet “Les Bus de Services en pratique”).

Except in rare situations, SOA has failed to deliver its promised benefits. After investing millions, IT systems are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever. The people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives.

It’s time to accept reality. SOA fatigue has turned into SOA disillusionment

Le billet étonnera peu de spécialistes du domaine, mais dans la mesure où Anne-Thomas est l’une des figures de la “Big SOA”, la nouvelle est une importante marque de reconnaissance pour les approches pragmatiques.

Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.

UPDATE (lu parmi les commentaires du billet d'Anne) : I've actually had conversations with IT professionals about their SOA initiatives where they had trouble defining what SOA stood for, and not understanding that one could have a service-oriented-architecture without buying a "SOA" stack of software.

Le grand gagnant : les Services et les scénarios concrets d’utilisation en entreprise notamment :

L’Intégration & Interopérabilité (les Services Web REST & SOAP style)
L’Alignement IT/Métier (BPM, MDM…)
Le Cloud Computing (SaaS, PaaS, IaaS…)

D’ailleurs, je pressens que l’année 2009 va voir la fusion de mes blogs “SOA & Interop @ Microsoft France” et “Cloud Computing @ Microsoft France” vers un blog unique qui s’intitulerait “Services & Interop @ Microsoft France”, voire “Software + Services @ Microsoft France” ;-)

“Geneva” : Roadmap et adoption

Steve SFARTZ — Fri, 12 Dec 2008 14:36:00 GMT

Durant la session “Identity : Roadmap for Software + Services” de la PDC 2008, Kim Cameron a présenté la vision Microsoft en terme de fédération d’identité au travers des technologies “Geneva” Server, Framework & Cardspace et son intégration avec les founrnisseurs de claims que sont Windows Live ID, Microsoft Federation Gateway, .Net Access Control Services ou tiers. Rappelons que ces concepts sont fondamentaux pour vous assurer de l’accessibilité de vos services au délà des frontières de votre organisation.

Si vous êtes intéressé par les technologies “Geneva”, nous lançons un programme TAP (Technology Adoption Program) mettant en oeuvre la version beta 2. Pour y participer, proposer un scénario d’expérimentation détaillé. Pour rappel, voici la roadmap des technologies Geneva :

Geneva, Fédération d’identité, comment ça marche ? à quoi ça sert ?

En synthèse l’objectif est de simplifier l’accès à vos applications au travers d’un modèle ouvert et interopérable reposant sur le concept de claims (proclamation d’informations d’identité). On résoud donc la problématique suivante :

au travers d’un système du type :

où les informations d’un Active Directory d’Entreprise sont exposées sous forme de claims standards et interépérables pour être consommables à l’extérieur de l’entreprise par des systèmes avec lesquels nous aurons établi des partenariats (système d’identités fédérées).

Qu’en est-il du Microsoft Services Connector ?

Il s’agit d’un connecteur spécifique, gratuit et disponible en téléchargement, qui permet de connecter un Annuaire d’entreprise Active Directory aux Services Microsoft. Ce connecteur est donc plus restrictif que la technologie “Geneva Server” qui permet elle de créer une fédération d’identité entre système hétérogène (et non limité aux Services proposés dans les nuages par Microsoft et accessibles au travers de la Microsoft Federation Gateway).

Qu’est que la Microsoft Federation Gateway ?

Microsoft propose différents services (Live Services, Azure Services…) pour le particulier, les entreprises et les développeurs. Ces services sont accessibles au travers d’API spécifique (Windows Live ID, .Net Access Control Service). L’objectif de la Microsoft Federation Gateway est de proposer un point unique d’accès à l’ensemble des services proposés par Microsoft. Ainsi, vos applications d’entreprise peuvent tirer parti immédiatement de la multitude de services Live et Azure pour élargir leurs fonctionnalités.

J’attire votre attention que la passerelle de fédération d’identité Microsoft est compatible avec des claims générées par des technologies tierces et respectant les standards de fédération d’identité.

Remarque : Il est aussi possible d’accéder directement aux services Live et Azure sans mettre en oeuvre de fédération d’identité, c’est-à-dire en passant directement par les API proposées par ces services par le Live Framework et le SDK d’Azure SDK.

Qu'est-ce que le Geneva Framework ?

Il s'agit d'un framework .Net qui facilite la manipulation de claims dans vos applications .Net Windows et Web mais aussi vos services Web.

Michel Leroux Bustamante propose un article qui décrit sa mise en oeuvre avec WCF : "Geneva Framework : A better approach for building claims based WCF services"

En bref, l’authentification et la vérification des autorisations d’accès aux fonctionnalités de vos applications peut se résumer comme suit en .Net, à partir du moment où vous reposerez sur les principes des claims :

WS02 : un support avancé de SOAP pour PHP

Steve SFARTZ — Tue, 16 Sep 2008 18:09:00 GMT

Le framework WSF/PHP proposé par WS02 permet d’exposer et de consommer des Services Web qui respectent le Basic Profile, à savoir SOAP 1.1 et 1.2 mais aussi WSDL 1.1 et 2.0.

Mais WS02 est allé plus loin en supportant les spécifications avancées des Services Web (WS-*), avec le support de SOAP MTOM, WS-Addressing, WS-Security, WS-SecurityPolicy et WS-ReliableMessaging.

Quelques bonus :

WSF/PHP permet aussi l’invocation des Services Web selon un style REST.
Le WSDL est auto-généré dans une logique Code-First
La commande “wsdl2php” permet de générer les services ou les proxy clients associés à un WSDL

Voici une excellente nouvelle pour nos tests d’interopérabilité.

Interopérabilité des Services Web ... sur le terrain

Steve SFARTZ — Wed, 12 Mar 2008 13:13:00 GMT

Au fil de mes conférences et interventions sur les scénarios d'interopérabilité Java - .Net, je rencontre régulièrement les mêmes écueils. Voici donc un B.A.BA pour une interopérabilité réussie (avec la contribution de Benjamin Bellon Serre :-) :

Générer un proxy client à partir du WSDL

Utiliser la commande svcutil sous WCF (ou bien son équivalent sous Visual Studio : Add Service Reference...) ou bien la commande wsimport si vous utilisez un framework Java qui implémente JAX-WS

Ecueil 1 : la génération du proxy client Java ne fonctionne pas.

Cela est généralement lié au fait que le WSDL généré par WCF comprend des includes (même si c'est prévu par les spécifications, certains frameworks Java ne l'implémentent pas).

Dans ce cas, il faut retravailler le WSDL ou bien demander à la partie .Net de "mettre à plat" son WSDL. Voir ce billet ...

Ecueil 2 : les formats SOAP supportés par les frameworks doivent être alignés

Si JAX-WS et WCF supportent la plupart de ces modes d'encodage, il faut tout de même les aligner. En principe, la simple génération à partir du WSDL permet de générer le bon formattage par le proxy client. Cependant, si le consommateur ne supporte pas un mode encodage, il faudra adapter le serveur au mode d'encodage supporté. Voici le moyen en WCF :

Pour adapter la partie JAX-WS, voici les attributs à positionner sur le service :

@SOAPBinding(style=SOAPBinding.Style.DOCUMENT, use=SOAPBinding.Use.LITERAL)
public class ServiceSomme { ...

Si vous souhaitez consommer en Java un Web Service exposé par un applicatif Microsoft, voici les encodages proposés par défaut pour les frameworks historiques (au sens avant WCF)

Et si ça ne fonctionne toujours pas, il faut aller regarder de plus près le fichier WSDL et les flux SOAP

L'outillage nécessaire pour soumettre des trames SOAP est SoapUI côté Java, et ServiceTester côté .Net (fourni avec le Managed Service Engine). L'intégration WCF dans VisualStudio 2008 permet aussi de soumettre des flux SOAP pour un service .Net hébergé grâce au moteur WCF intégré (WCFTestClient)

Si vous utilisez WCF, il suffit de mettre en place l'analyse (Diagnotics) pour pouvoir tracer les flux SOAP échangés.

<system.diagnostics>
    <sources>
      <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
        <listeners>
          <add type="System.Diagnostics.DefaultTraceListener" name="Default">
            <filter type="" />
          </add>
          <add name="ServiceModelMessageLoggingListener">
            <filter type="" />
          </add>
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add initializeData="...\app_messages.svclog"
        type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
        name="ServiceModelMessageLoggingListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack">
        <filter type="" />
      </add>
    </sharedListeners>
</system.diagnostics>

Ressources

Pour approfondir les aspects théoriques des Services Web et les problématiques d'interopérabilité avec des exemples AXIS, JAX-WS et WCF, je vous invite à lire ce livre blanc et les vidéos associées.

Si vous êtes en environnement .Net + WebSphere 6, IBM a publié un guide dont la première partie couvre SOAP et WS-Adressing.

Protocoles de communication Windows et encodages XML

Steve SFARTZ — Thu, 06 Mar 2008 14:27:00 GMT

Suite à l'annonce Interopérabilité de Microsoft, les 30.000 pages d'API documentées dans le cadre notamment du procès avec la Communauté Européenne ont été mises à disposition. Pour information ou rappel, ce travail collossal a été réalisé sur plusieurs années et par près de 200 spécialistes.

Dans le cadre de l'interop et de la SOA, la documentation des protocoles de communication MCPP sont passionnants, ils offrent un bon complément à la documentation MSDN du framework .Net.

En les parcourant je me suis intéressé à l'encodage binaire des messages SOAP. La lecture de ces trois documents permet de découvrir et approfondir les choix et l'implémentation choisie par Microsoft pour optimiser la sérialization de documents XML.

[MC-NBFS]: .NET Binary Format: SOAP Data Structure
[MC-NBFX]: .NET Binary Format: XML Data Structure
[MC-NBFSE]: .NET Binary Format: SOAP Extension

Du coup, voilà qui m'amène à me poser la question du choix de la solution d'encodage optimale, des options disponibles, ainsi que l'état des standards dans le domaine. Voici la synthèse de mes recherches au 6 mars 2008 :

Si souhaitez disposer de critères de choix d'une solution d'encodage ou bien de compression de messages SOAP, je vous invite à parcourir cette présentation qui fait état d'une expérimentation à l'aide de Sun Fast InfoSet et GZIP pour des messages de différentes tailles : A Study of the Impact of Compression and Binary Encoding on SOAP. Dommage l'encodage SOAP binaire proposé avec Microsoft n'a pas été testé.

Côté spécifications, je vois 3 stratégies d'encodage XML émerger : Microsoft (spécifications juste au-dessus) utlisé par WCF, SUN XML Fast InfoSet (FI) et celle du W3C Efficient XML Interchange(EXI) en draft depuis Decembre 2007.

Bilan vis à vis de WCF...

WCF propose 3 modes d'encodage des messages SOAP : Text (XML en clair), Binaire (optimisation en remplaçant les tags par une codification pré-établie, un peu comme une compression sur mesure qui a aussi l'avantage d'optimiser la phase de decoding), et MTOM (recommandation W3C qui cible l'intégration de données au format binaire au sein d'un message SOAP).

Warning de Nicholas Allen: The binary message encoder requires you to use SOAP 1.2 and any version of message addressing. Validation for the message encoder checks that you are using SOAP 1.2. A transport can supply its own native version of addressing, but the HTTP, TCP, and named pipe transports don't work with this for the binary encoding. The validation doesn't check to make sure that you have some kind of message addressing, so if you are using AddressingVersion.None, then that won't show up as an error until you try to send a message.

L'encodage binaire proposé par WCF optimise l'échange des flux, mais de façon non interopérable (même si les spécifications sont publiées, je n'ai pas connaissance d'implémentation Java de la sérialization proposée par Microsoft; voilà un projet de stage :-)).

Si vous souhaitez optimiser la transmission de vos trames SOAP tout en restant interopérable, vous avez l'option de miser sur les spécifications Draft EXI du W3C dont AgileDelta propose une implémentation pour WCF, mais aussi pour AXIS 1, AXIS 2 et WebLogic.

[Archive] Tirer parti des technologies Microsoft depuis Java au travers des Services Web

Steve SFARTZ — Thu, 03 Jan 2008 15:07:00 GMT

Avec le concours de Jean-Louis LEQUEUX et de Nasime EL FARTASSE d'ATOS ORIGIN, le RV de l'interop du 18 octobre 2007 a permis d'illustrer 4 scénarios d'interopérabilité : Excel (VBA & AddIn avec VS2008), SharePoint (MOSS2007), Génération de rapports (SQL Server Reporting Services) et Composition de Services (WF - Wndows Workflow Foundation 3.5)

Vous pouvez écouter les sessions et télécharger les PPTs sur Microsoft Audio & Video.

J'ai profité des vacances pour packager un minimum les démos, dont voici les codes des démonstrations.

Le scénario d'interopérabilité Composite avec Worflow Foundation demandait à être complété : un article détaillé illustrant un scénario de médiation de protocoles avec WF, entre JAX-WS et un client REST via WF et en utilisant les bindings WCF paraîtra courant Janvier.

Voici l'agenda d'étaillé du RV du 18 octobre :

Atos Origin, SOA et interopérabilité 2/13
Les opportunités liées aux Services Web en entreprise 3/13
Théorie des Services Web 4/13
Les profils d'interopérabilité du WS-I 5/13
Développement de Services Web en .NET 6/13
Développement de Services Web en Java 7/13
Quelques bonnes pratiques pour débuter 8/13
Consommer des Services Java depuis Excel en VBA 9/13
Consommer des Services Java depuis un AddIn .NET Excel 10/13
Intégrer en Java un référentiel SharePoint 11/13
Rechercher et générer des rapports SQL SERVER depuis Java 12/13
Invoquer un Workflow .NET depuis un Service Web Java et plus 13/13

Ce RV de l'interop vient compléter de sessions plus théoriques sur les Services Web et l' Interopérabilité entre les environnements .Net et Java :

Juin 2007 : Interopérabilité des stacks SOAP .Net et Java

WCF, Apache AXIS et SUN JAX-WS
Accompagné d'un livre blanc

Juin 2007 : Interopérabilité via les protocoles avancés WS-*

Sécurité, transactions entre WCF et WSIT / Metro / SUN Glassfish

Mai 2007 : 3 stratégies pour interopérer entre Java et .Net

Services Web, Bridges, COM

[13 décembre] RV de l'interop : Anticipez le support de SDO.Net par l'OASIS

Steve SFARTZ — Tue, 20 Nov 2007 12:05:00 GMT

Le 25 octobre 2007, l'OASIS a annoncé la création d'un comité technique autour des spécifications SDO. Pour faire bref, disons que SDO (Service Data Objects) permet de décrire une grappe de de données au format XML, mais aussi les modifications opérées sur ces données (cad, un diff) de façon à pouvoir soumettre ces modifications à un service d'exécution de ces modifications (Data Access Services). Pour compléter ces éléments, un communiqué de presse est disponible.

Le premier objectif du comité sous 6 mois sera de livrer des spécifications SDO 2.1.1 comprenant des fix ainsi que le support de C++. Dans un second temps, et sous un délai de 15 à 18 mois, le comité livrera SDO 3.0 :

Enhancements to Static SDO : SDO Metadata, API for generation, Defining name mangling and package to namespace mappings, Consolidation with data objects from standard frameworks (JAX-B)
Service Level Programming API : readOnly properties modification, enable or disable SDO runtime features
Features related to the Data Access Services (DAS) Specification : Support for a concept of identity in SDO, and its relationship to other, Support for partially loaded graphs.
SDO XML Path Support
Improved XML/XSD Support : Improve tolerance for malformed XML, API to perform validation.
Cleaning up/ Enhancing the SDO API
Organization of SDO Type System and Helpers
Enhancements to SDO Metadata : Support validation against the metadata, where appropriate, Provide support for versioning of types, Provide a mechanism for identifying an ID property when defining Types, and Properties, Provide a mechanism to externalize the SDO-to-XML mapping.
Interoperability with .NET : Define interoperability with ADO .NET diffgrams
Relaxing Containment Requirements
Notification Support : Define a callback mechanism to inform clients of changes to properties
Programming Language Support : Language Specifications for Java, C++, and for all languages that are compliant with the .NET platform, May define additional programming language support for SDO 3.0 : C, COBOL, PL/I, JavaScript,PHP, Python, Perl, Ruby, Groovy

Pour découvrir les Data Access Services, et comment les spécifications SDO.Net s'articulent avec Linq et ADO.Net, inscrivez-vous au rendez-vous de l'interopérabilité du 13 décembre 14h.

La société XCALIA, éditeur de XICS (XCALIA Intermediation Core Server) et membre du comité technique SDO de l'OASIS, vous présentera ses travaux autour de SDO.Net et l'intégration avec l'environnement Visual Studio 2008 et Linq.

Porte 25 : Microsoft et l’Open Source et les initiatives d’interopérabilité

Steve SFARTZ — Mon, 22 Oct 2007 09:18:00 GMT

Marc Gardette lance Porte25, petit cousin français du site américain port25. Ce blog sera un canal de diffusion des informations concernant la stratégie et le positionnement de Microsoft vis-à-vis de l’Open Source et des initiatives d’interopérabilité.

[18 octobre] RV de l’intérop : Tirez parti des technologies Microsoft depuis Java

Steve SFARTZ — Fri, 12 Oct 2007 06:28:00 GMT

Un séminaire de 3h pour comprendre et implémenter les 5 scénarios d’interopérabilité les plus courants en Entreprise !
Au travers des Services Web, depuis les technologies Java vers les technologies Microsoft/ .Net et vice versa.

Comment appeler un service Web Java depuis Excel ?
Comment appeler un service Java depuis un client riche Desktop WPF – Windows Presentation Foundation ?
Comment déclencher la génération et afficher un rapport SQL Serveur depuis Java ?
Comment récupérer les données d’une liste SharePoint depuis Java ?
Comment appeler une orchestration Windows Workflow Foundation depuis Java et faire appel à un service Web Java depuis cette orchestration ?

Ce séminaire sera co-animé par ATOS et Microsoft.

De plus, Jeudi 18 octobre, c’est jour de grève, vous pourrez vous éclipse(r) facilement de vos tâches quotidiennes.

SilverLight 1.0 en version finale pour Windows et Apple, collaboration officielle sur Novell / Linux / MoonLight pour Linux

Steve SFARTZ — Wed, 05 Sep 2007 10:25:00 GMT

SilverLight et son encoder associé (Expression Encoder) sont en version 1.0 (finale) aujourd'hui. En moins d'un an , Microsoft a donc réussi son pari de livrer une expérience utilisateur unique et universelle puisque portée par les browsers Web. SilverLight constitue l'un des deux types de clients riches pour le Web (RIA) proposés par Microsoft pour la consommation des services, le second étant la technologie AJAX ASP.Net.

Microsoft et Novell annoncent par ailleurs un partenariat pour assurer la disponibilité de SilverLight sur la plate-forme Linux (même si comme le fait remarquer Christophe, cette plate-forme reste largement sous les 1% de parts de marché).

Cette annonce est historique en terme de contribution de la part de Microsoft à l'opensource dixit MigUel De Icasa :

Microsoft will give Novell access to the test suites for Silverlight to ensure that we have a compatible specification. The same test suite that Microsoft uses for Silverlight.
Microsoft will give us access to the Silverlight specifications: details that might be necessary to implement 1.0, beyond what is currently published on the web; and specifications on the 1.1 version of Silverlight as it is updated.
Microsoft will make the codecs for video and audio available to users of Moonlight from their web site. The codecs will be binary codecs, and they will only be licensed for use with Moonlight on a web browser (sorry, those are the rules for the Media codecs[1]).
Novell will implement Silverlight 1.0 and 1.1 and will distribute it for the major Linux distributions at the time of the shipment. We will offer some kind of one-click install for Linux users (no "Open a terminal and type su followed by your password..." as well as RPM and DEB packages for the major distros and operating systems.

Quelle est la prochaine étape ?

La version 1.1 de SilverLight ira au delà de la programmation JavaScript proposée aujourd'hui, en supportant les languages VB, C#, JavaScript, Python, Ruby, Pascal, ... puisqu'une marchine virtuelle .Net sera embarquée dans le plugin ! Pour ceux qui n'avaient pas suivi, il s'agit d'une CLR multi-plateforme, ultra-légère, et désormais supportée sur Linux par Novell avec la collaboration de Microsoft.

Pour l'annonce complète de SilverLight 1.0 et du futur, consulter le blog de Scott Guthrie :

Now that Silverlight 1.0 is out the door, my team is cranking hard on our Silverlight 1.1 release.

Silverlight 1.1 will include a cross-platform version of the .NET Framework, and will enable a rich .NET development experience in the browser. It will support a WPF programming model for UI - including support for an extensible control model, layout management, data-binding, control skinning, and a rich set of built-in controls. It will also include a subset of the full .NET Framework base class library you use today, including support for collections, generics, IO, threading, globalization, networking (including sockets, web-services and REST support), HTML DOM, XML, local storage, and LINQ.

You'll be able to use any .NET language to develop a Silverlight application (VB, C#, JavaScript, Python, Ruby, Pascal, and more). It is going to really open up a lot of new development opportunities.