Ozzie parle du futur de M$

c’etait il y a un an déjà et le grand architecte de Microsoft décrivait un plan de route pour M$.

L’acceptation de ce qui se passe (a lire dans le document complet) :
1. The power of the advertising-supported economic model.
2. The effectiveness of a new delivery and adoption model.
3. The demand for compelling, integrated user experiences that “just work”.

j’ai mis en gras quelques éléments.

Opportunitées :

SEAMLESS OS – The operating system as it would be designed for today’s multi-PC, multi-device, work anywhere, web-based world. Enabling you to login using any of your service-based or enterprise identities. Deploying software automatically and as appropriate to all your devices, and roaming application data and settings. Permitting seamless access to storage across all your PCs, devices, servers and the web.

SEAMLESS COMMUNICATIONS – Communications and notifications – from voice to typing to shared screen; from PC to service-based agent to phone. Maintaining continuous co-presence with intimate friends and family; improving the coordination amongst individuals who need to work together by reducing latency and adding clarity through shared context.

SEAMLESS PRODUCTIVITY – Enabling you to create, find and organize documents and data among all the desktops, devices, servers and services to which you have access, and with all the others with whom you need to work, through ‘shared space’ products that are internet service-based, enterprise server-based and directly peer-to-peer. Working within and across homes, small businesses, virtual workgroups and enterprises.

SEAMLESS ENTERTAINMENT – Enabling you to create, store, organize, present, consume and interact with media of all kinds; accessing, caching and viewing it anywhere you like regardless of where the media resides. Gaming experiences that bring two or two million people together across PCs, devices and the web.

SEAMLESS MARKETPLACE – Enabling you to research, find, buy and sell whatever you want through a seamlessly integrated purchase, billing & payment & points, advertising & lead generation & sales management system designed to satisfy the needs of both buyers and sellers.

SEAMLESS SOLUTIONS – Enabling workgroups and businesses to rapidly create and customize any of a broad class of template-driven, semi-structured data-based applications and solutions that “just work” and provide instant value – whether using them from the web, from enterprise servers, or from mobile client PCs.

SEAMLESS IT – Enabling enterprises to seamlessly and cost-effectively manage many of the things they’ve classically done within their data centers – e.g. PCs, messaging, content and applications. The management experience might be wholly within the cloud, or with the cloud seamlessly integrating enterprise server assist.

Ce qu’il faut faire :

a. BASE vs. ADDITIVE EXPERIENCES – In MSN, and in Windows Update and software deployed by it, we have quite a bit of experience with methods and practices for getting innovations to market on a rapid cycle. In the form of a newly combined division, we should consider many options as to how we might bring user experience innovations and enhancements to users worldwide. Specifically, we should consider the achievability, desirability, and methods of increasing the tempo for both ‘base’ OS experiences as well as ‘additive’ experiences that might be delivered on a more rapid tempo. In doing so, we would better serve a broad range of highly-influential early adopters.

b. SERVICES PLATFORM – [...]

c. SERVICE/SERVER SYNERGY – A tension has emerged between our products designed for the enterprise and those for the internet. Exchange/Hotmail, AD/Passport, and Messenger/Communicator are but three examples. All our enterprise clients and servers must interoperate with and complement our internet services. Our functional aspirations are generally “server/service symmetry”, but architectural considerations dictate that different implementations may be required to economically reach internet scale. We must quickly find the best path to achieve seamless user, developer, and administration experiences involving servers and services.

d. LIGHTWEIGHT DEVELOPMENT – The rapid growth of application assembly using things such as REST, JavaScript and PHP suggests that many developers gravitate toward very rapid, lightweight ways to create and compose solutions. We have always appreciated the need for lightweight development by power users in the form of products such as Access and SharePoint. We should revisit whether we’re adequately serving the lightweight model of development and solution composition for all classes of development.

