Je collabore, tu collabores, il s’arrache les cheveux. Le DSI. Dans la liste des outils informatiques aux contours informes, le collaboratif occupe une place de choix.
Les rouages de la rotative collaborent pour sortir les pages du journal, lesquelles sont issues d’une collaboration entre les maquettistes et les journalistes, lesquels collaborent avec leurs contacts pour obtenir de l’information, et la rédigent parfois en collaboration avec d’autres collègues.
Et ce schéma peut être décliné à l’infini : la collaboration, intrinsèquement, est une base essentielle du fonctionnement de l’entreprise. En outre c’est à la mode, à l’époque des réseaux sociaux, on doit collaborer, il faut des outils collaboratifs.
La belle affaire, j’ai déjà ma messagerie, mon agenda, mes documents partagés, ma vidéoconférence qui va m’économiser une semaine de grippe (ou pas), mon MSN-Live-Pidgin-Yahoo pour discuter de bouts de gras, des wiki, des blogs, des forums …. tant d’outils merveilleux que MyCompany.com a mis à ma disposition pour accroitre ma capacité de collaboration.
Mais à force de collaborer, je ne trouve plus le temps de travailler !
Pourquoi ? Parce c’est chronophage. Parce que quand je collabore je produis de la valeur, mais elle reste en dehors du cœur de l’information de l’entreprise, « hors contexte ». Ces outils sont des moyens d’échange indépendants de l’organisation de l’entreprise et de son SI.
Avec Beehive, Oracle tente d’apporter plusieurs solutions à ce problème, que je vous invite à découvrir …

La collaboration dans un contexte d’équipe

L’architecture de données Beehive repose complètement sur la notion d’ « Espace de Travail » : l’utilisateur dispose d’un espace de travail personnel dans lequel il va retrouver sa messagerie, son agenda, etc. Il peut également participer ou gérer des espaces de travail de groupe, associés à des projets ou à des équipes, dans lequel une information collaborative « en contexte » est gérée, et peut être liée à des informations personnelles si besoin.
Mais gérer la collaboration en contexte, cela peut aller beaucoup plus loin : l’idée est de lier l’outil collaboratif à l’outil de production, pour apporter une plus grande valeur ajoutée à la collaboration par une meilleure interaction avec le SI. Ainsi, quand je collabore, j’échange et je produis.

Besoin d’un outil collaboratif intégré au SI

Quelques exemples pour parler plus concrètement :

• dans l’hôpital, le médecin gère son agenda personnel, et l’agenda offert par l’application de gestion du dossier patient
• le médecin de ville qui consulte en établissement, doit aussi gérer plusieurs agendas
• dans l’entreprise, les services de support client communiquent beaucoup par mail, lesquels doivent pouvoir être intégrés à l’application de CRM
• les applications RH qui permettent de suivre le salarié tout au long de sa vie, doivent pouvoir gérer l’évolution de ses droits et appartenance à des groupes, de ses informations de contact (email, etc)
• les pages créées en collaboration sur un wiki peuvent devenir des articles de journal, des notices d’utilisation, des fiches d’information pour le support client … directement accessibles dans les applications métier correspondantes
• les échanges d’email entre les équipes commerciales et les clients sont mieux suivis s’ils sont visibles dans le CRM, en contexte, avec les dossiers contenant le contrat en cours d’élaboration
• les outils de création, CAO, PAO sont souvent reliées à des GED complexes, dont l’utilisateur ne maitrise pas le fonctionnement. Comment collaborer efficacement dans ce cadre ?
• … et votre quotidien alimenterait cette liste bien mieux que moi !
  

Bien entendu, cette intégration doit être transparente et ne pas imposer de changement dans l’utilisation des outils collaboratifs, l’idée n’est pas d’intégrer des fonctions collaboratives aux applications mais bien de lier la plate-forme collaborative au SI.
Et bien entendu, tout cela doit s’appuyer sur des standards.

L’approche SOA

Pour faciliter cette intégration, Oracle a mis le paquet, avec l’intégration DANS Beehive du moteur Oracle BPEL qui permet l’intégration dans une architecture SOA, dans le cadre de processus d’entreprises structurés et managés. Sans installation. Plug and Play (bon, le SOA, c’est pas très « play », mais on se comprend !). Beehive propose des centaines de d’événements internes qui peuvent déclencher des processus applicatifs, par le biais de stratégies. A l’inverse, il peut tout aussi bien se positionner en « client ».

Échanger du contenu

En plus de l’anglais, français et autres langues humaines, Beehive cause également le JCR, comme Java Content Repository. JCR est un standard au doux nom de code JSR-170, qui définit et standardise l’accès à un gestionnaire de contenu. JCR apporte donc de l’interopérabilité dans le monde de la GED et de la gestion de contenu.
Une application compatible JCR (progiciel ou application « maison ») peut facilement échanger du contenu (documents, images, etc) avec Beehive, et Oracle fournit des API pour faciliter l’implémentation dans le cadre d’un développement spécifique.
Ca y est, je dérive encore, il y a tant de points d’intégration dans Beehive … mais venons en au cœur du sujet !

