Paris - Los Angeles...."Oslo"!

J'étais parmi les nombreux courageux "frenchies" à avoir bravé Air France, la douane américaine (avec ses énooooormes officières), les cabs combinards pour pouvoir assister à la PDC 2008, à Los Angeles. J'ai donc été présent, et c'est avec une fébrile émotion que j'ai accueilli les annonces concernant Windows Azure  et Windows 7 ainsi que la présentation d'Oslo. C'est donc à Oslo  que je vous emmêne.

Comme les taxonomistes devant chaque nouvelle espèce découverte, fossile ou vivante, la question se pose de savoir comment la classer. Qu'est ce que c'est ? Dans quelle famille la classer ? etc.

Au niveau de l'informatique la problématique est augmentée de la difficulté  de déterminer en plus l'intention derrière la nouveauté et ce qu'on peut bien en faire.

Ben alors, qu'est ce que c'est ?

Voici ce qu'on lit dans le premier chapitre du  document "Oslo Overview.docx fourni avec le SDK Oslo :

"The Oslo Modeling Platform provides a fundamental change both in how people create and maintain a solution and in how software runs and controls a system. The platform enables you to develop model-driven solutions that are stored as transparent data in a common repository. The platform provides a complete solution for creating, viewing, and manipulating models both graphically, programmatically, and as data. This enables Oslo to help resolve the problems that companies have with managing the project lifecycle and that software can have with running complex systems."

Comme l'indique l'extrait ci-dessus, au pays d'Oslo, les modèles sont rois. La solution est décrite sous forme de modèles, ces modèles sont stockés dans un référentiel commun, et ces modèles peuvent être gérés comme une simple data, et finalement seront la matière premiére des systèmes qui seront "Oslo compliant". Les échanges entre les différents acteurs de la vie d'une solution passeront par un modèle commun entreposé dans le référentiel.

Voici à quoi pourrait ressembler un scénario Oslo simple:

ApplicationModel

  • Un architecte définit une solution pour un service. Il définit un modèle, dans lequel il décrit son service en mode boîte noire. Il indique également des contraintes d'éxécution telles que l'OS minimum. Il indique aussi les indicateurs de performance que le service propose. Il indique finalement les contraintes de fonctionnement minimal au dessous desquelles une instance de service doit être recyclée. L'architecte remonte son modèle dans le Repository.
  • Le développeur qui se voit assigné la tache d'implémenter le service, récupère le modèle depuis le Repository. Il voit l'intention de l'architecte et implémente le service. Il implémente également les compteurs de performance demandés. Une fois terminé il remonte les sources dans le gestionnaire de sources. Il met à jour le modèle de l'application, qui se voir enrichi de la référence des sources dans le gestionnaire de sources.
  • L'operation manager va déployer, monitorer le service, et se conformer aux contraintes posées sur le service par l'architecte. Le modèle sera enrichi avec l'identification des instances du services mises en production.
  • Dans une itération suivante, l'architecte veut effectuer une mise à niveau de son service, il peut déterminer l'impact de sa mise à niveau, grâce aux informations sur les instances de services contenues dans le modèle.

Cet exemple illustre le fait que dans Oslo le point de focalisation est le modèle. Ce modèle contient toutes les informations dont ont besoin les différents intervenants dans la vie d'un applicatif.  Pour être sûr que tous les intervenants utilisent bien le même modèle, celui ci est entreposé dans un référentiel central.

Modèle, vous avez dit modèle ?

Comme nous l'avons indiqué précédemment, Oslo considère les modèles comme étant le point central du système. Mais qu'est qu'un modèle ?

Deux acceptions du terme sont valides :

  • Une représentation d'un système basée sur une abstraction (ou simplification) visant à réduire la complexité générale. C'est la définition classique, qui est également celle utilisée dans la documentation Oslo.
  • Le M du pattern MVC. En clair, les données qui peuvent être vues (et/ou manipulées) sous différentes perspectives. C'est ainsi que Don Box l'a présenté dans une de ses sessions. Ce qui est cohérent si l'on s'en référe au scénario ci-dessus.

Quelle que soit la signfication retenue, la conception du modèle d'application reprendra des données génériques, et contiendra autant de sous-ensembles de données spécifiques à chaque intervenant dans le cycle de vie de l'application. Le schéma suivant montre un exemple de conception d'un modèle d'application.

ApplicationModels