e. RESPONSIBLE COMPETITION – We will compete energetically but also responsibly and with recognition of our high legal responsibilities. We will design and license Windows and our internet-based services as separate products, so customers can choose Windows with or without Microsoft’s services. We’ll design and license Windows and our services on terms that provide third parties with the same ability to benefit from the Windows platform that Microsoft’s services enjoy. Our services innovations will include tight integration with the Windows client via documented interfaces, so that competing services can plug into Windows in the same manner as Microsoft’s services. We will compete hard and responsibly in services on the basis of software innovation and price – and on that basis we will offer consumers and businesses the best value in the market.

Business Division

a. CONNECTED OFFICE – How would we extend or re-conceptualize Office modules to fit in this seamless model of connectedness to others, and to other applications? Should PowerPoint directly ‘broadcast to the web’, or let the audience take notes and respond? How should we increase the role of Office Online as the portal for productivity? What should we do to bring Office’s classic COM-based publish-and-subscribe capabilities to a world where RSS and XML have become the de facto publish-and-subscribe mechanisms?

b. TELECOM TRANSFORMATION – [...]

c. RAPID SOLUTIONS – How can we utilize our extant products and our knowledge of the broad historical adoption of forms-based applications to jump-start an effort that could dramatically surpass offerings from Quickbase to Salesforce.com? How could we build it to scale to hundreds of millions of users at an unimaginably low cost that would change the game? How could we re-shape our client-side software offerings such as Access and Groove, and our server offerings such as SharePoint, to grow and thrive in the presence of such a service? Could these rapid solutions encourage a new ISV ecosystem and business model?

Entertainment & Devices Division

a. CONNECTED ENTERTAINMENT – How can XBox Live benefit from interconnection with other services assets, such as PC-based and mobile-based IM and VoIP? How might both the PC and XBox mutually benefit from a common marketplace? Might PC users act as spectators/participants in XBox games, and vice-versa?

b. GRASSROOTS MOBILE SERVICES –[...]

c. DEVICE/SERVICE FUSION – What new devices might emerge if we envision hardware/software/service fusion? What new kinds of devices might be enabled by the presence of a service?

Bonnes pratiques : Http

Comment bien utiliser le protocole Http : ici
Il y a de nombreuses règles pour faire des sites respectant bien le protocole.

et ici la traduction en français de l’architecture du Web.

OpenWorld : Oracle parle Web 2.0 et mashups d’entreprises

Les éditeurs cherchent toujours a surfer sur les vagues, Oracle ne deroge pas a la règle (Article du monde informatique).

S’inspirant de technologies telles que les blogs, les fils RSS, les wikis et s’appuyant sur des technologies comme Ajax (Asynchronous JavaScript) WebCenter permet de concevoir des interfaces interactives facilitant la navigation au travers de l’information stockée dans les différentes applications et bases de données de l’entreprise. Techniquement, le produit incorpore un framework JavaServer Faces (JSF) et Oracle ADF pour incorporer des composants Ajax, ainsi que des contenus, dans des applications JSF dotées d’une interface riche.

