Batch vs fil de l'eau

[Jean-Pierre]

Dans l'organisation qui m'occupe le débat est souvent animé dès lors
qu'il s'agit de choisir entre batch ou fil de l'eau. Et ce d'autant
plus que l'incompréhension est souvent grande sur le mode fil de l'eau
(ou continu).

Voici quelques élements qui peuvent aider dans la décision.

C'est aussi un essai pour faire revivre ce groupe où s'échangeait des
idées fort intéressantes.

Jean-Pierre Latour

------------------------------------

1. Mode batch

1.1.Deux types de batch :

- batch de traitement
- batch de transfert

1.2. Batch de traitement

But :
traiter en lots des données

Justification :
le besoin métier ne justifie pas le temps réel - les traitements
peuvent être fortement différés

Exemples :
établissement de factures, de fiches de paie en fin de mois

Caractéristiques :
- gros volumes de données
- phase de préparation sur les données (par exemple triage)
- périodicité faible : au plus la demi-journée
- déclenchement manuel ou planifié sous le contrôle d’un ordonnanceur
- traitement intensif sur les données

Moyens (non limitatifs) :
- un langage 3 GL (Cobol ou Java) étant donné la complexité possible
des traitements
si Java compléter par un framework tel que SpringBatch
- un ordonnanceur
- une infrastucture dédiée

Remarque : si la périodicité est importante (en dessous de la demi-
journée) envisager le fil de l’eau

1.3. Batch de transfert

But :
transférer des données d’une source de données vers une autre source
de données
typiquement d’une base de donnée relative à une application vers une
base de données relative à une autre application (avec éventuellement
export vers un fichier et import de ce fichier)

Justification :
le besoin métier ne justifie pas le temps réel - les transferts
peuvent être fortement différés

Exemples :
déplacement de données de la comptabilité vers la facturation, du
système de pointage vers le système de paie

Caractéristiques :
- volume de données faible à moyen (vu le déclenchement périodique il
doit logiquement
rester limité)
- pas de phase de préparation sur les données (vu les faibles volumes)
- périodicité faible : au plus la demi-journée
- déclenchement manuel ou planifié sous le contrôle d’un ordonnanceur
- pas de traitement intensif mais reformatage possible

Moyens :
- système home made à base de FTP, Cobol, Java, ...
- un ETL (justifié par la recherche de productivité)

Remarque : si la périodicité est importante (en dessous de la demi-
journée) envisager le fil de l’eau

2. Mode fil de l’eau (ou continu)

But : traiter des données dès leur apparition

Le fil de l’eau est une forme de batch à haute fréquence.

Justifications :
- métier : le besoin métier exige que la donnée puisse être consommée
le plus vite possible par une ou plusieurs
applications, sans exiger le temps réel
- technique :
- volonté (ou besoin) de couplage faible entre les applications qui
vise à éviter un échange synchrone via des
APIs de programmation
il s'agit de :
- privilégier le mode message pour éliminer les contraintes sur
les APIs de programmation
(découplage vis-vis-à-vis des interfaces : les évolutions de
l’interface d’une application ont
peu d’influence sur l’interface de la ou des autres
applications)
- privilégier le mode asynchrone par rapport au mode synchrone
(découplage temporel :
l’indisponibilté d’une application n’empêche pas les autres
applications de continuer à
fonctionner = notion de résilience !)
- "accessoirement" volonté de lisser la charge correspondant aux
batchs (pour éviter de dimensionner les
systèmes sur les pointes de charge ou éviter le débord des batchs
de nuit sur la journée)

Exemple :
ce mode de fonctionnement est typique dans les processus métier comme
le provisionning dans les telecoms, le traitement d’un dossier
d’assurance – il procède de la volonté d’augmenter la réactivité des
organisations (comparaison avec la notion de flux tendu dans les
usines)

Caractéristiques :
- données sous la forme de messages individualisés
- message de faible volume
- déclenchement automatique par triggering - recyclage automatique par
queues de backout
- traitement peu intensif

Moyens :
- un langage 3GL supporté, au niveau du transport par un MOM voire un
ESB (qui va reprendre à sa charge et avec peu de programmation
[approche par configuration et déclaration] un ensemble de
fonctionnalités telles que validation, transformation, routage, …)
- le langage Java est fréquemment utilisé pour son support de XML et
de l’API JMS

Remarques :
- de même que le batch, le fil de l’eau peut être utilisé soit à des
fins de traitement, soit à des fins de transfert
- la décision pour le batch ou le fil de l’eau, que ce soit pour le
traitement ou le transfert, doit se faire sur base des besoins métier
et de l’analyse du contexte technique (les systèmes connexes dans la
chaîne complète ) : si le métier peut se contenter d’une périodicité
faible ou si les systèmes connexes sont incapables de travailler eux-
mêmes au fil de l’eau, il ne sert à rien d’opter pour le fil de l’eau
pour le système faisant l'objet de l'étude
- le mode au fil de l’eau correspond à une nouvelle politique en
matière de gestion de l’information : comme dans l’industrie, la
tendance est au flux tendu, en vue de fluidifier les flux et
d’augmenter la réactivité


3. Combiné fil de l’eau et batch

But :
réceptionner les données dès leur envoi et ensuite les traiter par
lots en différé

Justification :
- métier :
- le besoin métier ne justifie pas le temps réel mais exige un
accusé de réception dans un
délai court
- accessoirement, le besoin métier exige garantie et unicité de
livraison (les données sont
bien transmises une et une seule fois)
- le besoin métier ne justifie pas le temps réel sur la partie
traitement – celui-ci peut-être
différé

- technique :
le couplage faible est souhaité ou requis entre expéditeur(s) et
destinataire (voir point 2. Justifications techniques)

Exemples :
réception de déclarations devant faire l’objet d’un traitement interne
pouvant être différé

Caractéristiques :
- envoi des données entre expéditeur(s) et destinataire sous la forme
de messages individualisés
- dès réception envoi d’une notification de réception du destinataire
vers l’expéditeur
- accessoirement, validation de l’envoi par le destinataire et envoi
d’une notification de validation (avec ou non présence d’un relevé
d’anomalie(s)) ou de rejet
- traitement des données reçues en différé par des applications batch
(vers lesquelles sont acheminées les données)

Moyens :
- pour la réception : un MOM auquel est éventuellement adossé un ESB
- au-delà du mode message le frontal de réception peut devoir
supporter le mode fichier (protocoles FTP, FTPS, WS-MTOM, …) – dans
ce cas les données entrantes sont ensuite récupérées par le MOM ou
l’ESB pour la délivrance des notifications et l’envoi vers les
systèmes batch
Remarque : la volonté (ou le besoin) de supporter plusieurs protocoles
en entrée conduit à une complexification de l’infrastructure du
frontal de réception avec la problématique de gestion des
identifications/ authentifications/ autorisations de manière
centralisée
- pour le traitement des applications batch traditionnelles, en Cobol
ou Java, récupérant les données dans des dbs ou des fichiers

[ldu]

