Think Service - Latest Comments

Re: Le principe des DTL avec TIBCO

teivah — Thu, 12 Feb 2015 16:25:18 -0000

Je ne parlais pas de ProcessMonitor.

Re: Le principe des DTL avec TIBCO

MJ — Thu, 12 Feb 2015 10:43:15 -0000

"Mais pour publier votre message, vous avez bien besoin d’un service publishLogMsg(). Et ce service doit pouvoir être appelé non pas de manière asynchrone mais bien de manière synchrone."
Pas du tout d'accord. Cf. TIBCO BWPM

Re: Le principe des DTL avec TIBCO

Charles.w — Sat, 03 Jan 2015 08:36:24 -0000

L'approche de Tibco (sur la branche BW5) est une approche très orientée "intégration" & "orchestration de process"...plutôt monolithique par essence...

Le problème principal de cette approche, c'est qu'elle a une granularité trop importante pour nombre de points :
- quid des petits process utilitaire que l'on utilise tout le temps ?
- quid des connectiques qui évoluent dans le temps ?
- quid des rejeux partiels (lorsque j'ai juste la dernière interface d'un process qui plante, alors que toutes les étapes précédentes ont été validées et ne peuvent pas être annulées) ?
- ...

L'approche suivie par IBM et désormais Tibco sur les dernières versions de Business Works consiste à réduire cette granularité afin de pouvoir proposer des composants autonomes pouvant être réutilisés & upgradés facilement. Ceci permet d'adresser nombre des points mentionnés précédemments, mais nécessite d'avoir une vraie approche orientée service...

Par ailleurs, concernant la gestion des dépendances et des montées de version, avec cette approche, ce n'est plus un problème : deux (resp. n) versions d'un même service peuvent cohabiter en parallèle à condition que les process appellant aient connaissance des versions des process appellés qu'ils supportent à minima et que les interfaces des composants appellés ne subissent pas de régression...un peu comme ce que préconisait en son temps l'équipe autour de Java Business Integration (JBI)...

Enfin, concernant le problème de déploiement, dans JBI, pour faire simple :
- 1 composant (au sens de cet article) = 1 Service Unit (SU) avec un descripteur précisant ses dépendances
- il est possibles de grouper plusieurs SU dans une Service Assembly (SA)...charge au conteneur JBI de les installer dans l'ordre (et donc charge au conteneur de trouver comment casser les cycles de références...mais ceci est un autre problème)

Avec ce mécanisme - et pour revenir au problème de montée de version - si une SA contient une version plus récente d'une SU déjà déployée, pas de soucis :
- le nouveau service ayant installé cette SU utilisera cette SU
- si un ancien service utilisant une expression régulière matche la version de cette nouvelle SU, il l'utilisera et migrera sans même s'en rendre compte sur la nouvelle version du service
- si un ancien service a un lien "en dur" vers une ancienne version de cette SU, il continuera d'utiliser cette SU...et il faudra le faire migrer...un jour :-)

Re: Et si la SOA augmentait le couplage entre les applications ?

teivah — Tue, 22 Oct 2013 17:56:27 -0000

Je ne suis pas certain tu aies saisi le fond de l'article :)

Effectivement avec une approche service l'appli consumer (C) ne sera pas liée directement à l'appli provider (P), elle passera par un layer intermédiaire, à savoir le service.

Mais ce que je précise dans l'article c'est qu'avec cette approche, si P devient le master d'un référentiel et que l'appli C souhaite consommer de l'information, il va faire un appel synchrone au service. Si P est indisponible alors C ne pourra accéder à la donnée.

Et donc tu as un couplage entre P et C, même s'il est indirect.

Re: Et si la SOA augmentait le couplage entre les applications ?

Greg — Tue, 22 Oct 2013 03:44:54 -0000

En théorie non, on abstrait complètement les apllications les unes des autres, en intercallant des Services. A n est pas couplé avec B, mais utilise un service de gestion des clients. On nna alors aucun couplage entre A et B uniquement avec le service. B peut devenir C du moment que le service est maintenu. A peut uttiliser le service de B mais le même pourrait être fourni par E.
En pratique, si tu n'as que A et B dans ton SI...

Re: Le principe des DTL avec TIBCO

Laurent Bernard — Mon, 26 Aug 2013 18:10:50 -0000

Très bon article mais on voit bien qu'avec l’approche Tibco on compense avec l'usage de composants autonomes déployés exposant des services asynchrones (ex : supervision fonctionnelle et remédiation) ... mais je ne suis plus objectif ;-)

