Altaïde Dev\' Drink 5

Du SaaS au Cloud Computing : Evolution du développement sur le Web Romain Marmot (Directeur R&D, Voluntis) Altaïde Dev Drink #5

A propos de Voluntis/ med passport

Plateforme SaaS lancée en 2002, dédiée à la santé et en particulier à 4 catégories d’usages (PRM - « Patient Relationship Management ») :

Patient Support : gestion de programmes d’accompagnement patient pour le compte d’industriels de la santé ou de payeurs.

Ex: Programme de coaching nutrionnel.

Homecare : organisation des soins à domicile pour le compte des prestataires de services.

Ex: Suivi à domicile de la nutrition par sonde.

Collaborative Care : gestion de protocoles de soins collaboratifs.

Ex: Suivi médico-sportif pour le compte de fédérations ou de ligues.

Telecare : disease management et télémédecine pour le compte de services hospitaliers et du patient lui-même.

Ex: Suivi à distance du diabète de type I.

+ de 350.000 patients suivis par medpassport en Europe.

Table des matières

Introduction & enjeux

Quelques définitions

Cartographie du PaaS

Amazon, Google, SalesForce & Facebook

Do-it-yourself : un peu de pratique

Conclusion

Quelques sociétés qui s’intéressent au PaaS…

Un constat

La notion de Software-as-a-Service est en train d’évoluer rapidement :

Cette évolution a fait émerger de nouveaux concepts :

« Development-as-a-Service »

« Platform-as-a-Service »

Software platform « in the cloud »

« Hardware-as-a-Service »…

Le SaaS est en pleine explosion

Le concept de SOA, et tout autre concept à base de « service », est maintenant largement accepté par l’industrie.

15 à 20% des ISV ont déjà initié des nouveaux développements en SaaS ou fait des acquisitions de logiciels SaaS (source: Saugatuck Technology, 2008).

Le nombre d’API Web, un des vecteurs principaux d’utilisation des SaaS, explose :

De 92 (2005) API commerciales à 761 aujourd’hui. (source: programmableweb.com)‏

Le dernier signe le plus significatif :

Les plateformes de développement de SaaS explosent.

Les enjeux

Pour quelles raisons utiliser le PaaS ?

Développerons-nous tous demain sur les serveurs d’une des 10 plus grosses sociétés du SaaS (Amazon, Google, SalesForce…) ?

Qui va gagner la guerre du Platform-as-a-Service ? (s’il y a un vainqueur).

Table des matières

Conclusion

6 caractéristiques du PaaS

Table des matières

Conclusion

Cartographie de l’industrie « -a-a-S »

Les différentes options ouverte

L’intérêt économique du PaaS

La proposition de valeur du PaaS :

Without PaaS With PaaS SaaS Operation and Maintenance Infrastructure & Hosting SaaS Engineering Overhead SaaS Revenue Modeling Application Engineering ISV PaaS Platform SaaS Operation and Maintenance Infrastructure & Hosting SaaS Engineering Overhead SaaS Revenue Modeling Application Engineering

Table des matières

Conclusion

Amazon – Le Cloud Computing

Amazon avait lancé des 2002 sa première API Web en ouvrant son catalogue produits aux développeurs.

En 2006, Amazon lance S3 puis EC2 :

S3 (Simple Storage Service) est son service de stockage en ligne à la demande.

EC2 (Elastic Cloud Computing) est son service d’infrastructure serveur à la demande :

Environ 10 cents/h d’une instance serveur.

AWS contient aussi d’autres solutions horizontales, « Core Cloud » : e-Commerce ( ECS ), micro-paiement ( FPS ) ou facturation ( DevPay ).

Pionnier du Cloud Computing… Amazon vend-il toujours des livres ?

SalesForce – Le Development-as-a-Service

SalesForce est un pionnier du SaaS et le leader incontestable du CRM on-demand – (25 ème édition de la plateforme au printemps ’08 !)‏

En 2006, SalesForce popularise son langage de développement Apex , évolution de son API de web services (utilisée pour développer les add-ons disponibles via AppExchange )‏

Aujourd’hui : plus de 800 applications professionnelles sur AppExchange

Début 2008, SalesForce lance son service de « DaaS » basé sur :

Apex

Force.com (la « première plateforme de PaaS au monde »).

VisualForce et force.com IDE (basé sur eclipse) - dédiés au développement avec Apex et sur Force.com .

Visual Force

force.com

Bungee Labs : un pionnier du DaaS/PaaS

Google – Les API Web

Lance sa première API en 2002.

Google propose déjà plus de 37 API Web.

Google a lancé en avril 2008 son Google App Engine, outil de DaaS et PaaS.

Google est-il un concurrent des offres PaaS d’Amazon et de SalesForce ou plutôt de Facebook ?

Facebook – Add-on Development facitily

Facebook lance en sa première API en août 2006,

Puis surtout en mai 2007 la Facebook Platform et le FBML

Plus de 26000 applications en ligne en mai 2008.

Aujourd’hui, Facebook lance Facebook Connect pour faciliter l’intégration d’identité avec des applications tierces.

Le business model est évidemment bien différent des AWS Amazon ou de force.com.

Google vs. Amazon ou vs. Facebook ?

Les caractéristiques de la plateforme PaaS de Google :

Pour l’instant, ne supporte que Python

Google ne propose pas de « l’utility » comme EC2 ou S3.

Google cherche à multiplier les applications liées à ses propres outils (à commencer par les Google Accounts).

App Engine est donc destiné aux applications les plus légères, contribuant à l’alimentation de son écosystème social.

Tout comme Facebook, le but ne semble pas de proposer des moyens de développements à la demande, mais plutôt de multiplier les applications qui utilisent et enrichissent les services propriétaires (comptes utilisateurs, social graph ou publicité en ligne).