Bonjour Jean-Pierre,
Chez nous nous sommes en train d'aborder ce sujet. D'ailleurs merci de
le relancer puisque nous devons encore nous organiser et donc définir
clairement les règles d'utilisation de nos systèmes de gestion de
batch.

Voici les quelques nuances avec ton texte (je reprends au début des
parties de nos analyses):
Définition de "batch" : c'est un enchaînement automatique de commandes
sans intervention d'un opérateur. Un ‘enchaînement automatique de
commandes’ est typiquement ce que tout programme informatique fait.
L’important tient donc dans la non‐intervention d’un opérateur humain
en cours de processus.
Le traitement répétitif est essentiel à la définition de batch. Une
fonction dont le temps d’exécution est très long et utilisée de
manière asynchrone (l’opérateur n’attend pas la réponse, mais sera
prévenu) n’est pas un batch. La définition de batch ne présuppose rien
de l’organisation de la répétition des tâches. Elles peuvent être
exécutées de manière séquentielle, parallèle ou autre.

Temps réel et temps différé :
En temps différé, un batch est exécuté à un temps donné, selon une
plage horaire ou bien sur l’action volontaire d’un opérateur.
L’exécution n’est pas directement dépendante de l’exécution d’un autre
programme utilisateur. Et vice‐versa, il n’y a pas de dépendance
directe entre les effets ou résultats d’un batch et l’exécution d’un
processus ou d’une interaction humaine. Un exemple classique est le
batch de nuit qui calcule la paie, émet les factures ou encore
synchronise les bases de données.
A l’opposé, l’exécution d’un batch temps réel dépend d’un évènement
déclencheur, d’un utilisateur (humain ou non). Le batch sera
généralement exécuté immédiatement avec la réception d’un message ou
plusieurs messages d’un ou plusieurs autres (programmes) utilisateurs,
peu importe comment ces messages sont implémentés. La notion de temps
réel implique de l’interactivité ou plutôt de la dépendance :
l’exécution d’un processus informatique ou humain peut dépendre de
l’obtention du résultat d’un batch. Un batch temps réel fait partie
d'un processus humain.

Il est important de noter qu’une architecture batch temps réel permet
aussi l’exécution d’un batch temps différé. En effet, si on peut
démarrer un batch sur base d’un événement, cet événement peut être
l’atteinte d’un temps donné. Si on peut être dépendant de la réponse
d’un batch on peut aussi bien choisir de l’ignorer.

Par rapport à ton texte nos batchs temps différé représentent tes
batchs de transfert et de traitement. Par contre le mode fil de l'eau
est de l'asynchrone comme je le comprends et le combiné correspond à
nos batchs temps réels.

Notre justification de l'utilisation des batchs temps réels impose
l'existence d'un besoin dans un processus métier de temps différé. Si
celui-ci existe alors il faut utiliser les batchs temps réels pour
garantir l'unicité, la garantie de livraison, etc ...

Donc je suis d'accord avec l'ensemble de ton texte aux nuances
indiquées ci-dessus.

Bien à toi,
Lilian.

On 19 oct, 14:23, Jean-Pierre <jean-pierre.lat...@tele2allin.be>
wrote:

[fa...@free.fr]

> Donc je suis d'accord avec l'ensemble de ton texte aux nuances
> indiquées ci-dessus.

Et ou situez-vous l'architecture orientee service dans tout ca ? :-).
Fab.

--
Mon ordinateur est ecologique, il ne consomme que du GPL.

fabien....@praxeme.org
Praxeme : http://www.praxeme.org
Blog : http://friends.praxeme.org
Photos : http://krohorl.free.fr

[William El Kaim]

Le Batch de transfert est considéré comme "un Service Technique" de communication ou comme la réalisation d'un service Metier (traitement par lot).
Faudrait peut-être écrire un livre sur ce sujet ... Le SOA avec un ESB à l'ancienne: ordonnanceur et scripts.

2009/10/20 <fa...@free.fr>

--
William EL Kaim (Personal email)

[ldu]

Biensûr le SOA s'intègre parfaitement à notre manière de faire puisque
nous partons du processus métier tout en respectant les mêmes règles
énoncés par Jean-Pierre. J'avais déjà abordé ce thème sur ce blog (et
d'ailleurs un grand merci pour toutes les remarques qui nous servies à
démarrer notre étude).
C'est à dire que nous respectons le découplage par l'utilisation de
message, le contrat, l'autonomie, la réutilisabilité, et le stateless
qui sont les critères obligatoires à respecter pour réaliser des
services chez nous.

Par ailleurs toujours dans le respect du SOA nos services sont
indépendants du temps différé.

Lilian.

On 20 oct, 18:29, fa...@free.fr wrote:
> > Donc je suis d'accord avec l'ensemble de ton texte aux nuances
> > indiquées ci-dessus.
>
>         Et ou situez-vous l'architecture orientee service dans tout ca ? :-).
>         Fab.
>
> --
> Mon ordinateur est ecologique, il ne consomme que du GPL.
>

> fabien.vill...@praxeme.org

[Jean-Pierre]

Bonjour Fabien,

Et bien es services (éventuellement exposés sur un ESB) sont consommés
par les modules constitutifs de la chaîne au fil de l'eau.Nous avons
un système au fil de l'eau qui fonctionne ainsi sous de très grosses
pointes de charge depuis plusieurs années.
Remarque :
Le problème peut être que lors de pointes de charge sur ce système les
services (ou les dbs derrière - ou le middleware) ne sont plus
suffisamment disponibles pour les applications interactives (applis
web ou autres). C'est un argument souvent utilisé par les détracteurs
du mode au fil de l'eau : il ne serait pas prédictible en termes de
sollicitation sur les services et empêcherait par voie de conséquences
la mise sur pied d'un vrai capacity planning et donc le respect des
SLAs du côté des applications interactives.
De mon point de vue c'est oublier la possibilité de faire du
throtlling sur les applis au fil de l'eau. Réglé en fonction de plages
horaires le cas échéant.

Je suis beaucoup plus réservé sur l'emploi de services SOA dans les
applications batch sur gros volumes. Personnellement j'aime qu'un
batch au vrai sens du terme (gros volume-traitement différé) attaque
le plus directement possible les dbs sans passer par une "pyramide" de
services. Concernant le respect des SLAs du côté des applications
interactives, ça peut évidemment demander des mesures spéciales pour
la mise à disposition des données nécessaires au batch (ou dans
l'autre sens).
Evidemment on peut vouloir appeler un service décisionnel par exemple
(les règles métier). Au risque de paraître old school je préfére pour
un vrai batch emporter le code dans l'application plutôt que de faire
appel à un service. Si l'outil de gestion de règles peut générer du
code on peut éviter la double maintenance (s'il le fait vers Cobol et
Java c'est encore mieux [et ça existe]). Attention dans ce cas aux
tests de non régression ;-).

Bien à toi,

Jean-Pierre

On 20 oct, 18:29, fa...@free.fr wrote:

> > Donc je suis d'accord avec l'ensemble de ton texte aux nuances
> > indiquées ci-dessus.
>
>         Et ou situez-vous l'architecture orientee service dans tout ca ? :-).
>         Fab.
>
> --
> Mon ordinateur est ecologique, il ne consomme que du GPL.
>

> fabien.vill...@praxeme.org

[Jean-Pierre]

Bonjour William,

Personnellement je vois un service au sens SOA comme une ressource
appelable à distance et qui doit donc être invoquée par un
consommateur de ce service.
Jamais comme une ressource dont l'exécution est planifiée. Question de
définition.

Oui mais bon ... ton ordonnanceur pourrait être vu comme le client du
script (le service). Et le script peut être distant.
Ca tient la route. Intéressante cette image de SOA à l'ancienne.
Ce qui ne veut quand même pas dire que c'est l'avenir ;-).