Ne reste qu’avoir l’implementation …
Il est fort probable que se soit une vision Web 2 qui corresponde avec ce qu’ils faisaent avant dans forms, c’est à dire ce qu’il ne faut pas faire.
Cela peut se comprendre car leur ERP est conçu avec une approche à la VB (il y a un historique . Ajax & co c’est une aubaine pour faire passer ce qu’ils aurraient fait pour des raisons historiques, pour de l’innovation.
Reconnaissons tout de même le progrès et le fait qu’ils fassent la promotion de RSS, wiki, Web 2 …

Boursorama fournit un lecteur RSS

Une petite news sur techcrunch annonce la présence d’un lecteur RSS disponible sur le site boursorama.

C’est a ma connaissance le premier site web (non portail générique) a fournir un lecteur rss a leurs lecteurs. Ce n’est pas parce que l’on n’est pas un portail que l’on ne peut pas proposer quelques fonctions utiles aux clients.

LCI, TF1, Le monde … proposent maintenant des fils rss sur leurs sites.

La démocratisation est bien en marche car il s’agit ici de sites grands publics.

Boursorama fournit un lecteur RSS

Une petite news sur techcrunch annonce la présence d’un lecteur RSS disponible sur le site boursorama.

C’est a ma connaissance le premier site web (non portail générique) a fournir un lecteur rss a leurs lecteurs. Ce n’est pas parce que l’on n’est pas un portail que l’on ne peut pas proposer quelques fonctions utiles aux clients.

LCI, TF1, Le monde … proposent maintenant des fils rss sur leurs sites.

La démocratisation est bien en marche car il s’agit ici de sites grands publics.

Nouvelle API d’IBM pour faire des applications ‘Web Oriented’

IBM vient de sortir hamlet, un API pour faire des applications ‘Web Oriented’

Ca partait bien :

What is IBM Servlet-Based Content Creation Framework?

This framework provides an easily-used and easily-understood way of developing Web-based applications. The framework not only supports but also enforces the complete separation of content and presentation. Its simple and elegant design does not hide the familiar underlying servlet infrastructure.

Par contre en terme de solution pour moi c’est raté :

he framework provides a servlet extension called a hamlet. A hamlet uses the Simple API for XML (SAX) to read XHTML template files containing presentation. While the XHTML file is being read, the hamlet uses a small set of callback functions to dynamically add content “on the fly” to those places in the template that are marked with special tags and IDs.

Pourquoi refaire XSL en propriétaire et en moins bien ?

Ils sont partis d’un bon constat, aujourd’hui on utilise des usines a gaz, ils donnent ici une erreur avec l’empilement de classes. La solution me parait mauvaise.

Java, servlet et gestion du cache du protocole http

S’il y a des choses peu expliquées en Java, c’est bien l’utilisation du cache Http !
Les développeurs utilisent des framework qui encapsulent http sans gérer le cache donc personne ne s’en preoccupe.
Ce petit billet est la pour montrer que c’est relativement simple et améliore considérablement les performances des applications.
Pour la théorie le site du W3C est evidement le plus complet et ici un tutoriel sur comment mettre en application de nombreuses options.
Des serveurs comme apache gèrent les caches pour les images et autres élements statiques. Je recommande quand même d’utiliser le mod_expire pour améliorer encore cette gestion.

Maintenant la partie presque jamais géré concerne les pages applicatives.
Admettons que vous developpiez un site de e-commerce, est-il nécessaire d’aller dans la base de donnée a chaque fois que l’on demande d’afficher un produit ? L’argument est généralement oui mais si ca change je veux être sur d’avoir un affichage a jour !”

C’est justement ce que permettent de faire les cahces http quand on sait s’en servir.

je vous propose 2 exemples en java pour illustrer le comportement de protocole.
Personnellement j’utilise Eclipse WTP 3.2, Tomcat 5.5 et java 5 mais l’exemple devrait tourner sur a peu près toutes les plateformes sans mofifications.

Le premier reponse sur l’utilisation du ‘Last-Modifed-Since’.
Lorsque vous générez pouvez envoyer une information au browser pour lui dire de quand date l’information ‘Last-Modified’. Lorsque le browser demande a nouveau cette ressource (ressource = url), il rajoutera dans l’entête ‘If-Modified-Since’. Lorsque vous recevez cette information dans l’entête cela veut dire que le browser a bien en cache l’information et il vous donne la date de modification du document. A vous de savoir si c’est la bonne date ou non. Si c’est la bonne vous repondez par un status particulier dans la réponse : NOT_MODIFIED

Dans l’exemple Java je fais ce qu’il ne faut pas faire, je dis si l’ecart est inférieur a 20 secondes je considère que le browser a la bonne version, sinon je lui fait une nouvelle réponse. Ca a l’interet de pouvoir etre regardé facilement. Dans une véritable application il faudrait une fonction performante pour avoir les dates de dernières mises a jours des ressources, comparer les dates et renvoyer au browser la page que si celle ci a été modifiée.

Premier exemple : utilisation du ‘Last-Modified’ :

//On recupere dans le header le ‘If-Modified-Since’ String httpLastModified = request.getHeader(“If-Modified-Since”);
System.out.println(httpLastModified);
if (httpLastModified!=null)
{
java.util.Date dtHeader = new java.util.Date(httpLastModified);
java.util.Date dtNow = new java.util.Date(System.currentTimeMillis());
long lEcart = (dtNow.getTime()-dtHeader.getTime())/1000; //ecart en ms
if (lEcart>20) // si l’ecart est superieur a 20 secondes
{ // on regenere du contenu
System.out.println(“LastModifed superieur a 20 secondes”);
response.setDateHeader(“Last-Modified”,System.currentTimeMillis());
out.println (“regeneration du document !!!”);
}
else // on considère que le browser a la bonne version
{
System.out.println(“pas modifié !”);
response.setDateHeader(“Last-Modified”,dtHeader.getTime());
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED); // reponse au browser : utilise le cache car la page n’a pas été modifiée
}
}
else
// s’il n’y a pas de date c’est que le browser n’a pas en cache la page (premier acces ou plus en cache)
{
System.out.println(“premier appel”);
response.setDateHeader(“Last-Modified”,System.currentTimeMillis());
out.println (“premier acces !!!”);
}