Mais pourquoi diable il y a « REST » dans le titre de l’article ?

J’y viens …
Enfin, l’autre force de Beehive réside dans les API proposées qui permettent une intégration poussée avec les applications du SI ou les ERP. C’est une nouveauté de la version prévue pour l’automne : Oracle, plutôt que le traditionnel SOAP qui peut s’avérer lourd pour certains besoins, a beaucoup travaillé pour proposer des interfaces « stateless » compatibles avec le paradigme REST, nouvelle coqueluche de l’intégration sur le Web.
REST (REpresentational State Transfer) repose sur une idée qu’on ne devrait jamais oublier dans la technologie ; Keep It Stupid and Simple, qui est la version geek du rasoir d’Ockham, l’idée exprimée par Guillaume d’Ockham : « pluralitas non est ponenda sine necessitate » (Les choses essentielles ne doivent pas être multipliées sans nécessité).
REST est une invention de Roy Fielding (le monsieur qui sourit), un des fondateurs d’Apache. Une idée est toujours meilleure si elle arrive simplement au résultat escompté, et l’idée derrière REST est que les Web Services n’ont pas forcément besoin de toute la plomberie de SOAP, WSDL, SAML et tous leurs amis, pour faire communiquer deux applications (en fait REST ne concerne pas QUE les web services, c’est un concept d’architecture global, mais je me permets ce raccourci qui permet de garder l’explication … simple et en contexte).
Fichtrement sensé !
Mon objet n’est pas de vous asséner un cours sur REST, un coup de bingoogle vous amènera à des dissertations bien agrémentées d’images sur le sujet. Mais dans le contexte Beehive, REST est une opportunité formidable de transformer le silo des outils collaboratifs qui occupent des tera-octets dans les SAN, isolés de tout le reste, en une véritable brique du SI.
L’intérêt majeur de REST est sa simplicité. Avec cette technologie, on peut en très peu de temps créer des mashup ou des applications riches « RIA » en utilisant, par exemple, Adobe Flex ou toute autre technologie équivalente. On peut aussi créer des ponts d’intégration avec toute application Web, simplement avec des POST ou GET HTTP qui encapsulent des transactions unitaires de lecture ou écriture de données dans les applications du SI. La relation avec du transactionnel est simple :

• Create   -> HTTP POST

• Read     -> HTTP GET

• Update   -> HTTP PUT

• Delete   -> HTTP DELETE

Les données proprement dites transiteront en XML, en binaire, en ce que l’on veut ! La différence fondamentale avec les services Web SOAP est qu’il n’y a pas de contrat ou de formalisme pré-établi, le client doit donc connaître l’interface offerte par le serveur, il ne peut pas la découvrir. C’est rudimentaire certes, mais dans beaucoup de cas cela suffit. Et dans la mesure ou tout repose sur des simples requêtes HTTP, il n’y a pas d’adhérence à un langage : vive Java, vive C#, vive PHP, vive Ruby … Enfin, sans l’encapsulation d’un protocole complexe, la performance est optimale.
Revenons donc à Beehive : Oracle fournit une implémentation complète d’interfaces REST dans le Beehive Development Kit (BDK) qui sera fourni avec Beehive « next version ». Cette API complètement documentée et riche, permet de quasiment tout contrôler dans une architecture Beehive et donc de construire des interfaces d’intégration et IHM bénéficiant de la facilité d’écriture de REST.
Le BDK propose un vaste ensemble de services permettant de manipuler tout artéfact collaboratif de Beehive : depuis le rendez-vous, l’email, le document, la conférence, jusqu’à l’espace de travail et l’utilisateur. Le développeur dispose de très nombreuses URI qui lui permettent d’appeler simplement ces services, par exemple :

• http://monserveur.com/my/user
• http://monserveur.com/my/workspace
• http://monserveur.com/wstm/list
• …

Chacune est accessible par une des méthodes HTTP, selon l’usage, et renvoie au choix des données XML ou JSON, une notation plus lisible, permettant ainsi leur manipulation dans un programme Java, Flex, C#, Javascript … avec la même facilité. En entrée, les services acceptent également pour les méthodes POST, PUT, DELETE, le même choix du formalisme. Et tout ceci sans paramétrage, il suffit d’indiquer le format utilisé par des balises content-type et accepts.

Bien entendu, la sécurité n’est pas oubliée, d’une part la réponse des services est liée au contexte de sécurité de l’utilisateur concerné, il n’aura donc accès qu’à l’information qu’il peut lire et/ou écrire dans Beehive. En outre les services du BDK supportent l’authentification SSO, HTTP, et S2S (authentification de l’application appelante et délégation de droits).

Pour conclure, le nouveau BDK permet de développer à moindre frais des appels vers les services Beehive pour manipuler tout artefact Beehive : un email un rendez-vous un document une conférence une page wiki …