Bien à toi,

Jean-Pierre

On 20 oct, 19:31, William El Kaim <william.elk...@gmail.com> wrote:
> Le Batch de transfert est considéré comme "un Service Technique" de
> communication ou comme la réalisation d'un service Metier (traitement par
> lot).
> Faudrait peut-être écrire un livre sur ce sujet ... Le SOA avec un ESB à
> l'ancienne: ordonnanceur et scripts.
>
> 2009/10/20 <fa...@free.fr>
>
>
>
>
>
> > > Donc je suis d'accord avec l'ensemble de ton texte aux nuances
> > > indiquées ci-dessus.
>
> >         Et ou situez-vous l'architecture orientee service dans tout ca ?
> > :-).
> >        Fab.
>
> > --
> > Mon ordinateur est ecologique, il ne consomme que du GPL.
>

> > fabien.vill...@praxeme.org

[fa...@free.fr]

> sollicitation sur les services et empêcherait par voie de conséquences
> la mise sur pied d'un vrai capacity planning et donc le respect des
> SLAs du côté des applications interactives.
> De mon point de vue c'est oublier la possibilité de faire du
> throtlling sur les applis au fil de l'eau. Réglé en fonction de plages
> horaires le cas échéant.

Certes. On a desormais assez d'outils de metrologie/management
des services pour etablir des priorites grace a des calculs
eventuellement complexes.

> Je suis beaucoup plus réservé sur l'emploi de services SOA dans les
> applications batch sur gros volumes. Personnellement j'aime qu'un
> batch au vrai sens du terme (gros volume-traitement différé) attaque
> le plus directement possible les dbs sans passer par une "pyramide" de
> services.

Il faut relativiser. Meme en C, un code bien structure passe
par une pyramide de fonctions. Si les intermediaires sont bien dessines
(des services plutot que des fonctions), l'overhead et peu ou prou le
meme.

> Evidemment on peut vouloir appeler un service décisionnel par exemple
> (les règles métier). Au risque de paraître old school je préfére pour
> un vrai batch emporter le code dans l'application plutôt que de faire
> appel à un service.

