http://blogs.jetbrains.com/idea/2011/10/play-with-intellij-idea-eap-build-110187/

TeamCity gére SVN, CVS, PerfForce et d’autres repository de code source. Au niveau de l’intégratio avec IDEA IntelliJ, un plugin permet de poster vers TeamCity son code et d’enchainer un commit si, et seulement si, le code compile sur TeamCity. C’est le principe de la compilation differée. Le cas d’usage: un vendredi soir vous terminez de corriger 3 fichiers importants. Vous aimeriez partir en week-end l’esprit tranquille et ne pas casser la compilation de votre logiciel. Grâce à Teamcity vous pouvez alors pré-commiter vos fichiers vers TeamCity. Celui-ci va alors lancer la compilation et si celle-ci passe, enverra vers SVN vos 3 fichiers. Si par contre vos modifications venaient à casser la build ou à ne pas etre compatible avec d’autres mise à jour, alors le serveur mettra de coté votre commit.

TeamCity est administré via une interface Web déployée sur Tomcat. La licence coûte 249 USD. Cela ne me semble vraiment pas cher. En effet, pour faire tourner CruiseControl correctement il vous faudra pas mal de tests, et prendre le temps de comprendre la configuration de CC via le fichier config.xml. D’un autre coté, TeamCity propose une interface Web très claire et simple qui vous fera gagner du temps.

Les ressources:

• Le site de JetBrains TeamCity http://www.jetbrains.com/teamcity/
• Features et Screenshots http://www.jetbrains.com/teamcity/features/index.html

SCA signifie Service Component Architecture. Il s’agit d’une spécification (en ligne ici) qui vise à promouvoir un système découplant l’implémentation de l’assemblage des services. SCA est indépendant du langage. Une architecture de service basée sur des composants permet de fournir un service définit par un ensemble d’interfaces. Des proprietés de données permettent aussi de définir des attributs globaux pour plusieurs services. Par exemple la langue ou la monnaie de l’utilisateur. Un composant SCA est une brique logicielle qui est assemblée dynamiquement par un moteur. Elle utilise un service en entrée et fait appel via des références à d’autres services. Des attributs (les properties ) permettent de configurer le contexte du SCA globalelement. Imaginez un component de type GestionCompte. Celui-ci configure une implémentation GestionCompteImpl, branche des références vers les services CompteDataService et CotationDevisesService. De plus une proprieté « Monnaie » est mise à EURO pour que le compte soit géré en euro.
Un composant SCA est un assemblage dynamique de plusieurs services autour d’un code de base, l’implémentation de références. En s’inspirant de l’injection de contrôle type Spring, SCA permet à un moteur externe de brancher les références des services dynamiquement. Il n’est donc pas de la responsabilité du programmeur qui écrit le component de se lancer dans l’écriture de ServicesLocator par exemple. L’injection s’applique aussi aux properties (la monnaie « EURO »).

Concernant la couche de transport, celle-ci est invisible pour le component SCA. Ce qui permet donc d’utiliser des web-services pour discuter avec d’autres services, mais aussi JMS, Corba ou des appels locaux. C’est un gain de souplesse et d’évolutivité.

Par rapport à Java, SCA supportera des objets simples (POJO). Une implémentation basée sur des EJB sera aussi possible ainsi qu’une implémenation BPEL (OASIS WS-BPEL standard).

Les components SCA sont déployés au sein de ce que la spéc appelle des « Module Assembly ». Les « Entry Points » sont les portes d’entrées du module qui contient un ou plusieurs composants SCA. Lorsque les composants SCA nécessitent des services externes, ceux-ci sont appelés « ExternalServices ». Plusieurs Modules sont regroupés par sous-système pour former une Application.

Le Binding est le système qui permet de brancher et d’assurer la couche transport d’une architecture SCA. Un des postulats de départ est de séparer la partie business logic de la partie transport. SCA supporte les Web Services, JMS, StatelessSession Bean ou encore des procédures stoquées en base. Par rapport aux échanges entre service, l’architecture SCA permet des échanges asynchrones de type « one-way » comme pour envoyer un message, de type callback et de type conversational. La gestion d’une conversation est par exemple une demande de crédit pour notre service bancaire. Plusieurs étapes dans l’échange de message seront nécessaire pour obtenir un résultat.

Pour résumer, les caractéristiques de SCA sont les suivantes:

• la logique d’une application est divisée en composant implémentant des services métiers
• un composant dispose d’intérface orientées métiers et services. Il n’a pas d’intérfaces
  liés au middle-ware