Une des qualités des modèles dans Oslo, est leur capacité a être représentés sous la forme de données. Et c'est sous cette forme qu'ils sont stockés dans le Repository. Comme pour le pattern MVC, le modèle peut être vu sous plusieurs formes qui sont : 

  • Une forme graphique. Ce sont des éditeurs comme Quadrant qui permettent d'éditer un modèle.
  • Des tables et colonnes dans une base de données relationnelle (Repository)
  • Langage "M". Un langage orienté données et non objet.
  • XAML, le format natif des modèles.

Remarque sur XAML: Bien que XAML soit surtout associé à WPF, il est en fait un langage de factory, i.e. qu'il permet de spécifier comment un objet composite doit être construit. Et c'est comme ça qu'il est utilisé dans WPF, en décrivant la composition des applications et celle des fenêtres.

Do you speak "M" ?

Avec Oslo, on a vu arriver les Mg (ou encore MGrammars) et en particulier le langage "M". C'est une abstraction de l'accès aux données. Ce langage permet de générer des instructions SQL. Et il ne fait que ça. 

Voici un exemple reprenant la définition des données génériques du modèle d'application montré dans le diagramme ci-dessus:

module Hamid
{
  type ApplicationModel
  {
    ApplicationID : Text; // L'identifiant de l'application
    Version : Text; // La version de l'application.
  } where identity(ApplicationID);

  // Extents
  ApplicationModels : ApplicationModel*;
}

Le type ApplicationModel est défini, pour lequel on indique que la clé primaire (PK) est le champ ApplicationID.  Particularité de "M". Lorsqu'on définit une collection du type créé, on indique à "M" de créer une table dans le Repository. La table créée s'appellera ApplicationModels dans le base de données Hamid. 

Voici pour info, le SQL équivalent :

set xact_abort on;
go

begin transaction;
go

set ansi_nulls on;
go

create schema [Hamid];
go

create table [Hamid].[ApplicationModels]
(
  [ApplicationID] int not null,
  [Version] nvarchar(max) not null,
  constraint [PK_ApplicationModels] primary key clustered ([ApplicationID])
);
go

commit transaction;
go

Un des interêts de ce langage est de fournir un exemple d'abstraction qui se focalise sur l'intention et non la façon d'accomplir. En clair de montrer à quoi peut ressembler un DSL.

J'aborderai les Mg dans un post prochain.

Oslo, "hic et nunc" ?

Voici à quoi correspond Oslo, aujourd'hui et maintenant :

  • VPC "Dublin" et Oslo : Dans cette VPC  on trouve :
    • le serveur "Dublin" qui correspond au nouveau serveur d'applications de Microsoft. Il pourra servir d'hôte pour des services WCF ainsi que des applications WF. La particularité de "Dublin" est d'être le premier élément de la plateforme serveurs Microsoft à être "Oslo compliant". Cela veut dire qu'il sera capable de hoster une application (WCF ou WF) à partir des modèles présents dans le Repository.
    • Quadrant : Qui est l'éditeur grahique de modèle.
  • SDK Oslo 1.0: Le SDK est à télécharger, et rendra les choses suivantes disponibles :
    • Les compilateurs Mx et Mgx.
    • IntelliPad, un éditeur trés basique.
    • Des éléments de documentation.
    • Un template de projet "M" dans Visual Studio.
    • Des Tasks pour la compilations de MLanguages. 
    • Un script de création d'un Repository local.

Pour ma part, je ne me suis intéressé qu'au SDK, dans la mesure ou je n'aime pas travailler dans une VPC. 

Finalement, quel intérêt ?

L'interet majeur d'Oslo est la normalisation de la plateforme, en la rendant "model centric". Les modèles ne sont pas nouveaux, et modéliser est devenu une activité courante. Le problème, comme toujours, reste la disparité des formats de modélisation. Il y a bien UML, mais il reste cantonné sur l'activité de développement. Pour la capture des besoins, les uses cases et pour la partie opérationnelle, il est insuffisant. Donc proposer une solution qui intègre les modèles tout le long du cycle, est plus qu'intéressant. Toutefois, chaque métier du SI  ayant ses besoins propres, l'unification n'est ni évidente, ni triviale. D'ou l'utilisation des DSL. Ils vont permettre de conserver une expressivité (je préfére expressiveness) et des métaphores propres à capturer l'intention des utilisateurs, tout en permettant la génération de modèles sous un format unifié. Pour l'implémentation des DSL, Oslo propose les Mg (Les langages basés sur la MGrammar).  Ils sont assez simples à mettre en oeuvre bien que fonctionnellement fruste (ANTLR reste la référence). On peut aussi s'intérroger sur le fait que les DSLTools du même éditeur n'aient pas été utilisés.

