Noelios Technologies est un éditeur de logiciel, créateur du logiciel open source Restlet Framework, spécialisé dans les technologies Web (Web RESTful, Web Mobile, Cloud Computing et Web Sémantique). Noelios est basé en France, près de Paris, avec des clients et utilisateurs répartis dans le monde entier. Ses activités principales sont les services professionnels, la vente de licences commerciales et de plans de support technique pour le Restlet Framework, ainsi que le conseil en architecture logicielle.

Jérôme Louvel, directeur technique de Noelios, a plus de 12 ans d’ expérience dans le conseil informatique et l’édition logicielle. Il a créé le logiciel open source Restlet Framework en 2005 et dirige désormais les aspects techniques et commerciaux de Noelios Technologies qu’il a cofondée en 2008. Jérôme est également membre du groupe d’experts JSR-311 qui définit l’API JAX-RS, et auteur du livre « Restlet in Action » publié par Manning.

Noelios, qui compte la NASA parmi ses références, reconnaît le savoir-faire d’Aeon Consulting autour de REST et de son logiciel Restlet Framework, et souhaite renforcer avec l’aide d’Aeon Consulting sa présence dans le domaine Aéronautique et Spatial.

> En savoir plus

• 2 et 3 mars : Embedded World à Nuremberg (Allemagne),  le plus grand événement du monde autour des technologies embarquées
• 4 et 5 mars : CeBIT à Hanovre (Allemagne), le fameux événement dédié aux technologies de l’information et de la communication

N’hésitez pas à venir nous rencontrer :

• Contact : David Fairand, au +33 6 61 34 98 17

Dans la lignée du dossier proposé par 01 Informatique, il est donc intéressant de dresser un petit point sur quelques aspects du Cloud Computing.

Sur la maturité des développeurs et architectes Cloud

Les composants des applications Cloud restent dans l’ensemble similaires à ceux des applications Web traditionnelles : les développeurs techniques peuvent donc généralement monter en compétences rapidement sur les solutions PaaS. Cet aspect est renforcé par le fait que les plateformes Cloud proposent des services techniques classiques : persistance des données, hébergement de l’application, authentification et droits des utilisateurs, intégration…

Le manque de recul concerne en général davantage l’intégration d’une application Cloud dans le SI : par exemple, c’est une chose d’envisager l’externalisation d’une application, mais il faut également être prêt à externaliser ses données. En pratique, c’est plus facile à envisager pour des services annexes ou transverses que pour des services au cœur du métier de l’entreprise. Sans oublier les aspects juridiques largement évoqués dans la presse spécialisée…

Sur les difficultés de mise en œuvre

Développement

Cela varie en fonction des solutions. La solution PaaS de Google, App Engine, par exemple, nous affranchit de nombreuses difficultés côté environnements de développement et déploiement puisqu’on utilise Eclipse et des plugins qui permettent de créer des projets et de les déployer dans l’environnement de test local ou dans les nuages en quelques clics. Par contre, l’environnement de test local est très différent de l’environnement de production, ce qui ne facilite pas les tests et la détection de problèmes en amont.

Et surtout, cette solution implique des changements dans la façon de concevoir l’architecture des applications : par exemple, le datastore nécessite d’implémenter les relations entre les objets et les transactions différemment de nos applications relationnelles traditionnelles. Sans oublier les restrictions sur l’utilisation des ressources : délai maximal de 30 secondes par traitement, récupération d’au plus 1000 entrées par requête dans le datastore…

L’offre IaaS d’Amazon, EC2, à l’inverse, permet la mise en œuvre d’architectures plus classiques mais requiert la manipulation de machines virtuelles sur lesquelles sont déployées les applications.

D’où l’intérêt de surveiller le nouvel arrivant dans la course, Cloud Foundry, de Spring (récemment acquis par VMware). Cette offre PaaS, reposant à l’heure actuelle sur Amazon EC2, se veut justement rendre transparente la manipulation des machines virtuelles tout en permettant des développement plus traditionnels que ceux imposés par Google App Engine.

Entre les différentes solutions, IaaS ou PaaS, le match ne fait donc que commencer. Et le manque de portabilité entre elles ne va pas faciliter le combat !

Exploitation