Le fait de mettre le code dans le batch ne casse pas
forcement l'approche service. Que tu invoques le service par un
appel de methode, un web service avec la stack complete ou tout
intermediaire (proxy/factory, aop...) ne change pas le fait que
tu invoques un service (et que tu n'appelles pas une fonction :-).

Mais ca reste dangereux pour la raison que tu evoques :

> Si l'outil de gestion de règles peut générer du
> code on peut éviter la double maintenance (s'il le fait vers Cobol et
> Java c'est encore mieux [et ça existe]). Attention dans ce cas aux
> tests de non régression ;-).

On retombe dans le risque classique : redondance, branches
d'evolutions separees, doc incompletes et incompatibles, perte de
maitrise et donc de controle.

Ah ! Ca faisait longtemps que ce forum n'avait pas connu ca ! :-).

Fab.

--
Now, I have to change my biometrics every 90 days...

fabien....@praxeme.org

[Jean-Pierre]

> > Je suis beaucoup plus réservé sur l'emploi de services SOA dans les
> > applications batch sur gros volumes. Personnellement j'aime qu'un
> > batch au vrai sens du terme (gros volume-traitement différé) attaque
> > le plus directement possible les dbs sans passer par une "pyramide" de
> > services.
>
>         Il faut relativiser. Meme en C, un code bien structure passe
> par une pyramide de fonctions. Si les intermediaires sont bien dessines
> (des services plutot que des fonctions), l'overhead et peu ou prou le
> meme.

>         Le fait de mettre le code dans le batch ne casse pas
> forcement l'approche service. Que tu invoques le service par un
> appel de methode, un web service avec la stack complete ou tout
> intermediaire (proxy/factory, aop...) ne change pas le fait que
> tu invoques un service (et que tu n'appelles pas une fonction :-).
>

Ce qui nous rend prudent vis-à-vis de l'appel de services SOA à partir
de programmes batch, dès lors que les services sont des Web services,
c'est le prix à payer pour la sérialisation, désérialisation XML. Avec
donc toute l'ampleur de la question : jusqu'à quel niveau de
profondeur pousser le stack WS dans la pyramide SOA? Sa

[William El Kaim]

Attention SOA ne veut pas forcément dire web service ... ni XML.
Le problème avec les batchs c'est que très souvent uils ne sont pas gérés par des équipes de développements mais par le production. Donc, la mise en place d'une passerelle entre le sous SI batch et l'ESB est une bonne approche. On cloisonne les différentes problémantqiues. L'ESB douit juste recevoir les messages du cycle de vie des services Metier réalisés par les batchs.
Informatica a des outils qui permettent ce genre de passerelle. Mais, cela existe chez tout les acteurs du marché.

Mon autre problème avec les batchs c'est que mal controler ils peuvent créer des problemes de performances sur les SGBD et qu'il est difficile de faire du capacity planning. Certaines équipes de développement chez nous développent en Java des appluications "batch" et utilise un ordonnaceur java (Quartz) pour les gérér. Le lien avec l'ESB est alors plus simple et les applications gérées par le développement. Il est ainsi plus facile de savoir combien de batch tournent, leur temps de traitement, leur parallelisation, etc. l'objectif etant la "sustainabilité", pas la rentabilité court terme.

Maklheureusement les batchs sont encore la pour longtemps et vont devoir coexister avec le real time web.

2009/10/21 Jean-Pierre <jean-pier...@tele2allin.be>

[Robin Mulkers]

Pour une raison qui m'échappe, ces messages étaient considérés come
spam par Gmail.

Pour aujouter mon grain de sel, je dirais que le fait que le besoin
métier ne justifie pas le temps réel n'est pas une bonne
justification.

Pour moi, les justifications pour faire du traitement différé sont:
Soit historiques, l'application a été développée à l'époque des cartes
perforées ;), introduire du traitement au fil de l'eau dans un
processus de traitement batch serait trop compliqué
Soit techniques, l'utilisation de certaines resources doit être
planifiée (par exemple, la production d'un fichier, d'un rapport
périodique, une chaîne d'impression,..)
Soit financières, même si on sait aujourd'hui que la maintenance de
telles applications est délicate, le fait d'éviter l'utilisation de
middleware peut faire baisser le coût par transaction. Applicable pour
les volumes importants.

C'est le rôle de l'architecte de faire ce choix au cas par cas en
fonction des besoins, des coûts, de la stratégie, etc etc

Je reste persuadé que SOA ne va pas remplacer les programmes batch.
Ils seront toujours nécessaires mais dans une moindre mesure.
Robin

On 19 oct, 14:23, Jean-Pierre <jean-pierre.lat...@tele2allin.be>
wrote:

[Jean-Pierre]

William,

Tu peux développer le point suivant :"

"> Mon autre problème avec les batchs c'est que mal controler ils
peuvent créer
> des problemes de performances sur les SGBD et qu'il est difficile de faire
> du capacity planning."

Tu considères donc que la capacity planning serait plus facile à
établir avec le fil de l'eau qu'avec le batch?
Tes arguments m'intéressent.

Jean-pPerre

[William El Kaim]

Je vais essayer de répondre à cette question ...

C'est d'abord une question d'organisation. Qui effectue le controle. Si tout est géré au sein de l'application, il est possible d'instrumenter la vision de bout en bout et de la relier aux processus Metier. ce sont les étrudes qui utilisent leurs outils d'application monitoring pour cela.

Si les batchs sont concus par la production sur des outils gérés par la production, il y a une rupture. La production n'a pas de compréhension globale des flux et de l'application en général. S'il y a une personne qui s'occupe que de surveiller les batchs, alors tout va bien. Si cette personne est capable de dire tel batch n'a pas marché, voila l'impact sur ces applications et sur les business process, c'est aussi super. Si enfin, cette personne est capable d'analyser les évolutions dans le temps de ces traitements en fonction des évolutions du Metier, alors c'est parfait. Mais, admettions que cela n'est pas courant dans les équipes de production. En général, la production s'attache à faire fonctionner les plateformes et les logiciels en respectant les SLA.

Le capacity planning est donc lié à la compréhension de l'ensemble des flux de données, des algorithmes et temps de calcul en général fonction des donénes et des plateformes cibles, de l'ordonnancement des traitements (parrallele ou pas), des ressources necessaires au rollback en cas d'erreur, etc.

Enfin, quels sont les métriques de performance sur des batchs accessibles durant leurs exécutions? De quels outils dispose t'on pour les mesurer et les aggreger ensuite pour les associer à l'activité business? Si j'ajoute 500 nouvelles entrées dans ma table, combien de temps prendra le(s) batch(s)? Dififcile à prédire. Difficile à gérer.

Voila ma vision et je la partage avec moi même et maintenant avec vous.

Cordialement

2009/10/21 Jean-Pierre <jean-pier...@tele2allin.be>

[Jean-Pierre]

Autrement dit tu considères que si la production est sensible aux SLAs
par application (c'est la moindre des choses) elle est beaucoup moins
sensible à la fluidité des processus.

Autrement dit encore, vu du point de vue du métier, la production
serait plutôt tournée vers l'optimisation locale et non l'optimisation
globale.

Voilà qui mérite réflexion.

Il y a aussi des cailloux du côté du développement sur l'optimisation
globale : si deux projets pompent sur la même db, le projet 1 est
souvent bien peu soucieux des conséquences sur le projet 2, et
inversément.

C'est pourquoi je défendais le bien-fondé des comités de review lors
de SITA 2009. En vue d'avoir des (deux) instances qui s'occupent
d'optimisation globale. Que ce soit le comité de review fonctionnel
pour optimiser la réutilisation (entr'autres) ou le review technique
pour optimiser l'usage des ressources partagées (entr'autres).

Sans mesure structurelle au moins temporaire, il est très difficile,
voire impossible, de faire évoluer les mentalités et comportements.

Encore une question : selon toi l'approche fil de l'eau, si indiquée
en regard des besoins métier, permet-elle de faire mieux en termes
d'optimisation globale sur le capacity planning (recherche de la
meilleure utilisation des ressources) que l'approche batch?

La théorie des contraintes est très intéressante de ce point de vue.
Mais c'est au final dans la pratique qu'il nous faut en juger.

[fa...@free.fr]

> Je reste persuadé que SOA ne va pas remplacer les programmes batch.
> Ils seront toujours nécessaires mais dans une moindre mesure.

Je suis persuade du contraire :-).
Ils ne se justifient comme tu l'as dit que pour des raisons
qui sont de plus en plus fallacieuses. La vraie raison est probablement
plus proche de la resistance au changement culturel. Dans pas mal de
cas, des aujourd'hui, et sans pour autant mettre la SOA en avant, on arrive
a les eliminer rien qu'en reconstruisant des acces aux bases corrects,
par une activite de conception. On voit meme des traitements STP bien
construits (penses) qui les absorbent car ils sont ainsi plus eficaces.
Et c'est une des vertus de la SOA de refonte de favoriser cette
reconception efficace.

Fab.

--

[Robin Mulkers]

Ok, je prends un exemple concret et vécu: un programme d'impression
d'extraits de compte dans une banque.

Les mouvements sur les comptes arrivent au fil de l'eau.
Chaque jour, on imprime une grande quantité d'extraits de compte qui
sont mis sous enveloppe automatiquement. La Poste impose certains
critères de tri pour avoir une réduction sur les frais d'expédition.
On veut trier et regrouper les enveloppes par code postal pour
bénéficier des tarifs d'expédition réduits.

Le programme qui va parcourir les comptes pour lesquels il y a des
mouvements à imprimer et ensuite constituer le fichier qui sera envoyé
à l'impression avec les extraits de comptes triés par code postal.

Comment est-il possible de réaliser celà simplement sans à aucun
moment dans la chaîne utiliser un programme batch?
J'attends vos propositions avec impatience.

On 22 oct, 00:31, fa...@free.fr wrote:
> > Je reste persuadé que SOA ne va pas remplacer les programmes batch.
> > Ils seront toujours nécessaires mais dans une moindre mesure.
>
>         Je suis persuade du contraire :-).
>         Ils ne se justifient comme tu l'as dit que pour des raisons
> qui sont de plus en plus fallacieuses. La vraie raison est probablement
> plus proche de la resistance au changement culturel. Dans pas mal de
> cas, des aujourd'hui, et sans pour autant mettre la SOA en avant, on arrive
> a les eliminer rien qu'en reconstruisant des acces aux bases corrects,
> par une activite de conception. On voit meme des traitements STP bien
> construits (penses) qui les absorbent car ils sont ainsi plus eficaces.
> Et c'est une des vertus de la SOA de refonte de favoriser cette
> reconception efficace.
>
>         Fab.
>
> --

> fabien.vill...@praxeme.org

[Jean-Pierre]

>
> > > Je reste persuadé que SOA ne va pas remplacer les programmes batch.
> > > Ils seront toujours nécessaires mais dans une moindre mesure.
>

Perso, je suis d'accord avec Robin. Pas plus tard qu'hier j'étais dans
une réunion relative au choix d'un outil pour l'impression de
documents.
La problématique du regroupement et du triage était évidente.

Je suis personnellement convaincu qu'il y a aujourd'hui 3 types
d'applis :
- interactives (web ou GUI - la différence s'amenuisant en termes de
possibilités)
- fil de l'eau (tirée en bas par les ESBs [pour l'integration par les
données], en haut par les BPMS [pour l'intégration par les fonctions],
de façon générale par le SOA) - ou batch temps réel selon la typologie
de Lilian
- batch (pour les traitement périodiques)