Un des autre intêret est que si Oslo arrive à atteindre les activités de capture des besoins et de spécifications fonctionnelles, il sera possible de tracer les features jusqu'aux instances d'applicatifs en production. Les études d'impacts et la remontée de statistiques seront grandement simplifiées.

L'objectif ultime d'Oslo est ni plus ni moins que de revoir la façon de faire des applicatifs, et de redonner la part belle à l'intention. Les applications ne seront plus codées mais décrites, sous la forme de modèles et au final sous la forme de données (le fameux "Code as Data"). Mais avant de jeter les compilateurs aux orties pour se mettre à développer sous la forme de fichiers XAML, il y a encore un monde. Le mode déclaratif marche pour des applications de types WPF, WCF ou WF, en clair là où la composition est naturelle. Mais pour du code "classique", il faudra passer les compilateurs, les générateurs de code ou alors les DSL.

Finalement si Oslo continue a être développé, si la liste des produits Oslo Compliant (Windows Server, SQL Server, IIS, BizTalk, etc.) est étendue, si un modèle "normalisé" d'application est fourni et si l'ergonomie est au rendez-vous,  ça peut le faire. Mais ça fait beaucoup de "si" et un immense "quand".

Technorati Tags: ,,,,,

Classé sous , , , ,

Hello World!

C'est la formule consacrée pour tout premier programme et elle m'a paru appropriée pour un tout premier post.

Bonsoir (il est 01:03), mon nom est Hamid Moutawakkil. Je travaille actuellement pour un centre de compétences Microsoft basé à Paris, au sein de la cellule architecture. J'y tiens la fonction d'architecte logiciel et de leader technique SOA.

Je tiens à présenter mes petits camarades, parce que je suis content de faire partie de cette équipe d'une part, parce que ce sont des bons d'autre part, et aussi parce que  je reproduirai certaines de nos discussions dans ce blog. Autant que vous les connaissiez. Les voici donc :

- Arnaud Cleret : Directeur technique (ze boss!!), architecte et premier MVP BizTalk en France (total respect!!). Il a la curieuse manie d'habiter Marseille et de travailler à Paris. Ses autres particularités sont : la modestie, un savoir opérationnel encyclopédique et ... une tête rasée. 

- Guillaume Belmas : Architecte, leader technique Industrialisation et MVP Team System. Champion du monde de l'Imagine Cup, marathonnien, plongeur deuxiéme niveau. Court sur patte, mais un orateur hors pair.

- Sebastien Monteil : Architecte, leader techique DotNet. S'il y en a un qui sait comment TFS fonctionne, c'est bien lui. Sa particularité est d'avoir un portefeuille débordant de livres anglaises, de dollars américains et de tickets restaurant.

- Stephan Coquelet : Architecte, leader technique Collaboratif. Un mec bien, fan de Farscape, et amoureux comme moi de Aerin Sun (Claudia Black). Il est également actionnaire principal de M&M's :). Hédoniste émérite.

- Dominique Quilgars : Architecte, leader technique Collaboratif. Un titan discret. Fraichement papa. 

- Valentin Billote : Architecte, as du dotnet et du IL, de Silverlight et qui développe un moteur de rendu 3D. Egalement MVP.

- Bruno Saint Germain: Architecte, spécialiste Silverlight. Ancien champion de france de volley-ball. Grand mélomane devant le Créateur.

- Romain Couturier : Architecte, fraichement arrivé dans l'équipe, vieil ami de la méthodologie SCRUM.

Les sujets qui m'interessent et que je serai amené à aborder dans ce blog sont  :

  • Architecture logicielle.
  • BizTalk.
  • SOA.
  • ESB.
  • DSL.
  • Outillage de la qualité logicielle.
  • AOSD et AOP.
  • Méthodologies.
  • Software factories.
  • Comment intégrer les Aspects dans DotNet.
  • Java.

Et également, comme je l'ai déjà indiqué, les conversations entre architectes qui sont suffisamment intéressantes pour montrer comment notre équipe fonctionne.

Et voila, je suis au bout de mon premier post. Pas sorcier finalement.

A bientôt.

HM.


Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01