Re: La revue de presse Think Service : semaine 13

dje — Wed, 03 Apr 2013 08:12:32 -0000

Article intéressant concernant Tibco. C'est assez rare d'avoir des informations sur un éditeur, avec autant de transparence.

Merci pour ces suggestions :)

Re: Le principe des DTL avec TIBCO

teivah — Thu, 28 Mar 2013 18:06:41 -0000

Héhé merci :) En plus t'es un peu le parrain de l'article vu t'étais le premier à qui j'en avais parlé de ces fameuses DTL !

Ouep t'as raison, c'est vrai que pour un premier déploiement c'est assez pratique. Par contre pour le redéploiement d'un framework, je me souviens de quelques galères..

Re: Le principe des DTL avec TIBCO

dje — Thu, 28 Mar 2013 06:51:20 -0000

Ah, depuis le temps que je l'attendais, ce fameux article !! C'est très clair et explicite. D'autant que je partage également ton avis.

A noter qu'avec webMethods, lorsque tu déploies un composant qui fait appel à des composants "framework", le risque d'absence des composants framework est vite levé si tu as bien référencé tes dépendances. L'incohérence sera vue au déploiement, et pas au run.

Vivement le prochain article

Re: La revue de presse Think Service : semaine 09

teivah — Mon, 04 Mar 2013 14:18:32 -0000

Thanks ;)

Re: La revue de presse Think Service : semaine 09

jerome — Mon, 04 Mar 2013 03:32:34 -0000

Au risque de me répéter, c'est bien cool, ces petites revues de presse !! Thks !

Re: Création de la revue de presse Think Service

teivah — Mon, 11 Feb 2013 16:39:30 -0000

Je t'en prie ! Si une semaine t'as un lien à proposer, n'hésite pas ;)

Re: Création de la revue de presse Think Service

jay — Mon, 11 Feb 2013 11:27:00 -0000

Merci think service !

Re: Quiz : IBM Certification 000-667 Architectural Design of SOA Solution

teivah — Wed, 15 Aug 2012 14:59:16 -0000

Oui c'est pas faux :)

La #3 sert à montrer que la couche process elle repose sur une couche de services de haut niveau. Puisque le « SOA designer » a identifié un process commun entre divers départements, il doit pouvoir juger que chacune des étapes doit faire l'objet d'un service réutilisable.
Les autres sont éliminés probablement parce que ce sont des traitements existants et donc qu'ils offrent une plus-value moindre.

Pour la #5, IBM définit dans ce livre blanc http://www.redbooks.ibm.com... (pour réussir la certif il faut lire une bonne dizaine de livres...) un self-service comme un service « user-to-business », c'est-à-dire la possibilité pour un utilisateur d’interagir avec une entreprise (le plus souvent par Internet). Donc en gros t'as un self-service unique pour l’interaction avec l'utilisateur et ensuite l'ESB va te permettre de router la demande vers l'un des 5000 services déployés sur les fronts. Le registre va permettre de faire le lien entre le service exposé (celui utilisé par l'appli web) et le service d'implémentation en question. Puis le cache bien sûr pour éviter un trop grand nombre de requêtes.
Sinon pour les autres choix, il y a certains termes que je maîtrise pas forcément. Notamment extended enterprise ou multiple step information population ^^

Ça te semble cohérent :) ?

Re: Quiz : IBM Certification 000-667 Architectural Design of SOA Solution

Jtouya — Tue, 14 Aug 2012 03:38:51 -0000

10/5 bien sûr ;)

Intéressant ce petit test, mais ça aurait été encore mieux avec des explications sur les réponses. #3 et #5 par exemple.
Merci pour l'info de l’existence de telles certifications

Re: Méthodologie SOA : Partie 1 – Les questions fondamentales

Aleks — Thu, 10 May 2012 08:55:11 -0000

Et cela ne s'applique pas uniquement au SOA. Tout choix technologique devrait débuter par ces interrogations.
Ce qui représente l'étape la plus judicieuse de pré-conception d'un projet. Il est dommage que bon nombre de projets ne respectent pas cette règle à la lettre.

Re: Méthodologie SOA : Partie 2 – Le QUOI

tioufout — Sun, 23 Oct 2011 18:19:11 -0000

Merci de ta visite; j'attends avec impatience le nouvel article.

Réfléchir sur SOA ce n'est pas du narcissisme!

Re: Présentation

Marc — Wed, 22 Jun 2011 17:43:40 -0000

Bonne chance ;)