D'après moi la part batch va se réduire au profit du fil de l'eau (il
faut accentuer la réactivité) mais le batch subsistera (car tout faire
au fil de l'eau serait hors de prix - le batch permet des économies
d'échelle)

[fa...@free.fr]

> Les mouvements sur les comptes arrivent au fil de l'eau.
> Chaque jour, on imprime une grande quantité d'extraits de compte qui
> sont mis sous enveloppe automatiquement. La Poste impose certains
> critères de tri pour avoir une réduction sur les frais d'expédition.
> On veut trier et regrouper les enveloppes par code postal pour
> bénéficier des tarifs d'expédition réduits.
> Le programme qui va parcourir les comptes pour lesquels il y a des
> mouvements à imprimer et ensuite constituer le fichier qui sera envoyé
> à l'impression avec les extraits de comptes triés par code postal.
> Comment est-il possible de réaliser celà simplement sans à aucun
> moment dans la chaîne utiliser un programme batch?
> J'attends vos propositions avec impatience.

Un systeme (serveur, service, daemon unix,...) recoit les
evenements correspondants aux mouvements declencheurs d'impressions,
prepare les requetes de creation des info d'impression du compte,
voire cree le resultat au format adequat. Il conserve les references,
triees au fur et a mesure (un tri dans ces conditions ne coute presque
rien). Il recoit aussi l'evenement declencheur de la transmission (un
tick d'horloge, mais aussi potentiellement une autorisation d'envoi
fournie par le systeme de la poste si cette derniere avance vers le
B2B) et invoque le service de transmission eventuellement fourni par
un autre sous-systeme.
L'avantage est de ne plus avoir de traitement lourd a un
moment donne, voire meme de ne plus avoir d'acces a la base vivante
si les evenements declencheurs portent les donnees suffisantes. La,
tout depend de l'effort consenti vis-a-vis des transformations de
l'existant. A l'extreme, ce probleme est a integrer dans un traitement
STP, en annexe, qu'on ne place pas sur le chemin critique.
Le fait est que l'approche fonctionnaliste, qui nous plombe
depuis 10 ans, entraine souvent la confusion entre separer les
preoccupations/competences (qui est un bon principe d'architecture)
et regrouper les transactions (qui est une technique d'optimisation).
C'est perturbant quand on reflechit aux avantages du traitement au
fil de l'eau.
Fab.

--
A classic is something that everyone wants to have read and nobody
wants to read. (Mark Twain, "The Disappearance of Literature")

fabien....@praxeme.org

[fa...@free.fr]

> au fil de l'eau serait hors de prix - le batch permet des économies
> d'échelle)

Comment les obtient-on ?

Je vois bien plusieurs choses, certes, mais pas tres excitantes :

- Un batch est encore ecrit le plus souvent comme un gros
bloatware spaghetti meem dans les langages modernes. C'est l'endroit
ou il semble qu'on puisse encore se permettre de ne meme pas structurer
le code, par exemple quand les batches sont ecrits dans des lanagages
interpretes :-). Ca semble etre moins couteux a ecrire (quoique) mais
la maintenance et surtout, comme l'evoquait William, le control des
kyrielles de bouts de batches, prouve le contraire.

- Le regroupement des transactions metier en transactions
techniques moins nombreuses. Il y a la un reel pouvoir d'optimiation.
Mais negligeable par rapport au gain d'une bonne conception des bases
et des acces aux donnees. Et rien n'empeche de faire un regroupement
de cet ordre au fil de l'eau en bufferisant certains evenements.

En revanche, le traitement batch est resoluement caracteriel
vis-a-vis du parallelisme et de la distribution. Passer un traitement
batch sur une grosse machine aujourd'hui (un multi-coeur) puis celles
de demain (beaucoup de coeurs :-) ne l'accelere pas. L'utilisation des
grilles de calcul et des grilles de donnees est quasiment prohibe. Le
decoupage que certains tentent (sur le perimetre) est le plus facile
a mettre en oeuvre (souvent c'est le seul qui vient a l'esprit), mais
c'est le pire, il n'est pas scalable. Non, decidement, le principe du
batch est obsolete, il va falloir s'y faire :-).

Fab.

--
J'ai tout bon, j'en mettrais mon main() à compiler !

fabien....@praxeme.org

[Robin Mulkers]

Salut Fab, je comprends tes arguments. C'est effectivement possible de
déplacer le traitement le plus possible vers le fil de l'eau.
Par exemple, dans le cas de mes extraits de compte, on pourrait déjà
formatter les extraits à l'avance pour in-fine ne plus devoir faire
que le tri à un instant donné.
Ton argument est qu'en limitant au maximum la travail à réaliser à cet
instant donné, on peut exécuter ce travail sous la forme d'un service
et pas sous forme d'un batch.
C'est correct mais parfois injustifiable d'un point de vue économique.
En effet, cette approche nécessite d'augmenter la capacité de stockage
pour le fil de l'eau (probablement une DB indexée si on veut
effectivement un tri rapide) et ce stockage est un coût supplémentaire
pour le traitement.
Ce qui pour moi est une meilleure solution pour allèger le programme
batch est d'utiliser un service pour formatter les extraits de compte
au lieu de développer cette fonctionnalité dans le programme batch lui-
même.
C'est toujours une architecture SOA mais on ne supprime pas les
batchs, on les rend juste plus légers.

Discussion intéressante ;)

> fabien.vill...@praxeme.org

[Robin Mulkers]

Je ne suis pas d'accord sur le point du parallélisme.
Il est tout à fait possible de paralléliser les traitements batchs.
La méthode la plus ancienne est de fragmenter les données en entrée.
Par exemple, on découpe un fichier d'entrée en plusieurs morceaux pour
les traiter en parallèle par la suite. Sur Unix, on trouve de plus en
plus des batchs qui font du multi-threading.
La problématique est alors la gestion des transactions et la reprise
en cas d'échec, mais par expérience, ce n'est vraiment pas
insurmontable.

En général, en batch, l'élément déterminant pour la performance n'est
pas la vitesse du processeur mais plutôt la vitesse et la latence des
contrôleurs I/O. En effet, on manipule des volumes importants de
données. C'est pourquoi on trouve des processeurs si peu rapides sur
certains mainframes.

> fabien.vill...@praxeme.org

[fa...@free.fr]

> C'est correct mais parfois injustifiable d'un point de vue économique.
> En effet, cette approche nécessite d'augmenter la capacité de stockage
> pour le fil de l'eau (probablement une DB indexée si on veut
> effectivement un tri rapide) et ce stockage est un coût supplémentaire
> pour le traitement.

Oh ! :-)
Le placement d'un code postal dans une liste ? Il faut une BD
relationnelle avec table et index pour faire ca ?

> Ce qui pour moi est une meilleure solution pour allèger le programme
> batch est d'utiliser un service pour formatter les extraits de compte
> au lieu de développer cette fonctionnalité dans le programme batch lui-
> même.
> C'est toujours une architecture SOA mais on ne supprime pas les
> batchs, on les rend juste plus légers.

