Notre équipe a donc mis en œuvre son expérience acquise en matière de développement iPhone afin de rapidement appréhender le kit de développement iPad : nous sommes aujourd’hui en mesure de réaliser vos applications iPhone comme iPad.

Nous sommes opérationnels sur la plateforme iPad au niveau technique, mais également au niveau ergonomique : réaliser une application iPad ne consiste pas uniquement à adapter les écrans d’une application iPhone. L’écran plus grand de l’iPad permet de nouveaux cas d’utilisation et requiert ainsi une nouvelle façon de concevoir l’ergonomie des applications.

L’iPad s’intègre ainsi pleinement dans notre offre de conseil stratégique et d’accompagnement technique autour de la réalisation d’applications mobiles à haute valeur ajoutée.

Vous souhaitez manipuler, voir une application iPad en action ? Mieux comprendre les intérêts de cette plateforme ? Alors n’hésitez plus, contactez-nous.

Avec un tel rythme, il peut être difficile d’avoir le recul nécessaire à la construction d’applications pérennes et évolutives. C’est pour cette raison que nous avons mis à jour notre formation au développement d’applications iPhone afin qu’elle intègre les nouveautés apportées par l’iPhone OS 4.

Vous pouvez consulter le nouveau programme. N’hésitez plus, rejoignez ceux qui nous ont fait confiance et venez vous inscrire à la prochaine session !

Vous êtes passionné par la technique, maitrisez la conception orientée objet et les architectures n-tiers ? Autonomie, créativité, maîtrise de l’Anglais, capacité rédactionnelle et esprit d’équipe sont des qualités qui vous caractérisent ?

Vous maitrisez une ou plusieurs des technologies suivantes ?

• Objective-C/Cocoa pour iPhone, iPad
• Java/Android
• Java/JME pour BlackBerry
• PHP, MySQL

Une aptitude dans l’un des sujets suivants serait un plus :

• OpenGL
• C++
• Telecom
• SIG
• Design d’interface utilisateur

En rejoignant Aeon Consulting, vous participerez à la conception et à la mise en œuvre de solutions innovantes pour nos clients. Au sein d’une structure jeune et dynamique, vous aurez la possibilité de :

• Travailler dans des contextes clients diversifiés
• Participer à des projets innovants et multi-culturels
• Parfaire et mettre en pratique vos acquis
• Développer vos connaissances au contact d’experts techniques et formateurs

Les postes sont basés à Toulouse.

Vous êtes intéressé ? Alors, n’hésitez plus, contactez-nous : jobs@aeon-consulting.fr.

Un de nos consultants, François Goldgewicht, y a présenté un état de l’art sur le Cloud Computing. Vous pouvez télécharger le support de cette session :

Nous remercions les organisateurs de cette journée, riche en partage d’expériences.

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