Question : quel outil pour développer des applications pour le PaaS de Google
Réponse : GPE (Google Plugin for Eclipse)
Google a regroupé un ensembe d'outils de développement logiciel sous forme d'un Plugin pour Eclipse GPE (Google Plugin for Eclipse)
Google Plugin for Eclipse permet aux développeurs Java de rapidement concevoir, construire, optimiser et déployer des applications orientées cloud.
GPE (Google Plugin for Eclipse) regroupe
Google Web Toolkit,
optimisation des performances avec traceur de vitesse (Speed Tracer),
Un mashup (en français application composite) est une application qui combine des services (généralement du contenu multimédia) provenant d’autres applications.
L’application la plus populaire des mashup est la capacité d’un site web d'agréger des cartes géo-localisées provenant de Google Maps dans un site web.
Pour ce faire, on utilise le plus souvent l'objet AJAX et RSS ou ATOM, JSON et une maitrise de JavaScript.
C’est l’intérêt d’utiliser Mashups4JSF pour simplifier la création de Mashup, sans être un expert de ces technologies coté client.
Mashups4JSF est un projet open source qui permet d’intégrer des services mashup dans des applications Java et JSF (RichFaces par exemple).
Le développeurs JSF pourra construire sans grande difficultés des mashup et offrir à ses clients une expérience utilisateurs digne des standards RIA.
D’autre part, Mashups4JSF permet d’exporter les données d’une application sous forme de mashup en utilisant ajoutant l’annotation @Feed à la définition de classe du domaine en question.
Il s’agit d’un nouveau projet (version 0.0.2) sous licence Apache 2.0, qui est apparemment compatible avec Google Apps Engine (demo sur GAE ici).
Prometteur … à suivre
Rappelons que pour se créer un mashup avec Google Maps, il suffit d’utiliser un autre composant déjà à sa version 1.1.3 GMaps4JSF
Nous observons actuellement une concurrence acharnée entre les offres de PaaS (plateforme as a Servce), de Salesfoce.com, Azure, Google App Engine, jusqu’à la nouvelle offre en préparation de Vmware/Spring.
Mais, la maturité de ce marché passe par la capacité d’offrir en native la prise en charge de de l’aspect multi locataire qui sera à même d’attirer les éditeurs de solution SaaS (Software as a Service) vers ce type de plateforme.
Une application SaaS est dite multitenant, si plusieurs organisations clientes (locataires) peuvent exécuter la même application déployée sur la même infrastructure.
La capacité de proposer une solution basée sur une architecture multi locataire (multi-tenant) est un des éléments fondamentaux de la viabilité économique d’une offre SaaS.
Rappelons que le PaaS Force.com (Salesforce ) est l’un des pionniers de ce domaine et que Microsoft a déjà annoncé que son offre PaaS Azure supporte l’aspect « multitenacy ».
C’est au tour de Google d’annoncer le support de l’aspect « multitenacy », comme l’amélioration majeure apporté par la version 1.3.6 de Google App Engine. La fonctionnalité est disponible pour toutes les API de Google App Engine : Datastore, Memcache, et Task Queues..
Google appengine réalise la ségrégation des applications basée sur un espace de nommage (namespace à la XML) unique affecté à chaque client (organisation). Ainsi, on pourra servir avec la même instance d’application les utilisateurs de plusieurs clients. Chaque client ne voit que sa propre copie personnalisée de l’application.
La bonne nouvelle, pour les développeurs, est que cette amélioration est activé par une simple configuration, aucun changement dans les codes sources n’est nécessaire..
Google app engine, cherche ainsi à séduire les éditeurs désireux de migrer, en mode SaaS, leurs logiciels ou d’en créer de nouveaux.
La version 1.2.6 du SDK de Google App Engine est sortie. Les trois principales nouveautés
Il est possible, désormais, d’effacer une application, via la console d’administration, à condition de ne plus utiliser le appId pour une autre application
Il est possible de recevoir des emails (exemple unNom@@yourappid.appspotmail.com) en plus du service déjà existant de l’envoi de email. L’application pourra recevoir des emails, dont les messages seront convertis en requête http.
Les statiques sur les données stockés par votre application sont visibles à travers la console d’administration.
Au même moment Microsoft annonce de nouvelles fonctionnalités sur sa plateforme Azure Mais ceci est un autre sujet
ECIG 2009est co-organisée par Le Groupe Sup de Co La Rochelle, l’Institut pour le Management de la Recherche et de l'Innovation (IMRI) – Université Paris - Dauphine, le CEntre de REcherche en sciences de GEstion (CEREGE) et l’Université de Sousse
Notons que cette conférence, qui traitera en autre du Risk Management des applications en ligne : Nouvelles menaces, fraudes et solutions, SaaS, a le soutien de l’Association Information et Management (AIM) et la collaboration de l’Institut Supérieur de Gestion (ISG) de Sousse, de l’Institut des Hautes Etudes Commerciales (IHEC) de Sousse et de l’Ecole Doctorale en Sciences Economiques et de Gestion de Sousse.
Le 09 octobre : un atelier professionnel sur le « Risk Management des applications en ligne : Nouvelles menaces, fraudes et solutions »
Le sujet s’inscrit dans le cadre de la maîtrise des risques opérationnels lors des échanges en ligne qui est devenu un facteur essentiel de développement des applications distantes.
L’atelier traitera des thèmes suivants :
Risk management (gestion de risque) pour les nouveaux modèles des applications hébergées : SaaS, IaaS, PaaS & cloud
Risk management (gestion de risque) pour le Web Banking
Risk management (gestion de risque) pour les applications distribuées en finance, monétique, monnaie électronique, paiements mobiles, etc.
Risk management (gestion de risque) pour le travail collaboratif en entreprise
Risk management (gestion de risque) pour les Echanges de Documents Informatiques en e-Government
Cet atelier professionnel va s’atteler à lancer le débat entre professionnels et académiciens autour de la thématique de la maîtrise des risques. En effet, le risk management est un facteur essentiel de développement du e-Business.
Au cours des débats j’aurais la chance de « présenter » le modèle SaaS (Software-as-a-Service), et la notion de gestion de risque, réel, imaginaire et perçu.
Cette entrée du Blog a été crée avec le nouvel outil de Google "Google Sidewiki" de commentaire de page web, le commentaire a été attaché à la page en question et a été envoyé automatiquement vers ce blog ...
un effet collatéral ...
j'avoue que j'ai été surpris de la seconde action (que je trouve utile)
Cela mérite une explication :
Explication : sur le site de google
Google Sidewiki est une barre latérale de navigateur qui vous permet d'afficher, d'ajouter et de partager des commentaires sur toute page Web. Cette fonctionnalité est proposée dans la barre d'outils Google.
Lorsque vous ajoutez une entrée dans Sidewiki, vous avez la possibilité de la publier également sur les blogs Blogger que vous avez associés à votre compte Google. Pour ce faire, procédez comme suit :
Cliquez sur le bouton Sidewiki de la barre d'outils Google afin d'ouvrir la barre latérale et de créer une entrée. Vous êtes invité à vous connecter à votre compte Google, si ce n'est pas encore le cas.
Cliquez sur Mes blogs sur Blogger en dessous de votre entrée.
Sélectionnez le ou les blogs que vous souhaitez mettre à jour.
Cliquez sur Publier.
Pour citer la page Web concernée dans votre message de blog, mettez en surbrillance la citation à extraire à l'aide de votre curseur avant de cliquer sur Publier.
Après 3,5 mois de test de la version java de Googgle Appengine, j’arrive à la conclusion suivante : dans la version actuelle (Googgle Appengine SDK installé : la version 1.2.2), il est utopique de penser à migrer sans efforts des applications javaEE actuelles. La migration reste possible, n’est pas triviale.
L’approche PaaS proposé par Google, dans son offre Googgle Appengine, ne privilégie pas la réutilisation des applications existantes pour trois raisons (contrairement à l'approche - à tester- de Spring sur son CloudFoundary).
- Une limitation des API java disponible et du ClassLoader (ce lien pour les classes du JRE et ce lien will-it-play-in-app-engine ?)
- Une limitation des actions possibles (pas de gestion de thread, pas d’écriture dans des fichiers, …)
- Un changement dans l’utilisation des bases de schémas possibles de bases de données
Il est préférable que la première application déployée soit réécrite spécialement pour le Googgle Appengine. Cela permet de comprendre le modèle de programmation et le modèle de facturation, les performances … avant même de penser à la connecter aux autres applications Google.
Pour une première exploration, je conseille d”adopter une approche RAD en utilisant l’un sur des frameworks “nouvelle approche du monde Java EE basé sur le concept de “Convention Over Configuration”.
Graisl & Groovy
Depuis sa version 1.1.1, Grails, est devenu le framework le plus prometteur de cette mouvance. Grails encapsule un condensé de Best practices, des meilleurs framewors (Spring, …) open source, des plugins spécifiques …
Ce tutorial vous permet de saisir la faciliter de création et déploiement d’une application
Créer et déployer votre première application dans le cloud en10 commandes
Alors si vous souhaiter vous lancer dans le cloud en quelques minutes : adopter l’approche 3 G : Grails, groovy & Google Appengine.
Les prérequis
Java JDK installé (de préférence la dernière version )
Grails installé : la version Grails 1.1.1
Goggle Appenigne SDK installé : la version 1.2.2
Avoir un compte Googgle Appenigne
Les étapes simplement (commades …)
grails create-app my_First_3G_app
cd my_First_3G_app
grails uninstall-plugin hibernate
grails install-plugin gorm-jpa
grails install-plugin app-engine
grails create-domain-class com.oxia.att.test.Message (ajouter un attribute message et faire le mapping JPA avec les annotations )
grails generate-all com.oxia.att.test.Message (ajouter le code Groovy et GSP pour personaliser les écrans selon vos besoins)
add to grails-app\conf\Config.groovy - google.appengine.application=" app3g "
go to http://localhost:8080 and test the app locally
Les étapes avec explications
Les étapes de 1 à 5 permettent de créer la structure de l’application
Ce qu’il faut retenir :
Ce qu’il faut retenir, Google appengine n’est pas compatible Hibernate, et que grâce au plugin Gorm-JPA de Grails, l’utilisation des annotations JPA est possible.
Les étapes 8 à 10 : concernent le déploiement
Les étapes 6 et 7 concernent l’application Grails et le code métier, affichage …
L’application doit répondre, bien sûre, à vos besoins métiers, et correspondre à la charte graphique de votre entreprise.
Tous ses aspects peuvent être réalisés avec Grails / Groovy en respectant les limitations de Google app engine.
Espèrerons que la même application soit compatible avec l'offre de Spring sur son CloudFoundary.
Signalons, en fin, que la principale limitation qui va rencontrer votre projet : la définition de votre schéma de persistance (pour ne pas dire schéma SQL) compatible avec BigTable (ce n’est pas du SQL bien qu’on y accède en JPA ou JDO, dison GQL)
Mais ceci est un autre sujet
autres entrés sur le même sujet
10 août 2009 : Un jour d’été pas comme les autres, une montée fulgurante d’une société, crée il y a 5 ans sur la base du consulting autour d’un framework Ioc, pour devenir la référence d’une communauté java toujours en quête d’évolution.
Aujourd’hui 10 août 2009 Vmware le leader incontesté de la vritualisation a annoncé l’acquisition de springSource le leader incontesté de la voie alternative de la communauté Java, du Server Side et java Software
Rappelons les grandes dates pour Spring :
novembre 2002: Rod Johnson publie son réquisitoire contre la voie officielle de J2EE : “J2EE Design and Development”
février 2003: Lancement d’un IOC en open source ‘Spring le Framework’ Juillet 2004: Lancement de SpringSource ‘Spring l’entrerpise’
janvier 2008: Acquisition par SpringSource de Covalent Technologies ( Apache java Software Foundation projects, Tomcat, Axis …)
mai 2009: Acquisition par SpringSource der Hyperic (monitoring de système).
Le but ultime de ce mariage, reste à mon avis, la préparation de prochaine bataille de l’IT: celle du cloud computing ( Qu’il s’agisse de Cloud privé ou public).
Rappelons que les offres cloud de Microsoft et de Google menacent directement le modèle &économique de VMware : Les deux Big Brothers offrent des infrastructures vitalisées par essence. Les offres cloud de Microsoft et de Google parlent en plus directement aux développeurs : .Net C# ou Java, conserver vos habitudes, programmez simplement et déployer facilement. Chère développeur Azure ou Google Appengine : des Vmware ou des Framework (Spring compris…) il n’y guère besoin, le cloud est là pour simplifier votre travaille. ….
Il s’agit donc, d’un autre mariage de raison, entre deux leaders préparant leurs avenirs :
Vmware est focalisée sur la simplification et l’automatisation des infrastructures pour les applications et Spring est focalisée sur la simplification et l’automatisation du développement des applications.
Pour le monde java, c’est une bonne nouvelle si ça aboutit à une vraie simplification des modèles de développement, déploiement et monitoring.
Restons vigilant sur l’ouverture du code de Tomcat, Spring, Grails et Groovy …
d’autre part, VMware, doit batailler pour s’imposer dans le monde des clouds privées ou va t’elle fusionner avec Amazon ?
Il semble que la chance sourit encore à Groovy & Grails.
Après le support total de SpringSource, allant jusqu’à l’acquisition, voilà qu’une tempête se profile de coté de son principal conçurent dans le monde Java, le fameux Jruby.
L’info tombé en ce fin du mois de juillet : les principaux développeurs derrière le projet JRuby ont quitté SUN pour rejoindre la société Engine Yard spécialisée en hébergement Ruby On Rails et se présente comme l'une des plus importantes entreprises de l'écosystème de Ruby on Rails
Les transfuges ont prétexté de l’incertitude autour du sort du projet JRuby, suite à l’acquisition de SUN par Oracle. Le plus difficile pour un Techos c’est l’absence de décision : « Supporte » ou « ne supporte pas » : or Oracle excelle dans l’art de cacher les intentions… , après tout on décidera dans quelques mois, lorsqu’on aurait ouvert tous les cartons de SUN …
D’un autre coté, Engine Yard mise sur l'adoption de JRuby par les développeurs Web Java et qui manquait jusque là d'experts dans ses équipes
Rappelons que Grails, suit le chemin tracé par Rails & Rubby "coding by convention", mais en se basant sur Groovy, le langage dynamique de référence du monde Java.
En privilégiant le concept de « Convention not Configuration », Grails cherche à simplifier le développement des applications Web.
De plus, la capacité d’heberger Garils & Groovy sur le Google AppEngine, leur ouvre de nouvelles perspectives et met en danger les hébergeurs web en générale et Engine Yard en particulier.
Mais, souhaitons que le projet JRubby puisse continuer à avance, la concurrence stimule, et la compétition génère de l’innovation. Et surtout espérerons que la prochaine version de JRuby (1.4) soit livrée à temps : en Septembre.
Finalement, ne pas oublier que la concurrence réelle pour Grails reste l’écosystème Rubby on Rails, qui lui continue son chemin, tranquillement …
Le monde Java a maintenant de bonnes réponses à Ruby en Groovy, Scala, et Clojure et de bonnes réponses à Rails dans Grails...
En ce mois de juillet 2009, un accord, pour sauver les bénéfices de Yahoo, en chute libre depuis quelques mois
Enfin, un accord de 10 ans pour mettre sur les rails le nouveau moteur de recherche de Microsoft BING (et à dieu msn).
Enfin un accord sur les rôles : Microsoft pour la technologie recherche et Yahoo pour la gestion des annonces.
Un accord entre le numéro 2 et numéro 3,
Bing-yahoo est désormais le numéro 2 de la recherche sur le web
Une alternative sérieuse pour les annonceurs face à l’hégémonie de Google dans le domaine de la publicité en ligne.
Quelle serait la réaction du coté de Google ?
et ne me dites pas qu'il a encore deux ans devant lui avant que la fusion des technlogies de Bing et yahoo ne soient effectives.
Google, a déjà lancé des attaques frontales avec Microsoft sur les thèmes de : cloud et Google AppEngine, les appstore, les OS, les navigateurs, les suite bureautique, les outils collaboratives (Wave, messagerie en ligne, messagerie instantanée, Plateform de blog, wiki ..) … Google cherche à mener ses batailles sur le terrain de l’enemi,
Le voilà, attaqué sur son propre terrain, Il va falloir relire les conseils de Sun Tzu.
Rappelons que la guerre est aussi lancée sur le front de la présentation des résultats: trop tabulaire, trop classique, peu précise.
Nous entendons de plus parler de "fact engine" à la place de "search engine",
Ça me rappelle une ancienne bloque sur le CNRS : « on y trouve des chercheurs on, mais on cherche des, toujours, des trouveurs» ..
C’est ce que propose Goggle Squared ou le tout nouveau Walfram Alpha (créateur Matimatica de mon application préféré, lorsque je travaillais sur le théorie du chaos et la modélisation des phénomènes non linaires…, bref le bon vieux temps).
Walfram Alpha est supposé comprendre des questions formulés en langage naturel, il peine à le faire pour le moment, mais espérons qu’il réussisse.. ;
Goggle Squared propose ce type d’information (copié souvent chez Wekipedia)
Car, s’il devient vraiment performant, le moteur de recherche deviendra Le vrai assistant personnel, un moteur d’aide à la décision, de l’internaute : qui l’assistera à explorer, chercher, et trouver ce qu’il souhaite…
Suite à ce rapprochement, il reste une question à régler : à qui appartiendra les données sur le comportement des internautes ?
Ce tutorial a pour but de présenter la démarche à suivre pour déployer une application web Java EE dans la plateforme PaaS de Google : Google appengine.
Pour présenter GAE (Google appengine) : il suffit de pense à un serveur d'applications java capable de supporter une charge importante. Bien sûre, plusieurs API java ont été désactivé, ce qui rend impossible de deployer telqu'elles les applications J2EE classique.
Il permettra de :
- Tester GAE : Faire un premier test du PaaS (Plateforme As A Service) de Google avec java
- Vérifier la courbe d’apprentissage
- Tester les outillages offerts par Google
- Vérifier la qualité des informations présentées par le Tableau de bord : dans le sens vérifier la validité des informations données par le Tableau de Bord (DashBorad) de Google par rapport à des mesures réelles.
Ce tutorial présente une démarche pour passer du monde de développement en local vers l’univers de l’hébergement d’une application dans une infrastructure de type Cloud : Google App Engine. Il couvre les points importants pour créer un compte Google App Engine, le déploiement des versions et le suivi de l’activité de l’application à travers la console d’administration.
Google App Engine est une une plateforme permettant de déployer des applications web Python et maintenant Java, directement dans les Datacenters de Google.
Le découpage des rôles est simple : le développeur crée son application et la déploie dans l’infrastructure de Google App Engine et Google s’occupe de gérer la montée en charge de l’application et facture le temps consommé (après dépassement d’un quota gratuit).
On l’attendait pour le milieu de l’année 2009, mais Google vient de la lancer officiellement au début de second trimestre 2009 : La « déclinaison » java de sa plate-forme Googe App Engine est désormais là.
C’est logique : il fallait réagir rapidement : pour faire barrage à Microsoft Azure.
Google se devait de riposter et proposer une alternative pour les développeurs.
La manœuvre est habile : supporter Java 6 et offrir un plugin Eclipse, permettrait à Google d’élargir la base de développeurs cible.
Google vise ainsi à faciliter la réutilisation de code source des applications existantes et à introduire les langages dynamique de type Groovy…
Pour pouvoir créer un compte Google App Engine, il faut posséder compte email sur Gmail. Ce compte Gmail sera l’identifiant unique à utiliser pour se connecter ( Google a adopté le principe de l'OpenID)
Trois étapes pour créer un compte Google App Engine
ü Demander la création d’un compte le compte
ü Attendre l’arrivée d’un code secret par SMS pour compléter la création du compte GAE
Donner un numéro de GSM, pour recevoir le code d’authentification
En moins d’une seconde j’ai reçu le code du compte par SMS
L’étape suivante consiste à inscrire le code dans la page d’authentification.
Renseigner l’identifiant de l’application
Et le titre.
Ce dernier pourra être changé dans la suite
Enfin, l’application est crée
Application Registered Successfully
The application will use kbdsoft as an identifier. This identifier belongs in your application's app.yaml file as well. Learn more Note that this identifier cannot be changed.
Afin d’éviter le « Hello World » j’ai récupéré une ancienne application simple à partir de mon serveur SVN. J’ai choit une application simple pour tester un seul aspect à la fois. L’application date de 2005, cela me permet de vérifier la capacité de GAE à pérenniser les investissements.
En effet, s’il fallait réécrire toutes les applications avant de les déployer sur le Cloud : le concept n’aura aucune chance de survire au BUZZ.
Il s’agit d’une application Web traitant de l’aspect navigation et MVC. Elle est basée sur
· JSP
· Struts
· Struts Menu
Ce tutorial a pour objectif de « prendre la température » de ce que propose Google dans son PaaS, et de vérifier le prédicat suivant : « les développeurs java vont pouvoir capitaliser sur leurs expériences et utiliser les réflexes et habitudes,
Les aspects avancés ne sont pas inclus : ni base de données, ni Spring, ni Hibernate, ces aspects seront testés dans une phase ultérieure.
Cela permettra de vérifier si « dans les nuages », un développeur Java va se sentir « comme chez soit»
Une fois déployé et ça marche : il suffit d’ouvrir le lien http://kbdsoft.appspot.com/ dans un navigateur web : une application web déployé dans les nuages
Cloud Computing, SOA et Web 2.0 :
Des sujets techniques sur SOA et l'Open Source : de Java & .Net, PHP5, Symfony, à SaaS / PaaS en passant par Azure, google appengine, le BPM, la Modélisation et d'autres sujets du coté du serveur et cloud computing.
Articles