Le dimensionnement est le premier problème majeur. Derrière l’image de l’opérateur de service à qui on confie l’hébergement de l’application avec la garantie du bon fonctionnement même quand d’importantes montées en charge sont nécessaires, on occulte souvent la nécessité – et la difficulté – de déterminer précisément la quantité de ressources dont on a besoin : en termes de requêtes HTTP entrantes ou sortantes, requêtes en base de données, accès au cache, etc. L’estimation de ces métriques n’est pas simple et ne doit pas être négligée : on délègue certaines tâches d’exploitation, mais celle-ci reste à notre charge.

La seconde problématique majeure (et inhérente) est la tarification : de simples tableaux associant des coûts à des quantités de ressources nous sont présentés mais comment les exploiter si on n’est pas en mesure de dimensionner nos besoins ?

Sur le Cloud et son écosystème

Emergence du Cloud Computing

Deux types d’applications ont largement contribué à l’émergence du Cloud Computing : d’abord les RIA (Rich Internet Applications), applications client/serveur sans déploiement sur les postes client et aux interfaces utilisateurs ergonomiques. Puis les applications Mobiles, sur des appareils comme iPhone ou Android. Le succès de l’App Store d’Apple, impressionnant et grandissant encore, ouvre la voie à des applications utilisées par des dizaines ou centaines de milliers d’utilisateurs à travers le monde, il est donc intéressant de pouvoir bénéficier d’hébergements scalables à moindre coût pour les services métier.

Cloud Computing et SOA

A l’instar de cette excellente image humoristique, j’ai lu plusieurs fois que « le Cloud avait remplacé SOA» . Au niveau marketing, peut-être… Mais aux niveaux opérationnel et technique, le Cloud ne remplace pas SOA, il peut au contraire reposer sur la collaboration entre applications et services.

Ce dossier passe en revue les plateformes et outils tout en plaçant en perspective les intégrateurs et offres du marché.

Nous remercions vivement Alain Clapaud et Pierre Tran pour cet excellent dossier, et vous souhaitons une bonne lecture.

Sur la notion de service

La définition de la notion de service fait rarement l’unanimité est c’est là le point de départ des incompréhensions autour de SOA. Je choisirai donc ici une définition que je rencontre souvent :

« un service est un ensemble d’opérations mises à disposition par un fournisseur à l’attention d’un consommateur. Ce fournisseur exécute les traitements invoqués par le client consommateur» 

Cette définition présente plusieurs lacunes. Celle qui m’intéresse dans le cadre de cet article est l’absence de référence à la notion de contrat de service. En effet, dans le cadre d’une démarche SOA, la notion de service n’est pas dissociable de la notion de contrat de service car il est nécessaire de formaliser le lien entre fournisseur et consommateur pour faciliter la mise en œuvre du service et sa réutilisation.

Soyons plus optimiste, on trouve parfois dans les définitions de la notion de service une référence à cette notion de contrat de service, formulée de la manière suivante :

« le contrat de service décrit les opérations invocables du service» 

Cette définition floue est heureusement parfois complétée par des précisions intéressantes :

« le contrat de service décrit les opérations invocables du service, c’est-à-dire la signature de ces opérations et les protocoles réseau utilisables» 

Cette dernière définition a beau être plus claire, elle n’en est pas pour autant complète.

Sur la notion de contrat de service

La notion de contrat de service est – et doit être – bien plus précise. En fait, la signature des opérations et les protocoles réseau ne sont que deux aspects d’un contrat. J’aime assez la décomposition suivante d’un contrat, en cinq aspects :

• Sémantique : signification des opérations et de leurs valeurs de retours, pré-conditions, post-conditions…
• Syntaxe : nom et signature des opérations, c’est-à-dire format des paramètres en entrée et en sortie
• Protocoles réseau : ensemble des protocoles réseau utilisables pour invoquer les opérations
• Protocole de conversation : ordre dans lequel les opérations doivent être invoquées
• Niveau de qualité : Qualité de Service (QoS) et Service Level Agreement (SLA), c’est-à-dire garanties en matière de sécurité, fiabilité, disponibilité, performance…

Maintenant que nous avons clarifié la composition d’un contrat de service, qu’en fait-on ?

Sur la formalisation du contrat de service