Jusqu'a ce qu'il ne reste plus rien dedans. Dans ton exemple, il
reste quoi ? Le tri ?

Allons jusqu'au bout de la reflexion, on est un peu la pour ca
aussi :-) :

Pourquoi ce tri ? C'est le sous-traitant qui l'impose. En fait
c'est pour lui simplifier la vie que tu compliques la tienne. Mais
tu payes un services, non ? Donc, on en arrive a la situation suivante :
un probleme de negociation commerciale (j'ai achete un service qui n'est
pas tout-a-fait le bon), a des impacts sur l'architecture logicielle
(batch versus fil de l'eau), et sur l'infrastructure (le batch ne tournera
pas sur n'importe quelle machine a cause des problemes de scalabilite).
Moi, ca me choque.
Solution : changer de sous-traitant ? Tu payeras peut-etre le
service plus cher, mais si ca te coute moins pour l'invoquer... Non ?

Fab.

--
fabien....@praxeme.org

[pierre bonnet]

Bonjour à tous,

Cela fait plaisir de voir ces discussions. Je n'ai pas eu le temps de lire
le détail de tous les messages mais je vais quand même y ajouter une idée,
celle poussée par Sustainable IT Architecture.

La réversibilité du choix entre traitements batchs (ensembliste) / et
traitements unitaires doit être favorisé. Dès lors, le passage d'un pan
d'exécution de N ou 1 n'a pas d'impact sur le logiciel. Pour y parvenir, il
"suffit" de garantir deux concepts clefs :
- externalisation de la gestion des transactions : les points de synchro
sont paramétrés, "on/off/esclave" selon les pans d'exécution souhaités => on
gère ces paramétrages (et bien d'autres) dans un MDM
- externalisation des règles métiers dans un BRMS pour les réutiliser dans
les modes batchs/unitaires

Par conséquent, la question de la disparition ou non des batchs au
profit/détriment du fil de l'eau n'est pas déterminante. Ce qui compte c'est
la capacité à changer la configuration du logiciel pour passer de l'un à
l'autre en réduisant au maximum les impacts, dans certains cas sans impacts.

C'est possible !

Pierre Bonnet

[fa...@free.fr]

> Par conséquent, la question de la disparition ou non des batchs au
> profit/détriment du fil de l'eau n'est pas déterminante. Ce qui compte c'est
> la capacité à changer la configuration du logiciel pour passer de l'un à
> l'autre en réduisant au maximum les impacts, dans certains cas sans impacts.

Elle est determinante, Pierre ! :-). Car le raisonnement batch
a tendance a occulter d'autres solutions. Par exemple pourquoi se
donner les moyens de changer par simple reconf si le batch est le seul moyen
d'arriver a ses fins ?

Mais oui, je suis d'accord, on peut concevoir 99% du systeme
sans se poser la question batch/fil de l'eau et passer d'une vision a
l'autre quand on veut.

Fab.

--
Les problèmes complexes ont des solutions simples, faciles
à comprendre, et fausses.

fabien....@praxeme.org

[fa...@free.fr]

>
> Je ne suis pas d'accord sur le point du parallélisme.
> Il est tout à fait possible de paralléliser les traitements batchs.
> La méthode la plus ancienne est de fragmenter les données en entrée.
> Par exemple, on découpe un fichier d'entrée en plusieurs morceaux pour
> les traiter en parallèle par la suite. Sur Unix, on trouve de plus en
> plus des batchs qui font du multi-threading.

Oui, j'ai evoque ca dans le mail que tu cites (parallelisation
par decoupage du perimetre). Ce n'est pas scalable. Ca permet tout
juste de decouper en quelques gros morceaux, mais pas de paralleliser.
Ca n'exploite pas bien le multi-threading qui lui-meme n'exploite pas
bien les multi-coeurs (meme peu nombreux), et encore moins les possibilites
de parallelisation massives du grid.

> En général, en batch, l'élément déterminant pour la performance n'est
> pas la vitesse du processeur mais plutôt la vitesse et la latence des
> contrôleurs I/O. En effet, on manipule des volumes importants de
> données. C'est pourquoi on trouve des processeurs si peu rapides sur
> certains mainframes.

C'est pourquoi il faut travailler a supprimer les IO. Une bonne
IO est une IO qu'on evite :-). Et le fil de l'eau permet bien sur de
faire ca puisque les traitements sont faits au moment ou le besoin s'en
fait sentir, c'est-a-dire au moment ou les donnees sont presentes.

Fab.

--
Un organigramme réussi : chacun dans sa case et
les cases seront bien gardées.

fabien....@praxeme.org

[pierre bonnet]

Alors si j'ai résolu 99% de vos débats je suis un consultant heureux.
A+

Pierre Bonnet

-----Original Message-----
From: metho...@googlegroups.com [mailto:metho...@googlegroups.com] On
Behalf Of fa...@free.fr
Sent: jeudi 22 octobre 2009 13:13
To: metho...@googlegroups.com
Subject: [SOA Bonnet] Re: Batch vs fil de l'eau

[Robin Mulkers]

Je ne suis pas d'accord sur le point des I/O. Je pense que les
traitements fils de l'eau et de plus en plus les architectures basées
sur XML pour l'échange des données provoquent une augmentation des I/O
et pas une réduction.
C'est du principalement à la taille plus élevée des données échangées
mais aussi la multiplication des en-têtes de message.
En effet, pour chaque message, il y a un en-tête de message qui est
multiplié par le nombre de messages (je simplifie). Plus les messages
sont petits, plus les en-têtes et tout le travail technique de
préparation au traitement d'un message augmente proportionnellement.

Pour résumer, un fichier qui reprend 100.000 ordres de paiement aura
une taille inférieure et nécessitera moins de resources système pour
son traitement que 100.000 ordres de paiement individuels, qui plus
est dans un format XML. Je suis vraiment surpris de devoir justifier
celà ici.

Maintenant, je ne dis pas celà pour vanter les mérites des programmes
batch, loin de là.
Toutefois, il me semble vraiment utopique aujourd'hui de penser qu'on
peut complètement se passer de ce genre de traitement.
Dans certains cas, celà reste indispensable.
Ces programmes batch deviennent alors potentiellement de nouveaux
clients pour les bus de service d'entreprise.

Bien à vous.
Robin Mulkers

> fabien.vill...@praxeme.org

[fa...@free.fr]

> Je ne suis pas d'accord sur le point des I/O. Je pense que les
> traitements fils de l'eau et de plus en plus les architectures basées
> sur XML pour l'échange des données provoquent une augmentation des I/O
> et pas une réduction.
> C'est du principalement à la taille plus élevée des données échangées
> mais aussi la multiplication des en-têtes de message.
> En effet, pour chaque message, il y a un en-tête de message qui est
> multiplié par le nombre de messages (je simplifie). Plus les messages
> sont petits, plus les en-têtes et tout le travail technique de
> préparation au traitement d'un message augmente proportionnellement.
> Pour résumer, un fichier qui reprend 100.000 ordres de paiement aura
> une taille inférieure et nécessitera moins de resources système pour
> son traitement que 100.000 ordres de paiement individuels, qui plus

A combien evalues-tu la difference de taille ?

Quant aux IO : un fichier de 100 000 ordres, en tant que fichier,
est stocke sur disque, donc IO ecritures/lectures, nombreuses car les
batches passent leur temps a lire et ecrire ces gros machins. A l'inverse,
100 000 ordres traites quand ils arrivent ne sont pas representes par
100 000 fichiers. Le fichier n'a plus de sens, de ce point de vue. Chaque
ordre est traite directement. Les IO de persistence (ou plus exactement
d'archivage qui est seul necessaire d'un point de vue metier) sont
desynchronisees par rapport aux traitements, les IO ne sont pas payees
par le traitement. Bref, il faut repenser tout ca en sortant *vraiment*
du mode batch.

> est dans un format XML. Je suis vraiment surpris de devoir justifier
> celà ici.

C'est parce qu'il faut en permanence remettre en cause les
idees qui prennent de l'age, pour voir si elles tiennent encore la
route :-).