• les composants peuvent être branchés entre eux pour les réutiliser. Cette capacité d’assemblage d’une architecture SCA permet de créer un réseau de services réutilisables
• SCA force une séparation entre les besoins de la personne qui implémente un composant de celle qui assure l’assemblage système des composants.
• SCA peut être implémenté par dessus un grand nombre d’environement middleware.
• Les composants sont implémentés et utilisés de la même manière quelque soit le language ou la technologie utilisée.
• SCA permet une qualité de service en s’assurant que le support des transactions, de la securité et des messages asynchrones est appliqué de manière déclarative et dynamique sans que la programmation
  d’un service force l’écriture ou l’implémentation de briques systèmes. C’est un principe aussi repris par les EJB3.

• Que le composant soit déployé localement ou à distance, il est accedé via ses interfaces métiers. L’assemblage de composants peut s’effectuer à différents niveaux pour permettre une plus grande flexibilité et une meilleure visibilité des composants.
• Une varieté de ressources comme les Web Services, les EJB’s ou les EIS peuvent être modélisés comme des composants distants et utilisés sans avoir connaissance de l’implémentation ou de la couche transport. Cependant certains types de transport restreignent les possibilités de qualité de service supportées.
• SCA supporte différentes technologies pour exprimer les interfaces métiers des composants, que ce soit WSDL ou des interfaces Java.
• Des composants sans interface métiers peuvent être utilisé pour permettre l’accès aux données, en séparant le problème de la persistence des données de la logique métier. Cela facilite aussi le portage de composants entre différents runtimes.
• Les capacités d’infrastructure comme la sécurité et les transactions sont appliqués sur les interactions entre les components (ProxyPattern) plutôt que d’utiliser du code dans le composant. C’est une idée que l’architecture JEMS de JBoss a mis en place avec succès depuis 2 ans déjà. Cela permet de bien séparer la partie métier de la partie infrastructure.
• Les composants applicatifs peuvent être reprogrammés à la volée en déleguant à des composants de type « StrategyPattern » certains traitements. C’est un pas vers les moteurs de Workflow ou les rules engines.
• SCA définit un modèle abstrait pour l’implémentation et un modèle pour l’accès au composant. Le modèle est découplé en différentes implémentations concretes dans une grande varieté de language comme JAVA, C++, BPEL ou des scripts XSLT. SCA essaye d’être intrusif au minimum avec seulement quelques APIs. L’injection des dépendances permet à un composant SCA de ne pas dépendre d’API externe pour retrouver d’autres composants.
• Les objets échangés entre différents composants via des interfaces métiers distantes est définit dans la spécification Service Data Object (SDO)

Sur apache.org le projet Tuscany a été créé pour regrouper 5 projets destinés à fournir une architecture type SOA:

• 1. SCA Runtime for Java (service component architecture)
• 2. SDO 2.0 Runtime for Java
• 3. Data Access Service for Java
• 4. SCA Runtime for C++
• 5. SDO 2.0 Runtime for C+

Tuscany(en français la Toscane en italie) est vraiment au tout début. Pour récuperer l’implémentation de référence il faut la charger via Subversion.

Un exemple commenté d’application basée sur SCA est disponible: http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-sca/SCA_BuildingYourFirstApplication_V09.pdf

La sortie des EJB3 pour Java va permettre une intégration facile de cette architecture. La gestion de la persistence et l’injection de dépendances sont 2 mécanismes puissants dors et déjà disponible avec
la spécification des EJB3 pour Java. Les Sessions Beans simplifiés des EJB3 peuvent servir naturellement de composant (les components dont j’ai parlé au début) comme brique de base. Il est possible
d’injecter des dépendances simplement grâce aux annotations dans un EJB3. Tout ceci fait que SCA + EJB3 semble naturel et plus facile à mettre en place.

En conclusion, SCA est donc une spécification d’architecture qui vise à faciliter l’écriture de composants métiers pour les intégrer dans un containeur global.

Pour terminer, lors de la lecture de la spéc, je suis tombé sur un nouveau barbarisme. Après POJO (plain old java object) j’ai vu dans la section 5.6.1 le mot POX qui signifie Plain Old XML… on arrête pas le progrès.

Allez voir cette page sur le site Ubuntu-fr. Elle localise sur une carte les utilisateurs d’Ubuntu francophone dans le monde. Ce qui est intéressant c’est l’utilisation de la technologie de GoogleMaps. Sur la page http://www.google.com/apis/maps/ vous pouvez vous enregistrer pour utiliser une carte GoogleMaps sur votre site internet. Avec un peu de Javascript il est facile de créer une carte pour localiser ainsi où se trouve votre entreprise et où vous habitez.

Voici quelques exemples trouvés via GoogleMapsMania:

• Heritage Walk montre un tour virtuel de la ville avec photos et descriptions des lieux remarquables.
• JamBase vous montre sur une carte les concerts programmés ce soir.
• Plus proche de l’actualité et moins amusant: KatrinaShelter est un site qui permet à des volontaires aux USA de proposer un hébergement pour les victimes de Katrina
• Vue satellite de la Nouvelle Orleans après le passage de Katrina