Un contrat de service peut être formalisé. Un formalisme commun facilite la mise en place et la réutilisation de services. Il existe différentes formes de formalisation et toutes ne sont pas standardisées mais certaines permettent d’automatiser la prise en charge d’un ou plusieurs aspects du contrat. Par exemple :

• Syntaxe et Protocoles réseau : la formalisation de ces aspects peut être exploitée pour générer les stubs côté client. C’est le cas du WSDL pour les Web Services WS-* ou du WADL pour les Web Services REST (enfin, pour ceux qui ne sont pas contre l’utilisation du WADL dans REST, mais ceci est un autre débat !)
• Protocole de conversation : le BPM, grâce à la formalisation standard BPEL, est un excellent exemple d’exploitation automatisée de cet aspect

Notons que les ESB permettent d’exploiter de manière automatisée l’ensemble de la formalisation de contrats, même si l’aspect Niveau de qualité (voir par exemple les couches concernées de la stack WS-*) est plus difficile à exploiter de manière automatisée et l’aspect Sémantique (voir par exemple UDDI) l’est encore plus.

La consommation des avions s’est considérablement réduite (au cours des 40 dernières années, la consommation moyenne de carburant par passager a diminué de 70 %) à l’instar des autres industries pour arriver aujourd’hui à une consommation d’environ 3,5 L par passager pour 100 km. Ceci contribue à expliquer que les compagnies aériennes achètent tel ou tel appareil pour renouveler leur flotte mais aussi et peut-être surtout pour faire des économies. En effet, les tous derniers appareils consomment moins que leurs prédécesseurs. Aux progrès sur les moteurs s’ajoutent des progrès sur les profils, notamment par l’arrivée des ailerons de bout d’aile « Winglet» . Et dans le cas de l’Airbus A380, l’économie se fait également par le remplacement de deux vols par un seul grâce à sa capacité.

Le coût du kérosène représente jusqu’à 30 % des dépenses d’une compagnie. On comprendra aisément les efforts que l’on doit apporter pour réduire ces coûts que l’on soit une compagnie en exploitation ou en cours de création.

Au fil de ces Carnets de Vol Aerospace, nous allons décrire différentes mesures d’économie déjà mises en place ou encore à l’étude. Toutes les mesures ne dépendent pas des compagnies aériennes. L’approche en descente continue en est une.

L’Approche en Descente Continue (efficacité du vol)

La CDA (Continuous Descent Approach en Anglais) est une technique d’approche plus écologique, d’où son nom d’atterrissage « vert» .


Aujourd’hui l’avion effectue une approche par palier : baisse de la poussée pour descendre et augmentation de la poussée pour se maintenir sur le niveau de vol, ce cycle étant répété jusqu’à l’atterrissage. Cette approche est complètement gérée par les contrôleurs aériens depuis le haut de « l’escalier»  jusqu’à l’alignement final et l’atterrissage :

A la différence, l’approche en descente continue permet de descendre avec des moteurs au ralenti environ 40 miles ou 65 km avant d’atterrir. Une remise de gaz est juste nécessaire les 5 dernières minutes avant l’atterrissage.

De l’altitude de croisière jusqu’au segment final de l’approche, le FMS (Flight Management System) de l’appareil permet d’effectuer l’ensemble de l’approche automatiquement.

Les avantages sont immédiats pour la compagnie et le voisinage des aéroports. En effet, la consommation en kérosène s’en trouve diminuée mais le bruit est aussi bien atténué car les moteurs fonctionnent au ralenti. Il faut également noter que la diminution de la consommation en kérosène est accentuée par le gain de temps engendré.

Les chiffres avancés parlent d’une économie de plus de 150 000 tonnes par an de kérosène, soit près de 100 millions d’euros, une réduction dans le même temps de 500 000 tonnes de CO2 par an et autour de 1 à 5 dB par vol. L’approche en descente continue est une exigence du programme SESAR pour une mise en application vers la fin 2013.

A ce jour, l’approche en descente continue n’a été mise en service nulle part en Europe et aux Etats-Unis en tant qu’approche standard. Des essais sont en cours à Londres, Stockholm, Amsterdam, Paris Orly, Strasbourg et Marseille. Sur ce dernier aéroport, je vous recommande la lecture de la présentation de l’Aviation Civile Française : http://www.stac.aviation-civile.gouv.fr/manifestation/jt2009/comm/JT2009-STAC-Desc-continue.pdf.