> Toutefois, il me semble vraiment utopique aujourd'hui de penser qu'on
> peut complètement se passer de ce genre de traitement.

Certes, mais d'autres vont neanmoins continuer de les
eliminer completement :-).

Fab.

--
Les donnees biometriques presentent 2 problemes qui les rendent inaptes
a securiser des acces : elles sont irrevocables, et elles sont publiees
publiquement des que leur proprietaire sort de chez lui.

fabien....@praxeme.org

[William El Kaim]

Euh ...
Si on suit la définition du batch de transfert et de traitement donné, je ne vois quel est le problème.
SOA ne veut pas dire XML ... On peut envoyer ce qu'on veut dans du JMS.
Concernant les batchs, on ne va pas re-investir dans leur re-ecriture, on les garde tel quel.
Il faut juste faire en sorte qu'ils s'intégrent dans la vision d'ensemble des flux et gérer les exceptions, erreurs et statut.
Informatica et sa plateforme V9 vont offrir une solution intégrée allant dans cette direction (toujours pas de scheduller par contre).
L'objectif est de rendre le SI durable. Donc on documente et on se re-approprie les batchs. On les insere dans la gestion des flux Metier, sur lesquels on va donner créer des dashboard. A tout moment on doit pouvoir savoir ou en est le batch (combien d'ordres passés, combien ont posé problème et le temps estimé de traitement).
Donc, on ne touche pas aux traitements, mais au controle. Puis, si on appliqie une vision ACMS, on va retravailler sur les données, les règles Metier, etc. Dans ce cas la, on peut imaginer de revoir l'architecture. En général, personne ne souhaite investir autant d'argent ...

2009/10/22 Robin Mulkers <mul...@gmail.com>

[Pierre Bonnet]

Je suis 100% d'accord avec William
Pierre Bonnet

----- Message d'origine -----
De: "William El Kaim" <william...@gmail.com>
À: metho...@googlegroups.com
Env: 22/10/2009 14:43
Objet: [SOA Bonnet] Re: Batch vs fil de l'eau

[Jean-Pierre]

Le succès de cette discussion montre bien que le sujet batch vs fil de
l'eau est dans beaucoup de têtes.

Je pense comme Pierre que la principale préoccupation doit être de
réduire la difficulté du passage d'un mode à l'autre. Ce qui à mon
sens implique pas mal de travail dans les batchs existants dont la
structure et l'optimisation du code n'est pas toujours un modèle du
genre, loin s'en faut.

Mais dites, sur la gestion du capacity planning des ressources
impliquées, croyez-vous que le fil de l'eau pose plus de problèmes que
le batch? Si on peut throttler sur le fil de l'eau je ne vois pas de
problèmes, bien au contraire.

[Jean-Pierre]

J'ai perdu mon dernier post => nouvel essai.

Je suis d'accord avec l'idée selon laquelle le plus important est de
créer les condittions pour passer facilement d'un mode à l'autre.

Mais dite, sur l'aspect capacity planning des ressources impliquées,
selon vous, avec quel mode as-t-on la plus facile et la meillleure
maîtrise (en supposant que l'exercice du capacity planning soit
facile ;-)).
Pour moi le mode au fil de l'eau, dès lors que l'on peut réguler le
flux est avantageux. Surtout comme le dit Fab si on fait en sorte
d'éviter les IOs sur les dbs. Souvent impossible à éviter pour partie
(un message qui conduit les données à traiter doit être contrôlé ou
enrichi. Pour cela il faut bien aller lire dans des dbs).

[William El Kaim]

Pardon, j'ai oublié le capacity planning ...

Je me suis posé la question récemment, car je me demandais, si en utilisant le cloud ou du data grid, je ne pourrais pas aller plus vite. Au lieu d'amener les données au traitement, j'amène le traitement aux noeuds de données (Gigaspace par exemple).

Le problème du "batch" c'est qu'on n'a pas l'habitude d'y associer des metriques. En général, on balance les scripts sur un legacy qui travaille sur une grosse BD départementale ou centrale. Seul l'admin de la BD ou du legacy à la vision d'ensemble des I/O et des perfs du matériel. mais il n'a aucune vision sur l'evolution des batchs et des volumes de données/calculs. Il ne réagira que quand les problemes seront la. En général par du scaling vertical (on rajoute du CPU et de la mémoire). Donc, on va construire l'infra en se basant sur l'optimum de ressources dont on risque d'avoir besoin. Ce n'est ni rentable, ni optimum.

Mon besoinest d'arriver a proactivement pouvoir dire: "attention, on va intégrer un nouveau gros client qui va nous augmenter notre base de 20%", et de détecter quel sera l'impact sur les batchs". A priori, personne ne le saura. A posteriori ca risque d'être trop tard.

De même si deux batchs tournent sur une base, comment savoir qu'il y a quelque chose qui cloche? Qui peut connaitre comment fonctionne les scripts?

C'est pourquoi, nous avons commencé à créer des batchs en Java avec SpringBatch, à les scheduler avec Quartz (API JAva) et à les intégrer avec nos outils de performance java. On a aussi décider de supprimer toutes les procedures stocquées qui n'ont plus lieu d'etre et peuvent être remplacées par un ORM (Hibernate ou autre). Enfin, les règles Metier sont codées en Java. Le passage à un BRMS pouvant se faire assez simplement via des API.

Les batchs de Transferts sont systématiquements développés sur Informatica et pilotés par Quartz ou un outil de process via appel Web service.

Seuls les traitements de calculs lourds sont conservés et optimisées si possible. Pour notre backoffice, on a du rachter des AS400 et ca a couté bien moins cher qu'une migration vers dotnet ou Java. On a par contre mis un convertigo devant, comme ca, on peut accélérer certains traitement en passant du batch à l'interactif tout en préservant la sécurité et l'existant legacy.

Enfin, on a intégré les équipes production et legacy dans les équipes de développement intégrés en mode agile. L'idée est que lma production comprenne ce qui se passe et il faut bien que qulqu'un prenne  le temps de leur expliquer!

