From:	 Stefane Fermigier <sf@fermigier.com>
To:	 lwn@lwn.net
Subject: ObjectWeb conference
Date:	 Tue, 30 Oct 2001 21:46:42 +0100

Hi, 

I was this morning at the first ObjectWeb conference. I think it is a
very promising project in the open source middleware field.

I took the following notes. Unfortunately for your readers, they are in
french.

  S.

Conférence ObjectWeb, ENST, 30/10/2001
======================================

Introduction (Jean-Bernard Stefani, INRIA)
------------------------------------------

  Initiative logiciel libre / open source (GPL/LGPL) qui a pour objectif de
  construire du middleware ("intergiciel" en québequois).

  ObjectWeb veut être à l'intergiciel ce qu'Apache est au serveur Web.

  ObjectWeb est actuellement une structure informelle, qui va bientôt
  se transformer en consortium international abrité par l'INRIA.

  Création fin 1999 par INRIA, FT R&D et BullSoft sur une base de code:
  Jonathan + JOnAS. Intégration de nouveaux composants en 2000 (Joram,
  RMIJdbc) et de nouveaux partenaires (Libelis, Lutris...).

  Le projet est motivé par l'intérêt que représente le logiciel libre pour
  les logiciels d'infrastructure car ces logiciels ont pour vocation d'être
  standardisés et largement diffusés. Il y a aussi des impératifs philosophiques
  liés au libre accès à ce type de code.

  On ne dispose pas encore à l'heure actuelle d'un ensemble suffisamment
  complet et de qualité suffisante en matière d'intergiciel.

  Il y a donc deux types d'objectifs: techniques et communautaires.  Pour ces
  derniers, il s'agit de construire une communauté vivante, pérenne,
  dynamique, similaire à la FSF ou l'ASF. 
  
  Les objectifs techniques sont de suivre les spécifications les plus ouvertes
  actuellement dans le domaines, dont notamment CORBA (CORBA 3.0, CCM), Java
  (EJB 2.0, JDBC, JDO), LDAPWeb Services (HTTP, SOAP, WSDL...). Il s'agit de
  développer une infrastructure logicielle répartie sous forme de composants,
  afin de permettre d'administrer et de faire évoluer au cours du temps cette
  infrastructure. Ceci n'est pas encore universellement établi, il y a donc un
  réel défi technique.

  La couverture fonctionnelle d'ObjectWeb doit inclure notamment des fonctions
  de sécurité et de haute disponibilité / tolérance aux pannes. La base de code
  doit être suffisamment robuste pour permettre des développements de qualité
  industrielle, donc il faut mettre en oeuvre des procédure de contrôle de la
  qualité.

  Concernant la communauté, il faut s'attacher notamment aux questions de
  formation (ObjectWeb peut servir de support pour des cours sur les
  intergiciels dans les universités nationales et européennes). ObjectWeb doit
  fédérer un certain nombre d'efforts (soutien du RNRT et du RNTL, recherche de
  financements de la CE pour attirer d'autres partenaires). Il faut aussi des
  partenaires industriels qui vont utiliser et accompagner le développement de
  la base de code d'ObjectWeb: c'est ce qui s'est passé cette année avec
  plusieurs startups qui ont basé tout ou partie de leur activité autour
  de l'exploitation de la base de code d'ObjectWeb. Plus généralement,
  il y a un travail d'évangélisation afin de faire passer l'intérêt du
  logiciel libre et de la base de code ObjectWeb.

  ObjectWeb est structuré par projets: chaque projet identifie le développement
  d'un composant particulier, il est dirigé par une chef de projet. Ce dernier
  est architecte en chef du composant, responsable des livraisons, et il anime
  les développeurs.

  Le consortium ObjectWeb va être composé de membres qui vont élire un conseil
  d'administration. Ce dernier aura pour rôle de superviser la stratégie
  d'ensemble du consortium et d'élire un comité exécutif qui aura pour charge
  d'animer et de gérer le consortium au quotidien.

  Il y a aussi un collège d'architectes, qui sera l'organe de décision
  technique, qui va décider notamment le lancement de nouveaux projets. Il y a
  actuellement 7 membres de ce collège, les 7 architectes des 7 composants
  actuels d'ObjectWeb.

  En conclusion: il s'agit d'une initiative ambitieuse mais opportune.  Si on
  croit au logiciel libre, il faut compléter l'offre actuelle Linux/Apache avec
  un intergiciel libre.

  "It's fun: join us!" <contact@objectweb.org>

  Question: dimension européenne ? lien avec le W3C ?
  
  Réponse: Lutris est partenaire d'ObjectWeb. Il y a également des contacts
  avec des universités en Europe. Le consortium va tenter de monter un projet
  financé par la CE. En Allemagne, il y a plusieurs initiatives dans le domaine
  du LL, notamment autour de MICO et JacORB qui pourraient être intéressantes
  pour ObjectWeb.

  Question: position par rapport avec JBoss ?

  Réponse: JBoss est le concurent le plus direct d'ObjectWeb. Il y a eu des
  discussion avec JBoss, mais pas de rapprochement prévu. Les ambitions sont
  différente: ObjectWeb n'a pas pour ambition, comme JBoss, d'être seulement un
  serveur d'applications.

  Question: quel est l'impact de la dépendance / Java ?

  Réponse: l'architecture est indépendante de Java, mais le code est développé
  en Java. On pourrait la développer dans un autre langage (C#!). Point de vue
  personnel: Java est un bon langage, meilleur que C++. Il y a un inconvénient
  lié aux éléments de propriété intellectuel que SUN parsème dans ses
  spécifications. Il y a un débat qui fait rage actuellement, qui n'a pas
  encore connu sa conclusion. ObjectWeb considère que les spécifications de SUN
  permettent une implémentation "cleanroom". Mais on ne pourra pas utiliser la
  marque déposée "EJB" ou "J2EE" car ça coûte très cher. J'ai personnellement
  (mais cela n'engage que mois) d'énormes préventions contre le "SUN community
  process" qui est un caricature de processus ouvert.

  Question: comment suivre le foisonnement des standards (Java, CORBA, W3C,
  Microsoft...) sans être un géant de l'informatique?

  Réponse: je pense qu'on peut. Sinon, on a un gros problème. L'évolution des
  infrastructures ne peut pas être dominée par seulement trois entreprises
  mondiales. Mais la communauté du libre a montré qu'elle était capable de
  développer des bases de code avec des couvertures fonctionnelles très larges
  (ex: Linux).


Utilisations industrielles d'ObjectWeb (Gérard Vandôme, INRIA)
--------------------------------------------------------------

  Le développement d'ObjectWeb est financé en partie par les projets: 

    - PEPITA; 
    
    - PAROL (platforme d'applications réparties à objets libres): consolidation
    du code d'ObjectWeb et développement de la communauté;

    - IMPACT (infrastructure et middleware pour plates-formes à composants
    techniques), financé par le RNTL: extension du projet ObjectWeb;
    
  Liens également avec: RNTL ARCAD, PHENIX, MARVEL...

  Les utilisateurs industriels ont besoin de l'open source avec de la qualité
  industrielle. Cela implique du code, des tests et de la documentation.

  JOnAS a des centaines de développeurs et des milliers d'utilisateurs. Il
  est embarqué déja dans de nombreuses applications.

  Ex d'applications industrielles: 
  
    - FT R&D: utilisation dans des projets internes comme CORSICA, PEPITA,
      Continuum, Athos, Ping, Sidrah, Ambiance.

    - Bull/Evidian: offre de support depuis mai 2001.

    - Bull infrastructure et systèmes: offre Linux + JOnAS.

    - Schlumberger: CP8, serveur GSM (?) avec Jonas, Apache.

    - Startups: Expelog (Expershop), Kelua (outils d'optimisation basés sur
      Jonathan), Libelis (serveur J2EE Orcas qui intègre JOnAS, Apache/Tomcat
      et une base de données objets, avec offre produit et services), Lutris,
      Scalagent (en cours de création).

  Exploitations internes:

    - Deutsche Post (application opérationnelle avec 19 serveurs)

    - E-fb2: ReponseNET

    - Compuware

    - High Sierra

    - TeraPort

    - Venetica

    - Ferma (intégrateur pour les telcos)

    - Kovair: offre de "strategic relationship management", utilise JOnAS
      depuis 1999. Ils sont très contents (de la stabilité et des performances:
      JOnAS est 2 à 5 fois plus rapide que JBoss). Utilisent JOnAS avec Jetty.

    - Intelligent Computer Systems (ICS): utilisent JOnAS pour du e-commerce
      (plusieurs applications opérationnelles). "JOnAS est aussi rapide sinon
      plus que BEA. Le bénéfice en terme de marge financière est énorme! On ne
      comprend pas pourquoi JOnAS reste confidentiel alors que c'est le
      meilleur serveur d'application du marché."

Jonathan (Bruno Dumant, Kelua)
------------------------------

  Il s'agit de permettre de construire des ORBs spécifiques à des
  problématiques courantes dans les télécoms: il faut permettre de relier et
  développer des services sur des systèmes de taille et de nature très
  diverses. Il faut supporter des protocoles variés, pas seulement IIOP, et
  supporter aussi le temps-réel.

  Il fallait développer une plateforme permettant de ne pas imposer des
  câblages trop spécifiques.

  Le projet a démaré en 1996 et a été mis en Open Source en 1999.

  Jonathan offre un système de "personnalités", par exemple CORBA, RMI/IIOP,
  JRMI ainsi qu'un toolkit permettant de réaliser un ORB (gestion des
  resources, naming, binding...) suivant des spécifications diverses.

  Rappel: un ORB sert à envoyer des message d'un objet à un autre avec les
  problèmes suivant à résoudre:

    - encodage du message

    - adressage des objets

    - progammation (respect d'API standards)

    - des services (annuaires, transactions, sécurité...)

    - des protocoles de transport, avec la gestion des informations
      contextuelles

    - la gestion des ressources (mémoire, CPU, ordonnancement)

    - le respect des standards

  Les deux personnalités principales de Jonathan sont David et Jérémie.
  Caractéristiques de David:

    - API: CORBA 2.2, RMI/IIOP

    - services: CosNaming, naming, events

    - encodage: CDR

    - identification: IOR

    - protocoles: GIOP 1.0, TCP/IP, RTP, IP Multicast, ou API ouverte

    - resources: pools de buffers et de threads

  Caractéristiques de Jérémie:

    - API: similaire à RMI

    - services: registry

    - encodage: sérialisation

    - identification, protocoles, resources: comme David

  Mais Jonathan est aussi un toolkit à ORB, qui permet de réaliser des ORB
  non-standards propres à chaque besoin. Pour cela, il faut que les différents
  composants soient développés de façon rigoureusement indépendante des autres.

  Cela ne peut marcher qu'à la condition d'avoir un système d'assemblage de
  composants atomiques qui entre en jeu au dernier moment (compilation ou
  runtime), en fonction d'un fichier de configuration. Il n'y a pas besoin de
  recompiler l'application ou l'infrastructure.

  Le futur: 

    - API: intégration de POA (CORBA 2.4), par exemple en récupérant le POA de
      JacORB ; création d'une personnalité pour l'embarqué.

    - services: repositoty d'interface (Jérémie), transactions (JOnAS),
      persistance (JORM), GC distribuée.

    - encodage: objects par valeur (David)

    - protocoles: GIOP 1.2, UDP, SOAP...

    - performances et utilisation du JDK 1.4.

  Question: qui utilise Jonathan ?

  Réponse: utilisateurs universitaires ou académiques (FT R&D).

JORAM (Frédéric Maistre, Scalagent)
-----------------------------------

  JORAM est une implémentation de la norme JMS, qui est un standard pour les
  MOM (middleware orientés messages) asynchrones. Ces spécifications spécifient
  plusieurs modes de communication (publish/subscribe et point to point), ce
  qu'est un message et une API.

  JMS sert à construire des applications distribuées hétérogènes qui englobent
  des organisations de taille importante.

  JORAM implémente JMS au-dessus de la plateforme ScalAgent qui est basée sur
  des agents (!), transactionnelle et totalement distribuée.

  Les "virtual channels" de JMS (objets ConnectionFactory) sont des agents de
  la plateforme ScalAgent.

  JORAM est intégré dans le serveur d'EJB JOnAS, en particulier implémente XA
  et ASF.

  Futur: JORAM 3.0 = réécriture du code avec performances améliorées, accès
  XML/HTTP pour des clients non-Java, variante pour l'embarqué.

  Question: que valent les performances ?

  Réponse: performances similaires aux produits commerciaux. La prochaine
  release sera nettement plus performante.

  Question: qu'est-ce qu'un agent ?

  Réponse: les agents sont des petites entités logicielles très légère. Ils
  communiquent entre eux uniquement par le biais de notifications. Notre
  plateforme à agents a déjà quelques années d'existence. Elle ne sert pas
  uniquement à faire des MOM.

-- 
Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile).
http://nuxeo.com/ & http://portalux.com/ & http://aful.org/