On arrête pas le progrès: en fixant un bug sur notre logiciel, je me suis aperçu que Log4j est capable de recharger sa configuration régulierement.

Log4j se configure via un fichier XML, un fichier de Properties ou directement dans votre application. Il est possible bien sûr de modifier la verbosité de votre application en effectuant des appels directement en Java. Cependant il n’est pas facile de configurer et d’ajouter des Appenders dynamiquement. La class DOMConfigurator de Log4J permet de charger un fichier de configuration pour Log4J au format XML. Cependant ce fichier une fois chargé, si vous veniez à modifier le fichier, vous devez redémarrer votre application. Et bien non ! La fonction configureAndWatch(String file, long delay) configure Log4J et rechargera le fichier automatiquement toutes les n milliseconds.

Pour plus de détails, voir la javadoc de DOMConfigurator.

Nous sommes actuellement sur un gros projet visant à mettre nos sources chez Collabnet. Brian est venu à Paris pour présenter sa societé et ses équipes et surtout répondre aux questions des différentes équipes. Il a présenté ses produits et les solutions qu’ils proposent. c’est un excellent orateur et je retire ce que j’ai précedemment raconté… Mea culpa. Bref c’est quelqu’un avec du recul, qui a commencé à bosser en tant que WebMaster avec le serveur Web NCSA. Avec d’autres ils passaient leur temps à le patcher, a patch, d’où le nom Apache. On prononce « apachiieu » en anglais à propos, et pas « apacheuu » si vous voulez que vos interlocuteurs comprennent.

CollabNet propose une solution d’hébergement de source code ultra-sécurisée et aussi un ensemble d’outils tels que: bug tracking, forums, mailing-list, project tracker et schedule managment. Via une interface Web, l’utilisateur dispose d’un ensemble d’outil pour travailler en réseau. Pour être plus clair, si vous connaissez SourceForge et bien CollabNet propose la même chose aux entreprises.

D’autre part CollabNet supporte activement SubVersion (SVN). En bref, SubVersion sera le remplaçant de CVS. CollabNet participe à l’effort de la communauté open-source et finance quelques développeurs du coeur du système.

Bref nous avons passé un bon moment, c’était sympa de le rencontrer en vrai.

Les bonnes raisons pour passer de VSS à CVS:

1. Il existe des clients CVS sous Solaris et Linux.
2. CVS est un produit robuste, open-source,libre et sûr alors que VSS est connu pour sa capacité à corrompre une base
3. CVS est plus rapide pour les opérations de mise à jour que VSS. Je télécharge notre arborescence VSS en 14 mn alors qu’il me faut 2mn43 pour faire un « cvs checkout »
4. CVS propose différent moyen d’accès réseau: ssh, local, rsh, kerberos alors que VSS utilise des montages SMB (disque réseau) et ne marche pas à distance. Il vous faut un VPN avec des disques réseaux montés sous Windows.
5. Microsoft n’a pas mis à jour VSS depuis fin 2002 alors que les nouvelles versions de CVS pour fixer des bugs ou des problèmes de sécurité sont mise à jour régulierement.
6. Lorsque CVS est utilisé avec l’éditeur Java IntelliJ IDEA un nouveau panel est ajouté. Il permet de voir en 1 clique les fichiers modifiés localement. Plus globalement, CVS est reconnu par casiment tous les éditeurs Java: Netbeans, JBuilder, Forte ou SUN One studio(pareil que netbeans) et Eclipse. Mais pas par VisualAge qui est une antiquité de toute façon.
7. CVS est bien intégré avec Ant dans les makefiles et permet de faire des scripts d’auto-compilation nocturnes (nightly build) ou des scripts de packaging de sources facilement
8. CVS est capable de faire des branches et de merger des sources. VSS est une horreur avec les Labels. Si vous réappliquez le même label VSS sur une arbo, que vous faites ensuite une opération de Checkout en utilisant ce Label, vous ne récuperez pas les fichiers les plus récents mais les premiers qui avaient eu ce Label…
9. CVS et InstallAnywhere de Zerog.com travaillent ensemble à partir de Ant: vous pouvez sortir vos sources de CVS, les compiler et enfin les packager avec InstallAnywhere. Et ce, à partir de Solaris, Linux et Windows.
10. CVS ne coûte rien à l’achat, il faut par contre prendre le temps de bien l’apprendre du côté administrateur, il ne faut pas le jeter en pature aux développeurs qui n’ont jamais utilisé un gestionnaire de sources ou pire qui ont déjà travaillé sur VSS avant.

CVS est un logiciel qui vous ferra gagner de l’argent ou CVS is really a money-maker tool