Ces tests ont lieu pour l’instant uniquement lors des creux de trafic.

On citera également l’initiative de l’Union Européenne SES (Single European Sky), Clean Sky, FABEC (Functional Airspace Block Europe Central) et NextGen de la FAA aux USA qui vont également vers une généralisation de cette technique d’approche.

On peut s’attendre à des passerelles entre le programme Galileo et le projet SESAR notamment car une des premières applications de Galileo est de permettre les décollages et les atterrissages dans des conditions climatiques difficiles ou sur des aéroports non pourvus des équipements aux sols adéquats. Enfin, Galileo permettra l’optimisation des rotations et des routes.

C’est bien la gestion du trafic aérien en approche qui est bousculée avec l’acceptation par les contrôleurs aériens de nouvelles procédures, de nouvelles habitudes et sans doute une délégation vers l’avion du contrôle d’approche mais c’est à ce prix qu’on fera des économies.

Sources :

• « Getting air Traffic under Control»  by Bryan Walsh (Time)
• « Sesar – Approche continue»  by Burgi Hermann (Federal Assembly – Parliament Switzerland)
• CDA action plan (European Joint Industry)
• « Bénéfices des approches en descente continue (CDA) en matière de pollution atmosphérique»  by Hélène Manzoni (STAC)
• http://www.eforefficiency.com

Le site Web de la revue vous propose un résumé de cet article :

Entre la révélation du projet Chrome OS début juillet 2009 et l’annonce le 19 novembre dernier de l’ouverture à tout le monde de son code source, Google poursuit son agenda technologique en annonçant non seulement la sortie de ses Closure Tools, une suite d’outils pour JavaScript, mais également son propre langage de programmation, Go.

Nous vous souhaitons une bonne lecture en espérant que cet article vous aidera à mieux cerner ces dernières créations de Google.

Idée n°1 : Pourquoi l’iPhone n’est pas qu’un énième gadget

L’iPhone a avant tout représenté une curiosité technologique : malgré une sortie officielle en juin 2007, il a alimenté toutes sortes de mystères sur Internet dès la fin de l’année 2005.

L’iPhone n’est pas le premier appareil ayant permis une connexion Internet Edge puis 3G. Mais il est l’initiateur de l’ère des forfaits de données illimités : ces forfaits ont ouvert la voie à de nouvelles applications réellement connectées.

L’iPhone n’est pas non plus le premier appareil ayant proposé un appareil photo/caméra, une puce WiFi, une puce GPS, un accéléromètre et une boussole. Mais l’iPhone est un bijou technologique car son système d’exploitation, iPhone OS, a défini de nouveaux standards en matière de design et d’ergonomie des applications qui exploitent tous ces composants électroniques. Le Multi-Touch en est l’un des éléments essentiels.

C’est ce qui a fait qu’aujourd’hui, après seulement quelques mois, plusieurs millions de personnes utilisent un iPhone au quotidien.

Idée n°2 : Pourquoi l’iPhone n’intéresse pas que le grand public

Au-delà des intérêts techniques que nous venons de mettre en avant, il suffit de jeter un œil aux statistiques pour se rendre compte de l’impact de l’iPhone : plus de 50 millions d’iPhone, iPhone 3G, iPhone 3GS et iPod Touch ont été vendus dans le monde. Rappelons au passage que l’iPod Touch est également équipé de l’iPhone OS.

Les statistiques de l’App Store, seulement lancé en juin 2008, parlent également d’elles-mêmes :

• 77 pays
• 90 000 applications
• 120 000 développeurs
• Plus de 2 000 000 000 téléchargements dont le dernier quart en moins de 3 mois.

Ces chiffres sont uniques, les plateformes Android et Blackberry par exemple ne connaissent pas (encore ?) une telle croissance. Et ces chiffres ne font que croître. Fait significatif, l’App Store supporte parfaitement cette croissance. Cette impressionnante scalabilité de l’App Store en fait une plateforme internationale redoutable.

Un autre chiffre est significatif : 75% des applications présentes sur l’App Store sont payantes. Ce n’est pas le cas sur les plateformes Android et Blackberry, respectivement autour de 25% et 55%.