C’est relativement simple.
Un autre exemple :


String IfNoneMatch = request.getHeader(“If-None-Match”);
System.out.println(“If-None-Match=” + IfNoneMatch );
if ((IfNoneMatch!=null) && (IfNoneMatch.equals(“incache”)) )
{
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
System.out.println (“le browser a bien la version 1 ! on utilise le cache”);
}
else {
response.setHeader(“ETag”, “incache”);
System.out.println (“le browser n’a pas en cache, creation de la page”);
out.println (“La page web en cache”);
}

La différence est que l’on utilise le champ ‘ETag’ et que l’on peut mettre ce que l’on veut dedans. Un version, un nom …
Le browser lors d’un deuxième appel vous demandera de renvoyer la page si elle ne match pas avec celle qu’il a (If-None-Match’).

Ces techniques permettent de d’économiser beaucoup d’argent.
En effet la bande passante diminue beaucoup puisque renvoyer au browser l’instruction ‘utilise ton cache’ ne prends que quelques octets. La réponse est immédiate pour l’utilisateur.
De plus le serveur n’a pas a reconstituer l’information en allant dans 20 tables retrouver les bonnes données. Il faut juste un accès pour dire si oui ou non c’est la bonne version.

Cette technique est permet de bénéficier des performances des éléments statiques alors que les pages sont dynamiques. Tous les sites devraient faire un usage intensif de ces solutions proposées par le protocole http.

Google and BEA in enterprise portal mash-up talks

Un article sur Silicon concernant le rapprochement entre Google et Bea :

Google and BEA are in talks about partnering on a new initiative that will allow organisations to create mash-ups between enterprise portals and applications such as Google Maps.

As part of the partnership BEA will get access to some of Google’s hidden application programming interfaces (APIs), which will allow developers to create mash-ups using a new technology feature in BEA’s WebLogic Portal, called Adrenaline.

[...]

But Chuang said service-oriented architecture (SOA) will be key to businesses being able to embrace these new technologies and ways of working.

He said: “I think there is some critical crossover point that has to happen for the enterprise to experience the same thing. With such tight integration between process and function it is impossible. You are coding to the specs of the business.”

James Governor, analyst at RedMonk, told silicon.com that enterprise software vendors can’t afford not to respond to the threat posed by the likes of Google.

une remarque interessante :

We expect the same kind of experience from enterprise technology as consumer websites

et oui on l’a oublié mais avant c’était le contraire.