Table des matières

Conclusion

Do-it-yourself Les outils pour mettre en place une « SaaS add-on development Facility » :

Principe de fonctionnement Serveur Tiers 1. Requête du browser 5. Formatage de la réponse au browser 2. Requête au serveur Tiers Add-on 3. Echange d’objets métiers avec l’API 4. Réponse au serveur SaaS SaaS Platform/API Page Web de l’application SaaS App. Canvas

[WebService(Namespace = "http://tempuri.org/")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

public class Service: WebService

{

[WebMethod]

public User GetUser(string userName)‏

{

// Code to retrieve user profile.

}

}

Web Service API

Technologies employées :

SOAP (ex: SalesForce, Google, Amazon)‏

REST : XML-over-http (ex: Facebook, Google, Amazon) : près de 85% des développeurs optent pour cette technologie, jugée plus simple.

Exemple : SOAP Web Service .Net

Authentification & Session Serveur Tiers 1. Requête du browser 5. Formatage de la réponse au browser 2. Requête au serveur Tiers Add-on 3. Echange d’objets métiers avec l’API 4. Réponse au serveur SaaS Canvas URL + Session ID + Nonce + Signature Session ID + Nonce + Signature Pour la 1 ère connexion : Token obtenu de la page de login, immédiatement échangé contre le Session ID SaaS Platform/API Page Web de l’application SaaS App. Canvas

Authentification & Session

Un système de gestion de l’authentification et des sessions

Gestion de « token » immédiatement échangés contre une Session.

Envoi de paramètre (Token, puis SessionID) par :

Header HTTP (ex: Google Auth)‏

GET/POST (ex: Facebook)‏

Header SOAP (ex: medpassport !)‏

Gestion des credentials et des sessions en base de données ou file system

Exemple : Extension + header SOAP

<soap:Header> <AuthenticationHeader xmlns="http://tempuri.org/"> <AppId> string </AppId> <SessionId> string </SessionId> <Signature> string </Signature> </AuthenticationHeader> </soap:Header>

Authentication Header // Authentication Header public class AuthHeader : SoapHeader { public string ApplicationId; public string SessionId; public string Nonce; public string Signature; }

ApplicationId : ID unique de chaque Add-on, fourni par l’éditeur du SaaS.

SessionId : ID de la session utilisateur, négocié avec le serveur SaaS.

Nonce : « Number Used Once » – contre les replay attacks. (ex : Current Time)‏

Signature : MAC (« Message Authentication Code ») : hash du message utilisant une clé secrete fournie par l’éditeur du SaaS

Exemple d’algorithme pour MAC

parameters = array of key-value pairs representing each parameter

sortedParameters = AlphabeticallySortArrayByKey(loweredParameters)

parameterString = ConcatenateKeysAndValuesWithPipes(sortedParameters) //ex : key1|value1|key2|value2

requestString = Concatenate(parameterString,"|",secretKey)

signature = SHA1(requestString)‏

Session SOAP Extension

public class SessionExtension : SoapExtension

{

public override void ProcessMessage(SoapMessage message)‏

{

switch (message.Stage)‏

{

case SoapMessageStage.AfterDeserialize:

// Look for session header.

SessionHeader session = FindSessionHeader(message);

if (session != null)‏

{

// Validate session.

if (this.ValidateSession(session))‏

{

// Allow call to continue.

return;

}

}

// Fail the call if we get to here. Either the header isn't there or it contains invalid credentials.

throw new SoapException("UnauthorizedUser »); }

}

}

[SessionExtension]

[SoapHeader("Credentials")]

[WebMethod]

public User GetUser(string userName)‏

{}

Comment un dév. utilise mon API ?

// Instantiate service class

//(medpassport being the namespace given to the proxy class). medpassport.Service medpassport = new medpassport.Service ();

// Instantiate header class.

medpassport.SessionHeader header = new medpassport.SessionHeader();

// Set header's parameters.

header.ApplicationId = " myAppId ";

header.SessionId = " 4921354606564 ";

header.Nonce = " 635648595944 ";

header.Signature = ComputeSignature();

// Append header to the service so that it can be reused for any further requests.

medpassport.SessionHeaderValue = header;

// Perform the call.

medpassport.GetUser("jdoe");

Des composants web pour l’intégration des interfaces

Les technologies employées :

URL Rewriting

Pour proposer des url du type http://www.mySaaSapp.com/3rdPartyAddOn .

L’intégration de l’interface tierce dans son application :

Via iFrame + paramètres de requête par GET (plus simple pour la gestion locale des sessions).

Via moteur de requête en background qui va gérer la requête et traiter la réponse serveur.

En proposant son propre langage de mark-up (comme le FBML ou Apex par exemple) : plus grande homogénéité des interfaces utilisateurs.

Les limites en matière de sécurité

La difficulté est de faire respecter une police de sécurité du type :

Ajouter un filtre d’IP pour vérifier que les requêtes viennent bien du serveur SaaS et bloquer tout autre requête.

Toujours vérifier la Signature (MAC) des requêtes.

Toujours vérifier l’unicité du Nonce pour lutter contre les replay attacks.

Ne pas stocker de manière permanente des informations dont la responsabilité appartient au service SaaS principal (via le respect de Terms & Conditions adaptés).

Mauvais exemple : Facebook

De nombreuses applications ne vérifient pas l’unicité du Nonce (« fb_sig_time » dans le case de Facebook). Elles sont donc sujettes aux replay attacks.

Pour s’en convaincre, il suffit de surfer sur la page facebook d’une application utilisant une iFrame et de copier-coller l’url d’appel (contenant en querystring les paramètres fb_sig_time , fb_sig , etc…)‏

Table des matières