De là, il n’y a qu’un pas pour qu’une entreprise souhaite distribuer des applications sur l’App Store, pour des raisons marketing et business. Et quand on sait qu’il suffit d’un seul clic sur l’iPhone pour télécharger une application ou un contenu/service additionnel, gratuit ou payant…

Idée n°3 : Comment les entreprises ont fait leur entrée sur l’App Store

La première année d’existence de l’App Store a vu fleurir des applications de deux types :

• Applications de tous genres réalisées par des entreprises ou des particuliers, qui représentent pour la plupart des adaptations Mobiles d’applications Desktop ou Internet classiques : gestionnaires de tâches, viewers de fichiers, lecteurs de flux RSS, jeux, etc.
• Applications vitrines : souvent très (trop ?) simples, il s’agit d’applications réalisées par des entreprises qui ont simplement souhaité être visibles sur l’App Store. A la manière des sites Web à l’époque de la bulle Internet, où une entreprise se devait d’être présente sur le Web afin d’être visible et « dans le coup» .

L’effet vitrine est très important : lors de nos projets, nos clients nous expliquent souvent qu’ils souhaitent être présents sur la plateforme iPhone mais que pour des raisons de coût, ils préfèrent réaliser une application Web customisée pour iPhone pour ensuite voir s’ils passeront à une application native (en cas de succès de cette première étape). La différence de coût est effectivement souvent justifiée car la réalisation d’une application Web nécessite des compétences techniques souvent déjà maîtrisées dans les équipes : il s’agit des compétences Web classiques, HTML, JavaScript et CSS. Alors qu’une application native nécessite des environnements Apple, une connaissance de Cocoa et d’Objective-C, une licence, etc.

Cependant cette séquence « application Web puis éventuellement application native » n’est pas à considérer de manière logique systématiquement : les applications natives sont plus rapides, plus simples et plus réactives que les applications Web, dont l’IHM et les comportements sont bien souvent une pâle imitation de ceux des applications natives. En outre, les applications natives peuvent bénéficier de toutes les caractéristiques de l’appareil, ce qui n’est pas le cas des applications Web. Or toutes ces différences concernent justement l’essentiel des raisons qui font le succès de l’iPhone : le design et l’ergonomie. Les utilisateurs sont donc très exigeants sur ces domaines. Le choix entre développement d’une application native et d’une application Web doit donc être considéré sous cet angle et pas uniquement sous l’angle du coût.

Et le temps accentue cette tendance. Depuis quelques mois, l’App Store voit fleurir des applications qui exploitent pleinement les capacités de l’appareil : connectivité, géolocalisation, réalité augmentée… L’iPhone n’est plus une simple prolongation de nos ordinateurs de bureau, mais une vraie plateforme à part entière avec ses propres innovations.

Idée n°4 : Pourquoi les entreprises ne sont pas obligées de passer par l’App Store pour distribuer des applications

Il s’agit là d’un point essentiel, sur lequel nous sommes souvent questionnés :

• L’App Store est publique : est-il possible de distribuer des applications dans un cadre plus restreint ?
• L’App Store est soumis à des règles strictes et des contraintes : la principale en est la procédure de review par Apple des applications soumises, qui repose sur des critères ergonomiques, fonctionnels et techniques établis mais pas toujours maîtrisables par le non initié, et qui impose des délais légèrement croissants (il faut compter entre une et deux semaines d’attente pour la validation d’une nouvelle version d’une application).

En fait, pour développer des applications sur iPhone, il y a deux étapes.

La première consiste à s’enregistrer auprès d’Apple comme Registered iPhone Developer. Cela vous permet de :

• Accéder à l’iPhone Developer Center, point d’accès central à toutes les ressources nécessaires : SDK, documentation et ressources
• Développer des applications
• Les tester sur le simulateur fourni : attention, pas même sur votre propre iPhone !

C’est tout mais c’est gratuit ! En particulier : à l’issue de cette étape, vous ne pouvez pas distribuer d’application.

La seconde étape consiste à devenir iPhone Development Program Member. Cela vous permet de développer, tester et distribuer des applications, via un portail dédié et intégré dans l’iPhone Developer Center. En fonction du type de licence que vous choisissez, trois modes de distribution s’offrent alors à vous :