Dans l’annonce je suis très déçu de voir que la gestion de RSS est pour plus tard. De qui se moquent-ils ? C’est la base de tous les portails Web 2 et le développement de lecteurs est RSS est simplissime. Ils n’ont plus de développeurs ?

Sur le fond il était evident que les éditeurs allaient disposer de produits pour faire des portails Web 2 rapidement. Ce qui m’etonne c’est ce partenariat avec Google pour avoir de l’intégration avec Bea Portal. D’habitude l’integration des portails est avec SAP, PeopleSoft … et dans notre cas c’est l’omni présent Google. Ce n’est pas un editeur, et il n’a pas de focus entreprises ou particuliers.
Ca reste nouveau comme phénomène.

Technologiquement, ils ont juste découvert les iframes en Html. Ca existe depuis longtemps. Avec du marketing devant ca le fait bien mine de rien !

De la part de Bea qui est très avancé en webservices… c’est un changement que de s’interesser au mash-up. Ils sont très orientés entreprises et vont donc promouvoir cette technique dans les SI des entreprises. Enfi des editeurs seront sponsors de technologies qui marchent !

Non, l’excellence technique, les performances, la simplicité et l’ergonomie, la gratuité (ou quasi) ne doivent pas rester uniquement des réalités pour les particuliers. Les entreprises y auront le droit elles aussi, un jour !

Web Services Backward Compatibility

Un petit debat intéressant sur les problèmes de compatibilité entre les différentes versions de Webservices.

Heureusement pour vous, il y a ici un article sur les stratégies a adopter pour s’en sortir !
Le problème est compliqué :

Application versioning has always been a challenge for the developer community. With the introduction of Web services, this issue becomes even more difficult as developers are dealing with a more distributed set of components that aren’t necessarily under their control.

L’article reste interessant car il pose de vieux et bons problèmes.

Certains sont idenpendants des webservices d’ailleurs, le versionning des schémas est un problème même dans l’architecture REST. Il a juste des solutions un peu plus simple.
La ou est l’erreur importante avec les webservice est ici “distributed set of components that aren’t necessarily under their control“.
Lorsque l’on rend un service il faut publier celui-ci avec documents et schémas Xml. Il a donc sous son contrôle son évolution. Ensuite vous gagnez tous les problèmes de compatibilité avec les nombreuses couches de webservices qui evoluent sans arrets et plus ou moins compatibles entre editeurs/versions de produits…
Reste effectivement la gestion des versions des schémas avec vos données métiers.

Dans une vision REST …

Pour ce qui est envoyé au service : XML ou des paramètres, le service a les informations nécessaires pour faire un traitement avec la bonne version (targetnamespace dans le document xml en entrée) et il peut regarder les paramètres pour voir quelle version est adaptée. Par défaut la dernière. S’il n’y a plus de compatibilité il faut rejetter (ce cas peut avoir de bonnes raisons, par exemple si juridiquement il est obligatoire de transmettre une information en plus dans un document administratif a partir d’une certaine date…) ou pour arreter de maintenant d’ancienne version
En sortie le service doit fournir le service en dernière version et en paramètre quelque part un paramètre pour permettre d’utiliser une ancienne version.

Il ne faut pas oublier ensuite qu’une schéma n’est pas forcement monobloc, il est possible de définir l’adresse séparement … donc peut de schémas sont a faire évoluer. Ensuite chaque schéma utilisé pour le service utilisera ou non telle ou telle version de schéma dédié a la description d’une adresse…

Dans une vision REST et pratique …