Bon, c'est pas parfait, mais j'ai pas mieux sous la main. Equipe intégrée, documentation, nettoyage en appliquant des règles de design très clair.

2009/10/22 Jean-Pierre <jean-pier...@tele2allin.be>

[Jean-Pierre]

Et bien je suis assez d'accord avec tout ça.
Mais au fait vous avez du fil de l"eau basés sur du queuing ou pas ?
Je pose la question parce qu'à te lire j'ai un peu l'impression que
votre fil de l'eau est du batch à cadence rapide qui reste basé sur
des fichiers ou des dbs.
Pour moi le vrai fil de l'eau c'est prendre la(les) donnée(s) dans un
message posté dans une queue dès son apparition (il y a triggering
avec éventuellement du throttling).

> 2009/10/22 Jean-Pierre <jean-pierre.lat...@tele2allin.be>

[ycaseau]

Bonjour,

Je regarde passer la discussion avec le plus grand intérêt, c'était un
des sujets clés à Bouygues Telecom il y a quelques années.

Pour faire simple, mon point de vue est que tant que les infras
d'intégration ne feront pas de traitement intelligent des priorités
des flux (i.e. tant qu'on fera du FIFO), on aura besoin de batchs pour
garantir des SLA avec des très gros volumes.
Sans très gros volumes et SLA, le problème est trivial et on tombe
dans un débat "esthétique/religieux" :)
Je suis d'accord avec l'idée théorique que se débarasser des batchs
serait une possible et judicieux, (une fois passé la résistance
culturelle) mais encore faut-il avoir les bons outils.

Ordonnancer les flux avec des batchs est une méthode grossière et
frustre, mais fiable :)

Pour ceux que cela intéresse, j'ai modélisé le sujet dans:
http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6X1X-4H758D1-4&_user=10&_rdoc=1&_fmt=&_orig=search&_sort=d&_docanchor=&view=c&_searchStrId=1060440977&_rerunOrigin=google&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=c1017cb6cc623fee49500aaba0761735
(Self-adaptive middleware: Supporting business process priorities and
service level agreements)

Le papier est dense pour un non-scientifique, le résumé en une ligne,
c'est que faire du traitement dynamique des queues de messages au fil
de l'eau ça marche ! (encore faut-il le faire, j'avais commencé ce
travail pour motiver les éditeurs de logiciel, mais sans succès).

Cordialement,

--- Yves Caseau ----

[Robin Mulkers]

L'actualité nous rattrappe. En Belgique, la banque de la Poste vient
d'admettre une erreur de production informatique.
Ils ont envoyé un fichier de test en production envoyant par erreur
50.000 paiements d'allocations sociales pour un montant de 40 millions
€.
http://www.rtbf.be/info/economie/pres-de-50000-paiements-effectues-par-erreur-aupres-dallocataires-sociaux-capac-153304

La question que je me pose est la suivante:
Est-ce qu'une erreur de cette ampleur pourrait se produire avec des
traitements au fil de l'eau? Pourquoi pas?
Est-ce que le fil de l'eau permettrai de résoudre plus rapidement une
erreur comme celle-là ou au contraire, ce serait plus difficile de
corriger?

Qu'en pensez-vous?

On 23 oct, 08:49, ycaseau <y...@caseau.com> wrote:
> Bonjour,
>
> Je regarde passer la discussion avec le plus grand intérêt, c'était un
> des sujets clés à Bouygues Telecom il y a quelques années.
>
> Pour faire simple, mon point de vue est que tant que les infras
> d'intégration ne feront pas de traitement intelligent des priorités
> des flux (i.e. tant qu'on fera du FIFO), on aura besoin de batchs pour
> garantir des SLA avec des très gros volumes.
> Sans très gros volumes et SLA, le problème est trivial et on tombe
> dans un débat "esthétique/religieux" :)
> Je suis d'accord avec l'idée théorique que se débarasser des batchs
> serait une possible et judicieux, (une fois passé la résistance
> culturelle) mais encore faut-il avoir les bons outils.
>
> Ordonnancer les flux avec des batchs est une méthode grossière et
> frustre, mais fiable :)
>

> Pour ceux que cela intéresse, j'ai modélisé le sujet dans:http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6X1X-4H758D...

[fa...@free.fr]

> L'actualité nous rattrappe. En Belgique, la banque de la Poste vient
> d'admettre une erreur de production informatique.
> Ils ont envoyé un fichier de test en production envoyant par erreur
> 50.000 paiements d'allocations sociales pour un montant de 40 millions
> €.

> Est-ce qu'une erreur de cette ampleur pourrait se produire avec des
> traitements au fil de l'eau? Pourquoi pas?
> Est-ce que le fil de l'eau permettrai de résoudre plus rapidement une
> erreur comme celle-là ou au contraire, ce serait plus difficile de
> corriger?
> Qu'en pensez-vous?

Ce genre d'erreur est principalement due a la mauvaise
separation des environnements (voire a leur absence dans certains
cas extremes). L'architecture logicielle applicative n'a que peu
d'impact. Dans l'exemple, un traitement au fil de l'eau serait
accompagne de simulateurs d'evenements charges d'injecter des
masses de solicitations pour les tests. Ces injecteurs pourraient
tres bien injecter dans un systeme de prod par erreur si les
environnements ne sont pas assez bien separes (une erreur d'URI
dans une topologie reseau mal cloisonnee, par exemple).
Px insiste bien sur ce probleme des environnements en
faisant apparaitre clairement dans l'aspect physique le mapping
du logiciel sur le materiel, avec un decouplage dans lequel se
logent aisement les dispostifs de separation des environnements.
Evidemment ITIL est aussi une bonne force de separation et de
test de son efficacite.
Fab.

--
fabien....@praxeme.org

[Jean-Pierre]

Nous l'avons fait chez nous sur de gros volumes ... et, oui, ça
marche, et même très bien. Throughput remarquable.

Mais il faut admettre que ça peut présenter les inconvénients
suivants :
- c'est une révolution culturelle (et Dieu sait que c'est difficile à
gérer)
- ça complexifie l'infrastructure sous -jacente par rapport à du batch
traditionnel
- la supervision est peut-être un peu plus compliquée
- attention à ne pas bombarder (par une arrivée soudaine de messages)
les dbs aussi utilisées par d'autres applications sans précaution

Ce n'est pas une fin en soi. Nous sommes occupés à clarifier les
conditions de mise en oeuvre et cas d'emploi.

[William El Kaim]

Un article chez IBM qui dopnne un exemple ... L'exemple ne parle que de transferts de fichiers, mais peut être étendu sans problème à des batchs.  http://www.ibm.com/developerworks/websphere/library/techarticles/0907_amato/0907_amato.html

Managed file transfer for SOA

WebSphere MQ File Transfer Edition provides an enterprise-class platform for managed file transfer operations. This article shows you how to use File Transfer Edition to implement a managed file transfer system that enables you to issue file transfer commands simply by placing messages onto a queue and invoking a Web service.

2009/10/23 Jean-Pierre <jean-pier...@tele2allin.be>