• Distribution App Store : déploiement sur une plateforme internationale et publique d’applications gratuites ou payantes
• Distribution Ad-hoc : déploiement sur une flotte constituée de 100 appareils au maximum, référencés
• Distribution In-house : déploiement sur une flotte constituée de 500 appareils au minimum, au sein d’une entreprise.

Et voici les types de licences :

• Licence Standard : 99$ / an
  • Distribution : App Store ou ad-hoc
  • Peut concerner un individuel (1 développeur) ou une société (une équipe de développeurs)
• Licence Enterprise : 299$ / an
  • Distribution : in-house ou ad-hoc

Plusieurs modes de distribution s’offrent donc à vous. Attention à bien choisir la licence adéquate !

Idée n°5 : Attention, réaliser une application iPhone, ce n’est pas « que » faire du développement logiciel

Les développeurs familiers avec les langages comme C++, C# ou Java arriveront à se familiariser avec l’Objective-C. Mais le développement d’une application iPhone requiert d’autres attentions. L’aspect technique est important, mais les deux aspects suivants le sont tout autant, voire plus :

• le marketing : afin de rendre visible l’application
• l’ergonomie : il y a des règles strictes à respecter afin de passer la phase de validation d’Apple puis de satisfaire les utilisateurs, devenus exigeants en la matière. Il ne s’agit plus seulement de créer une application utilisable, mais de créer une application qui propose une réelle expérience utilisateur. La maxime d’Apple « The ’same old’ is not an option anymore»  est de plus en plus d’actualité.

En effet, nombre d’applications aux traits fonctionnels et techniques irréprochables n’ont pas connu le succès escompté tout simplement car les aspects ergonomie et marketing ont été sous-estimés. Notez que j’entends par « succès»  le fait de rendre riche les développeurs de rendre heureux les utilisateurs.

Cette idée pourrait faire l’objet d’un article à part entière, nous n’irons donc pas plus loin (pour l’instant). En attendant, où en êtes-vous de votre côté ?

Le site Web de la revue vous propose un résumé de cet article :

Le 28 mai 2009, Google a annoncé Google Wave, son outil de communication et de collaboration. Il ne s’agit pas d’une simple application et il n’est pas encore accessible au public mais a déjà la réputation d’être un outil révolutionnaire. Beaucoup d’articles traitent de Google Wave et des concepts associés, et il est difficile de s’en faire une idée claire car ses concepts sont réellement novateurs. D’autant que seulement 25 000 personnes dans le monde ont été invitées à tester le Google Wave Developer Sandbox. Etant l’un de ces heureux élus, je profite de cet article pour vous présenter Google Wave : de quoi s’agit-il exactement, et est-ce réellement un outil révolutionnaire ? Cet article s’inspire très fortement de deux posts que j’ai rédigés sur mon blog à la sortie de Google Wave.

Nous vous souhaitons une bonne lecture en espérant que cet article vous aidera à mieux cerner Google Wave. Notez que cet article a été rédigé durant le mois d’août dernier : depuis, le 30 septembre, Google a rendu accessible le Google Wave Preview à 100 000 nouvelles personnes. Et nombre de ces utilisateurs disposent de 20 invitations à envoyer à leur entourage.

Les Tech Talks sont des conférences gratuites où des experts présentent des techniques avancées de conception et développement permettant d’exploiter au maximum les technologies innovantes de l’iPhone. Ces techniques visent à aider les développeurs à créer des applications plus rapides et plus faciles à utiliser, en améliorant leur conception, leur fiabilité, leur performance, leur interface utilisateur, leur intégration avec le système… Ces sessions sont donc très techniques et destinées à des développeurs expérimentés qui ont déjà réalisé et distribué des applications sur l’App Store.

Cette journée sera également l’occasion de nous rencontrer et de partager nos expériences autour des applications iPhone.

L’iPhone Tech Talk World Tour 2009 est déjà passé à San José, Seattle, New-York et Toronto. Après cette étape parisienne, il passera à Londres, Hambourg, Pékin et Tokyo.

Nous remercions Apple pour cette invitation. Pour plus d’informations sur cet événement : http://devworld.apple.com/events/iphone/techtalks/.