Un article d’un expert de Bea explique comment gérer les extensions de schémas ce qui permet de résourdre la plupart des problèmes. Le sens de l’histoire etant généralement l’ajout de données … Donc tant que la structure ne change pas ca n’est pas un problème.
Pour eviter de se tromper sur la structure il suffit de se baser sur les standards actuels qui couvrent déjà un large scope et sont riches fonctionnellement (il existe des normes pour les achats, les ressources humaines, la finance, l’assurance…). Les métiers changent assez peu dans les structures d’informations nécessaires, vos services seront donc stables.
Les utiliser permet de partir sur une base qui évoluent peu et qui prevoit déjà de nombreux cas métiers. Se baser sur les pratiques actuelles de l’entreprises c’est en revanche l’assurance d’avoir des problèmes. En effet un standard se base sur ce qu’il est déjà possible de faire dans un métier donné. Donc si vous partez en spécifique pour en faire moins, n’oubliez pas qu’il est probable que l’entreprise se dirige aussi vers ces fonctions qu’elle n’utilise pas encore … Si c’est parce que vous faites mieux, cela se traite pas extensions.

Et lorsque le métier change vraiement il faut s’attendre a quelques impacts dans le SI avec des questions qui ne sont pas techniques (versionnement de schémas…) mais métiers, peut-on toujours utiliser tel ou tel service avec l’ancienne norme ? Partir de cette question amène des réponses plus constructives et intéressants. C’est la que l’on peut se rendre compte qu’il faut potentiellement modifier l’ancien (il faut peut être extrapoler les informations manquantes, prendre des risques métiers…).
L’approche REST ne poste pas de problèmes techniques, la technologie est simple. Elle ramène assez vite a des problèmes métiers.
L’approche WS-* tournée sur elle même se créé ses propres problèmes, lorsque la technologie est adaptée les problèmes sont avant tout métiers (même si leurs traitements peuvent être compliqués !).

Encore un commentaire sur le forum SOA du monde informatique …

Louis Nauges fait lui aussi ses commentaires sur le forum SOA organisé par Le Monde Informatique.
J’apprécie cette remarque :

Chargé d’introduire la journée, henry Peyret, du cabinet d’études Forrester, a été le premier à donner une définition de SOA qui, selon lui : “Permet à tous les fournisseurs de mettre ce qu’ils veulent derrière SOA”.

Ce n’est pas très etonnant vu que les 3 mots utilisés par SOA sont des mots valises.
Service : c’est quoi un service ? Définition wikipedia :

Un service est une action effectuée par une entité, (personne physique ou morale, entreprise, machine, programme informatique) pour le bien d’une autre, avec ou sans contrepartie. On dit rendre un service. Le terme service a donc un très large champ d’application.

Oriented : ca se passé de commentaire … se mot respire la rigeur mathématique …

Architecture : ce mot va sauver l’expression c’est sur !
Encore un petit appel a Wikipedia :

Étymologiquement, l’architecture se décompose en deux mots grecs : archi (le chef) et tekton (la charpente). Le terme s’applique à plusieurs champs :

  • Tout d’abord, il désigne une discipline qui associe art et science (et philosophie et socio-psychologie et droit et politique… car l’architecte est avant tout le concepteur de notre maniere de vivre et impose ses choix aux usagers de ses constructions) et qui est celle de l’architecte. Cette discipline concerne la conception et la construction d’espaces (que ce soient des villes, des bâtiments, des intérieurs, des paysages, du mobilier, des objets, des espaces virtuels…).
  • D’un autre côté, il désigne également l’étude et la classification des constructions, que leur conception ait été réfléchie ou non.
  • L’architecture navale forme une discipline bien particulière. Elle désigne la conception des embarcations de toutes tailles et catégories. En particulier certains architectes navals se sont spécialisés dans la conception des bateaux de plaisance et de compétition.
  • Par extension, le terme d’architecture est également utilisé pour désigner la conception ou l’acte de concevoir des systèmes d’objets complexes, comme par exemple l’architecture logicielle et l’architecture informatique. Dans ce cas, on fait référence à la structure générale du système.

Avec 3 termes comme ca manipulés par les fournisseurs on est tranquille, ils vont pouvoir créer de nouveaux produits ‘SOA’ pendant encore un certain temps.
Quand on pense qu’il suffirait que les clients arretent de les ecouter pour qu’on ne parle plus de SOA…