Batch Java

[jeremy.herault]

Bonjour,

Dans le cadre d'une migration potentielle de batchs Cobol vers Java,
et dans le cadre d'un développement from scratch de batchs Java,
j'aurais voulu avoir des retours d'expériences sur les technos que
vous avez pues utiliser, ainsi que le volume de données manipulées
lors des traitements. Je précise qu'il s'agit de migration à la mano,
pas de fainéantise en utilisant un traducteur Cobol-->Java quel qu’il
soit.

Pour vous situez dans quel cadre je me situe, le scheduler utilisé (et
qui le restera) est $U (Dollar Universe). Actuellement, il ordonnance
des scripts UNIX dans lesquels les appels aux programmes Cobol sont
effectués. Le volume de données manipulées par les batchs Cobol va de
plusieurs centaines de milliers au million de lignes.

Merci pour vos retours.

--
Jérémy

[Emmanuel Lécharny]

Le 4/19/12 11:25 AM, jeremy.herault a écrit :

Je ne vais pas répondre à ta question, n'ayant jamais eu à porter du
Cobol vers du Java, cela dit ton projet m'interpelle et j'ai quelques
questions :
- faire du batch avec du Java va poser clairement la question du
démarrage de la JVM. Ce n'est pas une opération gratuite, il faut bien
compter quelques secondes pour cela. Comment cela est-il compatible avec
les performances attendues ?
- ne serait-il pas plus simple d'avoir une JVM pré-chargée avec le code
à exécuter, et d'avoir des scripts (shell ou autre) qui déclanchent
l'exécution de ce code au travers d'une invocation type REST ou autre ?
Cela éviterait d'avoir à lancer une JVM à chaque fois

A froid, si on ne peut pas éliminer $U, c'est un peu ce que je ferai...
pas vous ?

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Baptiste MATHUS]

Le 19 avril 2012 14:32, Emmanuel Lécharny <elec...@gmail.com> a écrit :

Le 4/19/12 11:25 AM, jeremy.herault a écrit :

Bonjour,

Dans le cadre d'une migration potentielle de batchs Cobol vers Java,
et dans le cadre d'un développement from scratch de batchs Java,
j'aurais voulu avoir des retours d'expériences sur les technos que
vous avez pues utiliser, ainsi que le volume de données manipulées
lors des traitements. Je précise qu'il s'agit de migration à la mano,
pas de fainéantise en utilisant un traducteur Cobol-->Java quel qu’il
soit.

Pour vous situez dans quel cadre je me situe, le scheduler utilisé (et
qui le restera) est $U (Dollar Universe). Actuellement, il ordonnance
des scripts UNIX dans lesquels les appels aux programmes Cobol sont
effectués. Le volume de données manipulées par les batchs Cobol va de
plusieurs centaines de milliers au million de lignes.

Je ne vais pas répondre à ta question, n'ayant jamais eu à porter du Cobol vers du Java, cela dit ton projet m'interpelle et j'ai quelques questions :
- faire du batch avec du Java va poser clairement la question du démarrage de la JVM. Ce n'est pas une opération gratuite, il faut bien compter quelques secondes pour cela. Comment cela est-il compatible avec les performances attendues ?

Honnêtement, pas sûr que la question se pose, justement. Si les batches doivent traiter des centaines de milliers, voire millions de lignes, les 2 secondes de démarrage ne sont pas bouleversifier tant que ça les perfs. A mon avis, ces traitements sont du genre plusieurs heures.
 

- ne serait-il pas plus simple d'avoir une JVM pré-chargée avec le code à exécuter, et d'avoir des scripts (shell ou autre) qui déclanchent l'exécution de ce code au travers d'une invocation type REST ou autre ? Cela éviterait d'avoir à lancer une JVM à chaque fois

A froid, si on ne peut pas éliminer $U, c'est un peu ce que je ferai... pas vous ?

Peut-être un peu overkill selon les besoins. Si les batches sont très courts, cela peut être utile.

Sans répondre moi non plus directement à la question, je suis en ce moment les travaux sur la JSR352 (http://jcp.org/en/jsr/detail?id=352). Cette JSR doit définir la façon avec laquelle un batch doit être écrit, et finalement aussi ce qu'un conteneur de batch doit offrir. Le lead est le responsable de WebSphere Batch, et ya des gens de chez Spring (Spring Batch) et RedHat. La solution sera donc sûrement très intéressante et concrète.

Pour le moment, pas mal de discussions et de bouts de specs brouillon et des annotations ou du XML qui pourraient être utilisés pour définir les batches, mais pas encore d'implém dispo. A mon avis, pas de code utilisable à "espérer" avant 3e ou 4e trimestre 2012. Par contre, c'est le moment de suivre et de faire des retours.

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[jeremy.herault]

Le jeudi 19 avril 2012 14:32:45 UTC+2, elecharny a écrit :

Le 4/19/12 11:25 AM, jeremy.herault a écrit :
> Bonjour,
>
> Dans le cadre d'une migration potentielle de batchs Cobol vers Java,
> et dans le cadre d'un développement from scratch de batchs Java,
> j'aurais voulu avoir des retours d'expériences sur les technos que
> vous avez pues utiliser, ainsi que le volume de données manipulées
> lors des traitements. Je précise qu'il s'agit de migration à la mano,
> pas de fainéantise en utilisant un traducteur Cobol-->Java quel qu’il
> soit.
>
> Pour vous situez dans quel cadre je me situe, le scheduler utilisé (et
> qui le restera) est $U (Dollar Universe). Actuellement, il ordonnance
> des scripts UNIX dans lesquels les appels aux programmes Cobol sont
> effectués. Le volume de données manipulées par les batchs Cobol va de
> plusieurs centaines de milliers au million de lignes.

Je ne vais pas répondre à ta question, n'ayant jamais eu à porter du
Cobol vers du Java, cela dit ton projet m'interpelle et j'ai quelques
questions :
- faire du batch avec du Java va poser clairement la question du
démarrage de la JVM. Ce n'est pas une opération gratuite, il faut bien
compter quelques secondes pour cela. Comment cela est-il compatible avec
les performances attendues ?

 Je pense que quelques secondes de démarrage (on peut pousser jusqu'à la minute je pense pour maximiser) sur des batchs qui peuvent durer plusieurs minutes voir plusieurs heures n'est pas significatif (si on se base sur les temps des batchs Cobol actuels).

- ne serait-il pas plus simple d'avoir une JVM pré-chargée avec le code
à exécuter, et d'avoir des scripts (shell ou autre) qui déclanchent
l'exécution de ce code au travers d'une invocation type REST ou autre ?
Cela éviterait d'avoir à lancer une JVM à chaque fois

Effectivement, si on veux pousser le gain de temps au maximum en restant dans ce cadre cela pourrait être une solution. J'ai néanmoins quelques craintes sur la durée de connexion entre le script et le service appelé, mais c'est à approfondir.

Merci pour vos retours

[Emmanuel Lécharny]

Le 4/19/12 3:28 PM, Baptiste MATHUS a écrit :

Tu n'as pas tort. J'ai mal interprété le texte initial. Si le temps
d'exécution des batches est >> au temps de lancement de la JVM, KISS...

[Emmanuel Lécharny]

Le 4/19/12 3:32 PM, jeremy.herault a écrit :

>
> Le jeudi 19 avril 2012 14:32:45 UTC+2, elecharny a écrit :
> - ne serait-il pas plus simple d'avoir une JVM pré-chargée avec le code
>> à exécuter, et d'avoir des scripts (shell ou autre) qui déclanchent
>> l'exécution de ce code au travers d'une invocation type REST ou autre ?
>> Cela éviterait d'avoir à lancer une JVM à chaque fois
>>
> Effectivement, si on veux pousser le gain de temps au maximum en restant
> dans ce cadre cela pourrait être une solution. J'ai néanmoins quelques
> craintes sur la durée de connexion entre le script et le service appelé,
> mais c'est à approfondir.

Comme Baptiste (et toi même) le signalez, les batches vont tourner sur
plusieurs minutes. Dans ce cas, on s'en cogne un peu du temps de
chargement la JVM.

Keep it simple, je crois que c'est la clé.

[Laurent Forêt]

Je suis désolé je n'ai pas de retour mais comme je vais être en charge d'une problématique similaire dans peu, je suis intéressé par la question.

Le peu que j'ai pu comprendre de ce genre de problématique m'oriente pour l'instant vers la démarche suivante 

  - Traduction du code  Cobol en expression de règles métiers en Français par les cobolistes  et experts fonctionnels.

  - Interprétation de ces règles métiers et description en une DSL via Groovy (à la recherche de bons pointeurs sur ce sujet)

  - Expression des règles métiers via cette DSL.

Si le temps me manque je pencherai plutôt pour un traducteur Cobol --> java.

Par avance, merci pour tes retours.

Laurent Forêt
http://www.devcoop.fr

2012/4/19 jeremy.herault <jeremy....@gmail.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/lescastcodeurs/-/Ygs29z-cMiAJ.

Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

[Manu]

Moi je regarderais soit Spring Batch soit Talend ETL en fonction du type de traitement fait par les batchs.

De part mon expérience, les deux sont de bonnes solutions et permettent de conserver de très bonnes performances !

Manuel

2012/4/19 Laurent Forêt <lauren...@gmail.com>

[jeremy.herault]

Salut Manuel,

As-tu plus d'infos ou peux-tu en dire un peu plus ? quels sont les types de traitements que tu as réalisés et par rapport à ces types quelle est la solution que tu as utilisée ? as-tu également une fourchette sur le volume de données que tu as manipulé ?

Merci

[Manu]

Talend ETL, c'est bien pour extraire des données depuis une source pour les charger dans une autre source (E-T-L :) )

Soit en direct soit le plus souvent en passant par un fichier intermédiaire.

Par contre pour des traitements plus métiers avec des calculs qui ont plutôt tendance à rester dans la même base,

je pencherais pour Spring Batch car on a un vrai langage de programmation (Java) pour implémenter cette logique.

Et Spring Batch structure assez intelligemment notre code pour que les performances soient bonnes et que le batch

soit maintenables.

Je l'ai mis en place pour plusieurs clients dont certains avec des millions de lignes à traiter (pas à chaque fois hein ;) ).

Je ne te donne pas vraiment de chiffres parce qu'avec les batchs, ca n'est pas assez représentatif.

En fonction des traitements, des données manipulées, des possibilités de découper le batch pour le multi-threader, etc.

on n'aura pas deux batchs qui donnent les mêmes temps. Souvent, la contrainte est posé autrement :

 - "J'ai une plage de 2h pour ce batch entre 3 et 4h du matin, il faut que le traitement rentre dans ce créneau !"

PS: un article intéressant sur Spring Batch

http://jduchess.org/duchess-france/blog/les-dessous-de-spring-batch/

2012/4/19 jeremy.herault <jeremy....@gmail.com>

Salut Manuel,

As-tu plus d'infos ou peux-tu en dire un peu plus ? quels sont les types de traitements que tu as réalisés et par rapport à ces types quelle est la solution que tu as utilisée ? as-tu également une fourchette sur le volume de données que tu as manipulé ?

Merci

Manuel

2012/4/19 Laurent Forêt <lauren...@gmail.com>

Laurent Forêt
http://www.devcoop.fr

2012/4/19 jeremy.herault <jeremy....@gmail.com>

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/lescastcodeurs/-/6vkhn0pjOlAJ.

[Benito D'almeida]

Spring Bach en mode multi thread
La dernière est excellent

Benito d'ALMEIDA

> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.

[jeremy.herault]

Ok, merci pour ces quelques retours et Manuel pour tes précisions.

Devoxx France se terminant ce soir, on devrait avoir plus de retours par la suite :-)

Merci

[Patrice Trognon]

well, pas le temps de lire tout le thread trop de taf, donc je vais répondre en direct sur mon expérience
dans ce domaine.J'ai codé pas mal de chose qui ressemble a du batch (batch = gros traitements
lourds sur les données sql ou autre), voici les soucis rencontrés. attention c'est à remettre dans
le context de l''époque à savoir 2006 à 2008, mais finalement les problématiques sont peut être
toujours d'actualité.

1/ des gros soucis avec les drivers sql utilisés qui étaient assez pourris, dans notre cas c'était le driver
mysql qui ne gérait pas du tout le fetch-size correctement, a savoir même en l'initialisant le driver montait
tous les résultats des querys en mémoire d'ou des gros soucis de OutOfMemory et de lenteur.

On avait finit par solutionné en découpant nos querys avec les clause LIMIT de mysql, workaround a plein pif quoi.

2/ les reprises sur erreur SQL, cas typique l'admin qui décide de rebooter la base alors que le traitement
est en cours, casse burnes mais il ne voulait pas en démordre.

La solution apporté était de redévelopper une couche entre le driver et le code pour gérer toutes les exceptions SQL
afin de faire de la reconnexion automatique sans perte, bien sur certains cas sont ingérable au niveau bas il faut
les remonter dans le code métier, cela à donc un impact sur la façon de coder les batchs.

3/ fonctionnalité de batchs du driver jdbc mysql ne servant à rien si ce n'est coller les perfs au tapis

4/ faire attention aux faux amis de jdbc, genre modification d'un query pendant son execution, en fait cela genérait
de l'update en douce, effroyable pour les perfs !

5/ j'avais eu des soucis énormes sur les perfs avec jdbc en général sur des traitement bulk, grosso modo la solution
appliquée et validée à l'époque par le consultant mysql avec été de faire des dump des données a traiter dans
des fichiers plat, traiter les données dans le fichier plat, puis import bulk du fichier dans la base. bien crade
mais on avait des ratios de fois 10 au niveau des perfs.

bref, fait très attention au driver jdbc, le gros des problèmes venait de lui !

Pat

[David Screve]

Par expérience, le portage de batch de Cobol abouti à des désastres en
matière de performance....SpringBatch semble proposer des choses
intéressantes...dans la pratique, le développeur va appliquer les même
recette que dans une appui J2EE, va coller Hibernate, et on va se
retrouver avec des temps épouvantables....

Donc, ça marche, ici, on l'a fait, et on l'a passé avec $U, mais il a
fallut concevoir toute un cadre pour avoir les bons drivers au bon
endroit, spécifier une arborescence d'exécuter bien définit, et il y a
aussi un gros boulot sur la partie code de retour.

Enfin, côté développement, les développeurs Java n'ont en général
aucune culture du mode Batch, et c'est là que le bât blesse...
Du coup, la question devient : Est-ce que Java est vraiment fait pour
du traitement batch et de l'ordonnancement ?

J'ai envie de répondre par la négative.....

[Emmanuel Lécharny]

Le 4/20/12 4:47 PM, David Screve a écrit :

> Enfin, côté développement, les développeurs Java n'ont en général
> aucune culture du mode Batch, et c'est là que le bât blesse...
> Du coup, la question devient : Est-ce que Java est vraiment fait pour
> du traitement batch et de l'ordonnancement ?
>
> J'ai envie de répondre par la négative.....

C'est un peu paradoxal... Tu dis que les développeurs Java n'ont pas de
culture du batch, et tu en déduis que Java n'est pas fait pour du batch.
J'aurai plutôt tendance à penser que soit tes développeurs Java sont
mauvais, soit qu'ils ne sont pas correctement formés.

[Patrice Trognon]

soit que le langage n'est pas adapté à l'écriture de batch.

ensuite il faut s'entendre sur ce que l'on appelle un batch, pour moi c'est un enchainement de gros traitements
en base de données, quelle qu'elle soit.

Du reste l'expérience que je relatais n'est pas a proprement parler du batch, puisque c'était des daemons qui se
déclenchaient sur un événement (présence de fichiers à traiter), pour ensuite faire ses traitements.
Un batch à plus tendance a se déclencher à heure fixe pour effectuer un gros traitement en base, d'ou des temps
de transaction trés long ce qui n'est pas anodin, très long = éventuellement plusieurs heures.

Java n'est pas adapté pour l'écriture de batch, mais pour en avoir écrit dans différent langage je n'ai jamais
trouvé le nirvana :
PL/SQL : fait pour mais interaction effroyable avec autre chose que la base, et sacrée boite noir au debug.
C/C++ : beaucoup de sueur sur le traitement des erreurs, pas du tout adapté
Java : Le moins pire, mais pas non plus adapté.

Pat

> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

[Manu]

Je ne comprends pas ce qui vous fait que Java n'est pas adapté au batch.

Et non il ne faut mieux pas utiliser Hibernate pour du batch en effet.

[Patrice Trognon]

parce que c'est un langage orienté objet, pour écrire des batchs l'idéal c'est un langage orienté données

ce qu'il n'est pas.

mais bon, comme j'ai dit précédemment il est le moins pire de ce que l'on a à notre disposition aujourd'hui

si l'on exclu les langages de scripting a la Perl qui sont une horreur en debug et en maintenance.

Pat

[Moandji Ezana]

2012/4/21 Patrice Trognon <ptro...@gmail.com>

parce que c'est un langage orienté objet, pour écrire des batchs l'idéal c'est un langage orienté données

ce qu'il n'est pas.

C'est quoi, un langage orienté données?

Moandji

[Patrice Trognon]

PL/SQL en est un, pas franchement le pied a programmer on est d'accord, mais il est orienté uniquement base de données donc

si ton batch doit aussi interagir avec l'OS c'est mort.

Bref, un langage qui va te permettre de te concentrer uniquement sur les traitements et non sur tout ce qui vient autour,

peut être qu'une réponse serait un framework apportant toutes ces features à Java ou par exemple on pourrait lancer

les traitements SQL ou autre avec des points de callback pour les événements se produisant (erreur, timeout, ...).

Bon, tu m'oblige à le citer, Cobol en est le parfait exemple, en cela a mes yeux il n'a jamais été remplacé en mieux.

Bien avant l'existence de Java j'avais été amené a en développer un que j'avais orienté sur les traitements SQL

et les traitements de fichiers que l'on avait a faire, bref c'était totalement propriétaire pour notre besoin, une fois 

le langage définit ce qui avait été rapide (vive lex et yacc), j'avais ensuite écrit tous les traitements métier

avec, comme un PL/SQL si tu veux mais avec les ouvertures vers les fichiers.

Cela m'avait permis d'aller beaucoup plus vite sur l'écriture des traitements métier, et surtout de pouvoir les confier

à des développeurs ne connaissant pas le C puisqu'ils avaient juste a apprendre mon petit langage qui était super 

simpliste.

Alors faire la même chose pour un besoin plus général j'ai bien conscience que cela serait plus long, mais faisable,

en générant du java en dessous bien sur ainsi cela tournerai dans la vm.

Pat

[Jeff MAURY]

Salut,

pour moi, la problématique principale ne vient pas de la conversion des batchs vers Java mais plutôt de la conversion des données.
Parce que si tu te contentes de traduire les batchs en Java et de laisser les données sur le Z, alors autant aller crier "Vive Mélenchon" à un meeting MLP.
J'ai vu des batchs Java fait avec Hibernate et le problème ne venait pas d'Hibernate mais plutot de l'utilisation qui en était faite (pas de cache secondaire, multitude de sessions établies)

A+
Jeff

2012/4/21 Patrice Trognon <ptro...@gmail.com>

--
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury

[Henri Gomez]

Le 19 avril 2012 14:32, Emmanuel Lécharny <elec...@gmail.com> a écrit :

Tout dépend du temps d'exécution des jobs de batchs actuels.
S'ils durent des minutes ou des heures, le coup de démarrage de la JVM
sera insignifiant.

> A froid, si on ne peut pas éliminer $U, c'est un peu ce que je ferai... pas
> vous ?

dans l'idéal oui, un Jenkins ferait parfaitement l'affaire.

Reste que $U c'est du giron des équipes de production qui n'ont peut
être pas envie de retoucher des chaines de productions qui datent de
plusieurs années.

[Henri Gomez]

pour moi, la problématique principale ne vient pas de la conversion des batchs vers Java mais plutôt de la conversion des données.
Parce que si tu te contentes de traduire les batchs en Java et de laisser les données sur le Z, alors autant aller crier "Vive Mélenchon" à un meeting MLP.
J'ai vu des batchs Java fait avec Hibernate et le problème ne venait pas d'Hibernate mais plutot de l'utilisation qui en était faite (pas de cache secondaire, multitude de sessions établies)

Je plussoie car j'ai connu il n'y a pas si longtemps, dans un cadre batchs RPG/CL vers Java. 

Il n'y a pas de bonnes solutions (Hibernate ou JDBC) mais l'idée clé c'est de réduire le transfert de données (in et out).

Des moteurs de traitement par ruptures peuvent donner de très bons résultats en tout cas, permettant de travailler par lots, mais je ne sais pas s'il en existe en OpenSource (à l'époque nous avions utilisés une implémentation interne).

[Bruno Margerin]

Tous a fait d'accord avec l'idee de rester le maximum dans la base de donnee.

En fait, je recommenderais de lire la doc de spring batch. C'est une bonne introduction au concept de batch. Moi j'ai bien aime' l'approche the Task -> Task instance -> Task execution.

Pour moi, il y a des points distincts auquels il faut penser:

 - Idee de workflow. Quelle responsabilite est ce  ? Ton scheduler ? Spring batch ? Une "Decision Table" (desole pour le franglais), un moteur de regle ? 

 - Idee de distribution de charge. Y a il besoin de distributer le travail sur plusieurs servers ? Si oui Comment le faire sans dependences entre les servers. Et pour le messaging? . JMS/Web Services ? Hadoop ? 

 - Performance. Comme descris precedemment, garde le maximum dans la base de donnee (en esperant qu'elle puisse tenir), Si tu a besoin the sortir les donnees et les traiter en dehors de la base de donnee, considere le concept "d'external table". Au boulot j'utilise netezza, et le bulk load/unload, c'est tres rapide. J'imagine que ca doit etre rapide aussi avec d'autre DB. Pense a l'infrastructure materiel ? Quels disks utilisera tu? NAS, SAN ? SSD en local? Pense a avoir deux disks differents (un pour la lecture de donnee), l'autre pour l'ecriture de donnee,

-Si les entrees sorties sont trop lentes, alors, caching, caching, et caching. La RAM est pas chere, et un server avec 200Gb ram, 10GbE et 12 cores coute environ $10000 (du moins de l'autre cote de l'atlantique).

- Gestion d'erreurs. c'est un peu differents que les systemes transactionnelles. Difficile de faire a "roll back" sur 1 000 000 personnes. Difficile d'utiliser 1 transaction par personne aussi. Donc l'idee d'un parking a erreurs (or trash queue, dead queue, etc). ou les donnees qui ont foiree sont envoyees.

 - Gestion de "Crises". C'est l'ecosystem autour de l'envois d'emails aux operateurs en production, pagers. etc. Les "audit de qualites" qui verifient au cours du process si tout va bien (analyse statistique, temps de processing, etc).

- Collisions. Ok, tu as rater ta plage horaire, maintenant un nouveau process doit commencer et l'ancien n'a pas fini. Comment faire pour faire tourner les deux a la fois? Qui a priorite ? Question bonus. C'est une platforme "multi tenant", quel client sacrifier ?

- Maintenant, j'aime bien l'idee de "pre-loader" la JVM pour gagner du temps. Mais je ne conseille pas. Dans un project anterieur, c'est ce que je faisais. Le probleme. c'est que le module "pre-charge'" avait des "memory leaks" et "db connection leaks". Garder la meme JVM pour plusieurs series de process, resultait  a des problemes de ressource au bout de quelques jours. En realiter, je suggere d'isoler les modules dans leurs JVMs respectives. Quand le processing finit, la JVM finit aussi. Au moins ca limite les consequences d'avoir un code ecrit comme un cochon et "the shit does not stick for too long".

Pour ma part, je me suis longtemps demander si je n'allais pas utiliser Spring Batch. Dans mon cas la majeure partie du travail et du risque reside pas dans le "workflow": mais dans la distribution de la charge de travail a travers plusieurs servers, et les "Audits Qualites". Spring Batch n'aide pas trop dans ces aspects.

Enfin, j'ai pomper leur datamodel, et quelques autres bonnes idees, et suis en train de re-ecrire mes  propres modules. J'utilise un "master slave" classique, JMS (une queue pour les job, une queue pour les notification de "completion" une queue pour les erreurs, une queue pour les Email, pagers, etc, une queue pour les logs) et des MDB (limites en nombres) qui attendent , Glassfish (clustered). J'ai regarde Hadoop, mais j'ai des contraintes dans des modules pre-existants qui m'empeche d'utiliser Hadoop DFS. j'appelle les modules qui font les traitement de donnees via une JVM separee, malgre le cout de demarrer plusieurs JVM, et plus important, malgre le cout de perdre je contexe d'erreurs (exception stack, etc). 

En resume, pour ma part, c'est pas trop JAVA ou pas JAVA,  spring batch ou pas, c'est d'avoir penser aux specificites d'un process de batch, et d'avoir une approche pour chacune de ses caracteristiques. 

Bruno

[Xavier Combelle]

Le 21/04/2012 13:25, Patrice Trognon a �crit :
>
> Bien avant l'existence de Java j'avais �t� amen� a en d�velopper un
> que j'avais orient� sur les traitements SQL
> et les traitements de fichiers que l'on avait a faire, bref c'�tait
> totalement propri�taire pour notre besoin, une fois
> le langage d�finit ce qui avait �t� rapide (vive lex et yacc), j'avais
> ensuite �crit tous les traitements m�tier

> avec, comme un PL/SQL si tu veux mais avec les ouvertures vers les
> fichiers.

on peut avoir un exemple du langage pour avoir une id�e

[Patrice Trognon]

Le 21 avr. 2012 à 14:11, Xavier Combelle a écrit :

> Le 21/04/2012 13:25, Patrice Trognon a écrit :
>>
>> Bien avant l'existence de Java j'avais été amené a en développer un que j'avais orienté sur les traitements SQL
>> et les traitements de fichiers que l'on avait a faire, bref c'était totalement propriétaire pour notre besoin, une fois

>> le langage définit ce qui avait été rapide (vive lex et yacc), j'avais ensuite écrit tous les traitements métier

>> avec, comme un PL/SQL si tu veux mais avec les ouvertures vers les fichiers.

> on peut avoir un exemple du langage pour avoir une idée
>

En deux mots c'était orienté traitements en base, donc une intégration du SQL dans le langage, multi-base
puisque une des problématiques était la consolidation de données entre plusieurs bases différentes (Oracle,
SQL-Serveur, ...), plus des keywords permettant de manipuler le filesystem (repertoire, fichier, tris sur fichiers, etc).
typage faible.
Java en était a sa version 1.0.2 quand j'avais fait ça, donc réalisé en c++ avec le parser en lex/yacc, je ne travaille
plus dans la société ou j'avais fait ca dans les années 90, je n'ai plus ces sources :(

Voila.

Pat

[Patrice Trognon]

Le 21 avr. 2012 à 14:11, Xavier Combelle a écrit :

> Le 21/04/2012 13:25, Patrice Trognon a écrit :
>>
>> Bien avant l'existence de Java j'avais été amené a en développer un que j'avais orienté sur les traitements SQL
>> et les traitements de fichiers que l'on avait a faire, bref c'était totalement propriétaire pour notre besoin, une fois

>> le langage définit ce qui avait été rapide (vive lex et yacc), j'avais ensuite écrit tous les traitements métier

>> avec, comme un PL/SQL si tu veux mais avec les ouvertures vers les fichiers.

> on peut avoir un exemple du langage pour avoir une idée
>

tiens, je rebondis sur une expérience plus ancienne encore que celle dont je parlais.
J'avais participé à la refonte de la gescom d'une grosse société de VPC, ils avaient
un site central sur AS/400 et une gescom en écran vert réalisé en Cobol, qui marchait
trés bien mais demandait à etre remise au gout du jour.
Gout du jour = entre 1992 et 1995.
Décors technique :
Le choix se porte sur un Unix d'IBM, donc Aix, sgbd Oracle 7, et réalisation des IHM
avec ce qui était à la mode à cette époque : iLog Views.

Décors humain :
Une gescom le métier est monstrueux, donc 3 domaines fonctionnels (Commande, Stock
et Ventes), pour chaque domaine un directeur de projet, 2 à 3 chefs de projet, 3 à 4 développeurs
par chef de projets, ces développeurs venaient du gros système donc connaissaient Cobol
et RPG (un truc proprio as/400).
Impossible de se passer d'eux, car ils ont la connaissance métier.
Impossible de faire monter des jeunes développeurs c++ en compétence rapidement sur le
métier, les docs fonctionnelles faisaient plus d'un mètre de haut pour chaque domaine !

Pour concilier les deux, et tu vas voir que l'on revient à notre sujet voici la solution adoptée :
une petite équipe de dev c++ sur la partie ihm ilog views (3 personnes)
une petite équipe de dev c++ sur les classes utilitaires (OCI d'Oracle, plus grosso modo
classe de collection et compagnie pour faire vite)
une équipe de dev qui à réalisé un AGL orienté métier (conception des écrans fonctionnels,
et écriture des règles métiers a l'aide d'un langage orienté données et fonctionnel qui était
très proche d'un cobol ou rpg qu'ils connaissaient parfaitement).
Une fois les libs réalisées, et l'agl, les équipes fonctionnels ont pu réaliser la gescom
avec ces outils, et ce sont les outils qui ont généré le code c++ qui était compilé sur l'Aix.

Voila, on revient en plein dans ce que je disais avant, c++ était inadapté pour écrire
des batchs et des traitements métier, car trop compliqué à maitriser techniquement
on l'a donc caché afin que les développeurs métier puissent se concentrer sur leurs règles
qui ont leur propre complexité sans être gêné par le langage. Si on n'avait pas eu cette
approche le projet aurait été un Titanic.

J'ai à peu prêt le même avis sur Java et sa complexité pour ce type de développeurs, par
exemple je n'ai jamais compris les divagations EJBesques et les horreurs qui viennent avec
puis ensuite toutes les divagations qui ont suivi ou on ne cesse de nous expliquer que
ces n frameworks ont pour but de permettre au développeurs métier de réaliser des applies
fonctionnels.
Depuis toujours je pense qu'un bon gros AGL permettant de faire ses écrans, ses bindings
sgbd, et décrire ses règles (cela peut se faire à la souris avec une approche basé sur des
organigrammes), le tout générant le java + swing ou le java + web, aurait été une bien
meilleur approche que ces frameworks qui changent de cheval tous les 6 mois.

Pat (Le vieux con de service)

[Quang Hung]

Bonjour, 

Même si la liste a déjà beaucoup réagi à ce sujet, je voudrais te   raconter mon (seul vrai) expérience sur le batch (même si cela semble être différent de ton problème). 

A l'époque (2003/2004), nous devions parser les gros fichiers xml (environ 1000 fichier allant de 5Mo à 70/80 Mo /fichier) pour en extraire des données métier et les injecter/alimenter dans une base de donnée (Oracle). Initialement les outils ont été écrit en C (et je ne sais plus quoi). Au fil du temps (et des départs) il n'y avait plus personne qui avait assez de connaissance (et surtout d'envie) pour les maintenir. Il a été décidé de le porter en Java (80% de l'équipe étaient des dév Java). Et au final ça a donné (en gros)

- 1 scheduler lancé par le cron qui va créer les tâches et les stocker dans la base (1 tâche = 1 fichier xml à traiter)

- 1 ensemble de dispatcher qui viennent chercher les tâches dans la base pour les découper en opération (1 opération = 1 type de données à extraire du xml) --> les tâches sont également stockées dans la base avec certaines infos/attributs liés à la tâche/opération (statuts, id worker, # dates, le nom de la classe Runnable à exécuter, etc) et les fichiers xml sont copiés du dépôt central (nfs) au répertoire local de la machine (on avait plusieurs noeuds de traitement)

- 1 ensemble de worker (sur les noeuds de traitement) qui viennent chercher les opérations et instancier les Runnable associée et les lancer via le pool de threads (ou un nouveau thread si demandé). a la fin de chaque opération, le worker met à jour les infos dans la base.

 

- 1 master qui surveille l'avancement des opérations et mettent à jour le statut les tâches (quand toutes ses opérations sont traitées) et notifie le système métier quand une tâche est finie. Il surveille également les tâches pour éviter un dead-lock (erreur perpétuelle ou crash des workers) - le master avait lui même un backup. 

Au bout de plusieurs itérations, on avait pu rendre le système assez générique pour traiter aux tâches (autre que le parsing xml) et le temps de traitement global a été fortement réduit par rapport à la version C (car on avait pu paralléliser les traitements et répartir la charge sur différentes machines). 

Et comme certains l'ont déjà dit, à la fin notre point de contention était la connexion vers la base (injection des données extraites dans la base métier) - et aussi la copie des gros fichiers (et beaucoup --> jusqu'à 10 000 fichiers de plusieurs centaines de MO) à travers le réseau. 

Je crois qu'à l'époque il n'y avait pas encore de framework batch comme Spring Batch.

Voilà un petit retour d'expérience.

@]++

QHung

2012/4/19 jeremy.herault <jeremy....@gmail.com>

Bonjour,

Dans le cadre d'une migration potentielle de batchs Cobol vers Java,
et dans le cadre d'un développement from scratch de batchs Java,
j'aurais voulu avoir des retours d'expériences sur les technos que
vous avez pues utiliser, ainsi que le volume de données manipulées
lors des traitements. Je précise qu'il s'agit de migration à la mano,
pas de fainéantise en utilisant un traducteur Cobol-->Java quel qu’il
soit.

Pour vous situez dans quel cadre je me situe, le scheduler utilisé (et
qui le restera) est $U (Dollar Universe). Actuellement, il ordonnance
des scripts UNIX dans lesquels les appels aux programmes Cobol sont
effectués. Le volume de données manipulées par les batchs Cobol va de
plusieurs centaines de milliers au million de lignes.

Merci pour vos retours.

--
Jérémy

[Patrice Trognon]

Le 24 avr. 2012 à 11:03, Quang Hung a écrit :

> Bonjour,

>
>
> Au bout de plusieurs itérations, on avait pu rendre le système assez générique pour traiter aux tâches (autre que le parsing xml) et le temps de traitement global a été fortement réduit par rapport à la version C (car on avait pu paralléliser les traitements et répartir la charge sur différentes machines).

Surtout que pour avoir benché cette partie les implémentations xml/xsl en C sont pourris comme ce n'est pas permis,
leur équivalent dans le monde java est au bas mot 5 à 10 fois plus rapide !

Pour ce genre de traitement je pars sur du java directement !

Pat

[Manu]

Et pourtant dans tes batchs, il y a bien des traitements métiers à appliquer avec une logique de coneption, etc ...

Du coup ton language orienté donnée, il est à la ramasse sur la structuration et l'algorithmie.

Pour moi, Java est très bien adapté et avec les progrès fait depuis le début sur les perfs de la JVM,

les performances sont loin d'être ridicules !!

Les batchs existants étaient souvent codés avec les pieds alors avec un peu de rigueur dans la conception

du batch, on arrive même plus souvent qu'on le croit à faire plus rapide qu'un batch existant :)

2012/4/21 Patrice Trognon <ptro...@gmail.com>

[Manu]

En fait, c'était du Pro-C non ;)

2012/4/24 Patrice Trognon <ptro...@gmail.com>

[Patrice Trognon]

le prob du Pro-C c'est la dernière lettre : C

Donc oui sans le C, cad sans ses dangers.

du Pro-Basic si tu préfères :)

Pat

[Patrice Trognon]

Le 24 avr. 2012 à 11:20, Manu a écrit :

Et pourtant dans tes batchs, il y a bien des traitements métiers à appliquer avec une logique de coneption, etc ...

Du coup ton language orienté donnée, il est à la ramasse sur la structuration et l'algorithmie.

je n'ai pas besoin d'héritage de polymorphisme pour faire de l'algorithmie, if et while suffisent :)

Attends, j'essaye de me souvenir, les machines de turing elles étaient objet ? La machine

de Pascal elle était objet ?

sic

[David Screve]

Il faut recadrer les choses : quand on fait du traitement batch, on
traite des données structurées en base de données...pas des
objets...donc un langage objet n'est pas forcément un bon choix.

Le problème de java, c'est qu'il est calqué sur C/C++ et donc c'est un
langage générique, fait pour faire de la programmation système de bas
étage pas du tout fait pour gérer des problématiques de traitement par
lot, de la reprise sur erreur, la gestion des codes de retour,
etc...bref, tout ce que SpringBatch a essayé de recoder.

En plus, Java est foncièrement nul pour traiter des date et des
données financières nativement, puisqu'il faut lui coller les
BigInteger et autres gadgets.

Ca sera la même histoire quand il va falloir gérer des caches de
chargement de données : il faudra tout se palucher.

Bref, ce n'est pas fait pour cela...C'est un peu comme les moteurs de
règles qui se prennent des branlées face à un programme Prolog.

Donc, faire du Batch avec Java, c'est une solution de replis, à la
limite avec SpringBatch, mais ce n'est pas fait pour cela...mais comme
c'est à la mode de coller du Java partout en entreprise, ben faut bien
s'y résigner....

Au passage, Cron pour faire de l'ordonnancement c'est bien pour
dépanner, mais à des années lumières d'un $U.

On 24 avr, 11:25, Patrice Trognon <ptrog...@gmail.com> wrote:
> Le 24 avr. 2012 à 11:20, Manu a écrit :
>
> > Et pourtant dans tes batchs, il y a bien des traitements métiers à appliquer avec une logique de coneption, etc ...
> > Du coup ton language orienté donnée, il est à la ramasse sur la structuration et l'algorithmie.
>
> je n'ai pas besoin d'héritage de polymorphisme pour faire de l'algorithmie, if et while suffisent :)
>
> Attends, j'essaye de me souvenir, les machines de turing elles étaient objet ? La machine
> de Pascal elle était objet ?
>
> sic
>
>
>
>
>
>
>
> > Pour moi, Java est très bien adapté et avec les progrès fait depuis le début sur les perfs de la JVM,
> > les performances sont loin d'être ridicules !!
> > Les batchs existants étaient souvent codés avec les pieds alors avec un peu de rigueur dans la conception
> > du batch, on arrive même plus souvent qu'on le croit à faire plus rapide qu'un batch existant :)
>

> > 2012/4/21 Patrice Trognon <ptrog...@gmail.com>

> > PL/SQL en est un, pas franchement le pied a programmer on est d'accord, mais il est orienté uniquement base de données donc
> > si ton batch doit aussi interagir avec l'OS c'est mort.
>
> > Bref, un langage qui va te permettre de te concentrer uniquement sur les traitements et non sur tout ce qui vient autour,
> > peut être qu'une réponse serait un framework apportant toutes ces features à Java ou par exemple on pourrait lancer
> > les traitements SQL ou autre avec des points de callback pour les événements se produisant (erreur, timeout, ...).
>
> > Bon, tu m'oblige à le citer, Cobol en est le parfait exemple, en cela a mes yeux il n'a jamais été remplacé en mieux.
>
> > Bien avant l'existence de Java j'avais été amené a en développer un que j'avais orienté sur les traitements SQL
> > et les traitements de fichiers que l'on avait a faire, bref c'était totalement propriétaire pour notre besoin, une fois
> > le langage définit ce qui avait été rapide (vive lex et yacc), j'avais ensuite écrit tous les traitements métier
> > avec, comme un PL/SQL si tu veux mais avec les ouvertures vers les fichiers.
>
> > Cela m'avait permis d'aller beaucoup plus vite sur l'écriture des traitements métier, et surtout de pouvoir les confier
> > à des développeurs ne connaissant pas le C puisqu'ils avaient juste a apprendre mon petit langage qui était super
> > simpliste.
>
> > Alors faire la même chose pour un besoin plus général j'ai bien conscience que cela serait plus long, mais faisable,
> > en générant du java en dessous bien sur ainsi cela tournerai dans la vm.
>
> > Pat
>
> > Le 21 avr. 2012 à 13:06, Moandji Ezana a écrit :
>

> >> 2012/4/21 Patrice Trognon <ptrog...@gmail.com>

[Manu]

C'est pour ça que j'ai ajouté la notion de structuration.

Si tu veux simplifier, réutiliser, abstraire, factoriser, le PL/SQL c'est chouette (irony inside).

Au contraire, je ne traite pas les batchs comme les parents pauvres de l'application avec juste

une vocation brutale de traitement des données en masse.

C'est un vrai composant de l'application qu'il va falloir maintenir et faire évoluer.

Rien de tel qu'un langage objet pour ce travail !

2012/4/24 Patrice Trognon <ptro...@gmail.com>

[Manu]

2012/4/24 David Screve <david....@gmail.com>

Le problème de java, c'est qu'il est calqué sur C/C++ et donc c'est un
langage générique, fait pour faire de la programmation système de bas
étage pas du tout fait pour gérer des problématiques de traitement par
lot, de la reprise sur erreur, la gestion des codes de retour,
etc...

C'est vrai que la gestion des erreurs de PL/SQL ca fait rêver !

Et puis ton traitement Java s'appuie sur SQL pour accéder à la base, tu peux même dans certains cas

appeler une procédure PL/SQL. Mais Java apporte plein de choses quand même pour structurer.

Et SpringBatch cherche aussi à t'aider à structurer ton batch, à le découper en étape, justement pour favoriser

la reprise en cas d'incident. Bref à facilietr la maintenance et la robustesse de ton batch !

Quand je regarder la structuration d'un batch habituellement, moi ca me fait saigner les yeux :)

[David Screve]

On 24 avr, 11:41, Manu <mekt...@gmail.com> wrote:
> 2012/4/24 David Screve <david.scr...@gmail.com>

>
> > Le problème de java, c'est qu'il est calqué sur C/C++ et donc c'est un
> > langage générique, fait pour faire de la programmation système de bas
> > étage pas du tout fait pour gérer des problématiques de traitement par
> > lot, de la reprise sur erreur, la gestion des codes de retour,
> > etc...
>
> C'est vrai que la gestion des erreurs de PL/SQL ca fait rêver !

Oh, attention, je n'ai pas dit que PL/SQL était bien.....j'ai dit que
Java n'était pas forcément adapté....il y a une nuance entre les 2...

> Et puis ton traitement Java s'appuie sur SQL pour accéder à la base, tu
> peux même dans certains cas
> appeler une procédure PL/SQL. Mais Java apporte plein de choses quand même
> pour structurer.

Je n'ai pas dit cela...j'ai dit qu'il ne me paraissait pas très adapté
car conçu pour développer des problématiques où la POO est bien
adaptée...
Java n'est pas adapté à faire du match comme un AS/400 est
redoutablement plus efficace et robuste qu'un système UNIX...Au
passage, l'AS/400 va mettre une branlée à Unix pour les traitements
match.

> Et SpringBatch cherche aussi à t'aider à structurer ton batch, à le
> découper en étape, justement pour favoriser
> la reprise en cas d'incident. Bref à facilietr la maintenance et la
> robustesse de ton batch !

Oui, c'est ce que je disais, c'est une bonne avancée...mais ça reste
de la glue qu'on colle à un truc pas adapté à la base.

Il faudrait sérieusement repenser à un langage adapté à ce genre de
problématique, quoiqu'un ETL soit déjà fait pour cela, en partie.

> Quand je regarder la structuration d'un batch habituellement, moi ca me
> fait saigner les yeux :)

Ce qui signifie que le langage n'est pas adapté pour exprimer les
traitements à faire.

CQFD.

David

[David Screve]

On 24 avr, 11:36, Manu <mekt...@gmail.com> wrote:


> Rien de tel qu'un langage objet pour ce travail !

Non...ce que tu décris, c'est un langage structuré, pas besoin
d'objet, de polymorphisme, d'héritage et de toutes ces
choses...surtout si ta base de données ne l'est même pas.

David

[Manu]

2012/4/24 David Screve <david....@gmail.com>

surtout si ta base de données ne l'est même pas.

La base de données n'est pas objet en effet masi ca ne concerne que les données

pas le programme qui les manipulent qui lui peut l'être :)

Mais sinon d'accord avec toi sur les ETL, je trouve certains produits très bien pensés et très efficace pour des batchs !

Manuel

[David Screve]

On 24 avr, 15:55, Manu <mekt...@gmail.com> wrote:
> 2012/4/24 David Screve <david.scr...@gmail.com>
>

> > surtout si ta base de données ne l'est même pas.
>
> La base de données n'est pas objet en effet masi ca ne concerne que les
> données
> pas le programme qui les manipulent qui lui peut l'être :)

Oui, mais rien ne dit qu'un langage objet apportera réellement un plus
dans la mesure où on n'a pas forcément besoin de cela...Le principal
intérêt d'un langage objet, c'est quand les structures de données en
mémoire sont complexes, où il y a des besoins de polymorphisme, de
généricité et autres bidule qui n'ont aucun intérêt ici. du coup, tu
vas perdre du temps à transformer des données relationnelles en
données objets, les traiter, puis refaire la transformation inverse.
Il te faut un langage pour décrire des transformations, des agrégats,
etc...sur des lots de données, avec des traitements avancés de
rollback, et une gestion efficace des code de retour. Un langage pour
le batch doit aussi savoir traiter les dépassements d'horaires et tous
ces trucs qu'il va falloir coder à la main dans un langage classique.

Mais je reconnais qu'après 30 ans à vendre de l'objet dans les
langages généralistes type C++, Java ou C#, ce n'est pas évident
d'avoir à l'idée qu'on peut faire autrement avec des langages plus
adaptés.

David

[Gabriel Landais]

Le 24 avril 2012 15:55, Manu <mek...@gmail.com> a écrit :

Mais sinon d'accord avec toi sur les ETL, je trouve certains produits très bien pensés et très efficace pour des batchs !

Ca fait un moment que j'ai pas regardé les ETL, il se fait quoi depuis Talend?

[Manu]

2012/4/24 David Screve <david....@gmail.com>

On 24 avr, 15:55, Manu <mekt...@gmail.com> wrote:
> 2012/4/24 David Screve <david.scr...@gmail.com>
>

> > surtout si ta base de données ne l'est même pas.
>
> La base de données n'est pas objet en effet masi ca ne concerne que les
> données
> pas le programme qui les manipulent qui lui peut l'être :)

Oui, mais rien ne dit qu'un langage objet apportera réellement un plus
dans la mesure où on n'a pas forcément besoin de cela...Le principal
intérêt d'un langage objet, c'est quand les structures de données en
mémoire sont complexes, où il y a des besoins de polymorphisme, de
généricité et autres bidule qui n'ont aucun intérêt ici. du coup, tu
vas perdre du temps à transformer des données relationnelles en
données objets, les traiter, puis refaire la transformation inverse.

Non justement, je ne te parle pas d'utiliser systématiquement Hibernate,

tu peux structurer tes traitements en objet et manipuler tes données par lot,

de façon relationnelle, hiérarchique ou autre.

 

Il te faut un langage pour décrire des transformations, des agrégats,
etc...sur des lots de données, avec des traitements avancés de
rollback, et une gestion efficace des code de retour. Un langage pour
le batch doit aussi savoir traiter les dépassements d'horaires et tous
ces trucs qu'il va falloir coder à la main dans un langage classique.

Un langage ou un framework avec un bon dsl. Parce que le langage dont tu parles,

c'est juste que derrière des mots-clés dédiés à la problématique des batchs, il va automatiser

certains aspects, te masquer la tuyauterie, te gérer plein de choses de façon native.

C'est justement l'objet d'un framework, si en plus ils offrent un bon DSL, c'est la fête !

Il faudrait un Apache Camel du batch :)

 

Mais je reconnais qu'après 30 ans à vendre de l'objet dans les
langages généralistes type C++, Java ou C#, ce n'est pas évident
d'avoir à l'idée qu'on peut faire autrement avec des langages plus
adaptés.

Oui tu as peut être raison. J'ai peut être un marteau dans la main et je vois tous les problèmes

sous la forme de clous. 

D'un autre côté, developper des batchs en Java est vraiment faisable alors pourquoi mixer plusieurs

langages etchnologies dans une équipe alors qu'on peut uniformiser ?

Plus simple à maintenir, homogène voire même partage du code et des traitements métiers entre le mode batch et le mode "TP".

Manuel

[Manu]

En Open Source, j'ai pas vu grand chose de nouveau mais je ne suis pas ça de très près non plus.

Sinon il en existe plein de commerciaux ;)

2012/4/24 Gabriel Landais <gabriel...@gmail.com>

Le 24 avril 2012 15:55, Manu <mek...@gmail.com> a écrit :

Mais sinon d'accord avec toi sur les ETL, je trouve certains produits très bien pensés et très efficace pour des batchs !

Ca fait un moment que j'ai pas regardé les ETL, il se fait quoi depuis Talend?

--

[Emmanuel Lécharny]

Le 4/24/12 4:20 PM, David Screve a écrit :

Je pense que c'est un faux débat. L'adéquation d'un langage par rapport
à un besoin fonctionnel donné ne s'étudie pas par rapport à la capacité
du dît langage à traiter rapidement (ou pas) les données en
input/output. Dire qu'un langage objet va 'perdre du temps à transformer
des données relationnelles en données objets', c'est passer sous silence
que le temps de transformation, pour autant qu'il soit supérieur en
langage Objet par rapport à un langage structuré type C, est totalement
sans importance quand on le met en rapport avec le temps d'accès aux
données en elles mêmes.

Et je parle d'ordres de magnitude, ici.

Après, que Java pur soit insuffisant pour traiter des problématiques
batch, clairement, oui. Mais c'est le cas de tout langage. Ce qui
importe, c'est l'outillage qui vient avec le langage. Un bon ETL sera de
toute manière plus performant, même écrit en Java, en première approche,
que le même traitement écrit à la mano, si on considère que ce
développement spécifique n'aura pas forcément pris en compte les
différents aspects techniques impactant les perfs.

C'est peut-être aussi pour cela qu'il existe encore plein de
développeurs COBOL, qui codent au plus près des données, plutôt que de
confier ces tâches à des développeurs Java, ce qui imposera des
transferts de données très coûteux...

Je pense qu'il serait plus intéressant de revenir dans le cadre de la
question initiale : existe-t-il de bons frameworks en Java, en dehors de
Spring-batch, qui aiderait un développeur sans le contraindre à
réinventer la roue ?

NIH syndrom, on n'a rien inventé de pire depuis le VIH...

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Emmanuel Lécharny]

Le 4/24/12 4:37 PM, Manu a écrit :

> En Open Source, j'ai pas vu grand chose de nouveau mais je ne suis pas ça
> de très près non plus.

http://www.manageability.org/blog/stuff/open-source-etl

Mais aucune idée si c'est du tout bon ou de la crotte en barre...

[Manu]

C'est sur, plus tu es loin des données, pire ce sera !

2012/4/24 Emmanuel Lécharny <elec...@gmail.com>

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Emmanuel Lécharny]

Le 4/24/12 4:50 PM, Manu a écrit :

> C'est sur, plus tu es loin des données, pire ce sera !

On est *toujours* loin des données, quand il s'agit de les traiter par
millions...

[David Screve]

On 24 avr, 16:36, Manu <mekt...@gmail.com> wrote:
> 2012/4/24 David Screve <david.scr...@gmail.com>

>

> Non justement, je ne te parle pas d'utiliser systématiquement Hibernate,
> tu peux structurer tes traitements en objet et manipuler tes données par
> lot,
> de façon relationnelle, hiérarchique ou autre.

Je n'ai pas parlé d'hibernate....mais dans la pratique, c'est ce que
tu feras quand tu vas sérialiser tes objets...

>
> Un langage ou un framework avec un bon dsl. Parce que le langage dont tu
> parles,
> c'est juste que derrière des mots-clés dédiés à la problématique des
> batchs, il va automatiser
> certains aspects, te masquer la tuyauterie, te gérer plein de choses de
> façon native.
> C'est justement l'objet d'un framework, si en plus ils offrent un bon DSL,
> c'est la fête !

Ben alors à quoi ça sert un langage si un bon framework suffit ?
Autant faire de l'assembleur avec un bon framework, et basta les 40
ans d'évolution des langages...Oui, je sais, c'est un peu trollesque,
mais c'est un peu ce que tu dis en caricaturant....J'ai un ami qui
disait que Java était le Cobol des années 2000, et bien des fois je me
dis qu'il n'as pas totalement tord.

>
> Oui tu as peut être raison. J'ai peut être un marteau dans la main et je
> vois tous les problèmes
> sous la forme de clous.
> D'un autre côté, developper des batchs en Java est vraiment faisable alors
> pourquoi mixer plusieurs
> langages etchnologies dans une équipe alors qu'on peut uniformiser ?

Ben maintenant que tout le monde a des processeurs x86, autant faire
de l'assembleur....ou du C...Pourquoi du Java qui est un langage même
pas normalisé au niveau ISO ? Oui, je troll un peu....:-)

David

[Manu]

Je ne nourris pas les trolls revient avec des vrais critiques/arguments :)

2012/4/24 David Screve <david....@gmail.com>

David

[Manu]

Bon finalement je ne tiens pas !

Mais je vais plutôt te caricaturer à ton tour :)

Donc dans ta vision il faudrait :

 - un langage dédié IHM côté client

 - un langage dédié côté serveur/controlleur

 - un langage dédié web services

 - un langage dédié accès base

 - un langage dédié batch

 - un langage dédié règles métiers

 - un langage dédié traitement XML

 - etc

Manuel

2012/4/24 David Screve <david....@gmail.com>

David

[Patrice Trognon]

il me semble que le sujet est épuisé, tout a été dit ou presque.

en conclusion on tombe forcement en sujet trollesque en allant plus loin 

non ?

pourquoi argumenter des heures pour celui qui ne veut lire/comprendre, différent

avis ont été exprimés c'est parfait, chacun y pioche ce qu'il souhaite à la lumière

de son expérience ou de ce qu'il veut faire, surtout comment il veut le faire.

Pat

[Patrice Trognon]

prenons un exemple, juste un seul en fait.

traitement sur des fichiers, leur enveloppe, ou sur leur contenu, fichier de type texte, parsing de logs par exemple.

j'ai toujours fait ça en Perl sans une seule goute d'objet dedans ça ne sert à rien.

des batchs, pour en revenir aux batchs, justement si ils ne doivent faire que des manips sur des fichiers le Perl 

est parfait, par contre si ils doivent aussi faire des traitements en sgbd ca recommence à puer un peu plus.

Si je fais ce genre de traitement je n'ai que faire d'une approche objet qui ne va me servir a rien du tout

et les structures existant dans Perl (Scalar, Array, Hash) sont assez puissantes et rapides pour bon nombre

de traitements, sans avoir a pondre des pojo a tout va qui ne sont finalement que de vulgaires structures.

Et je peux te dire qu'un stagiaire m'a fait le coup une fois de me coder des traitements sur des fichiers en java

il a entendu parler du pays pendant toute la journée, son programme utilisait 95% de son temps a lancer la VM.

Alors j'entends d'ici les hurlements : ouaih c'est impossible à maintenir !

Balivernes et fumisterie, le code est maintenable si il est écrit pour l'être quelque soit le langage, j'ai connu

un gars qui écrivait des scripts shell qui étaient bien mieux écrire que nombre de code source de langage 

objet que j'ai pu lire !

Voila un exemple.

Ce qui me gene d'une manière générale c'est la monoculture, un seul langage est rarement LA bonne réponse

a toutes les problématiques, je pense qu'il est bon d'en connaitre plusieurs et de savoir les utiliser en fonction

des situations.

Tu as pu remarquer dans mes propos que je suis parfois critique sur tel ou tel langage, et que à l'inverse je vais

plussoyer le même langage sur un autre domaine (dans le thread présent sur les traitements XML j'avais

fait une remarque dans ce sens).

On rencontre trop souvent dans nos métiers des ingés qui connaissent un langage et vont a tout prix vouloir

le faire rentrer dans tous les besoins, c'est distordre la réalité que de faire cela car partir d'une solution pour

la faire correspondre a un besoin je suis désolé mais c'est la démarche inverse de celle que l'on doit avoir.

Pour en revenir aux traitements sur des données, Emmanuel l'a dit dans sa réponse et je suis 100% d'accord

avec lui, on n'a jamais inventé mieux que le cobol, il était fait pour et d'une simplicité d'apprentissage très rare !

Pour en revenir au propos initial on a juste émis l'idée, l'avis, que java n'est pas le langage le plus adapté

pour faire des batchs, cela malgres certains framework qui essayent de combler les manques. Voila, c'est un

avis, pas besoin de débattre des heures dessus, on est d'accord ou pas.

Alors maintenant tu veux quoi ? qu'on te dise ce que tu veux entendre pour te conforter dans ton choix,

ben je vais te le dire : C'est formidable utilise un seul et même langage pour tout faire, il sait tout faire et

il le fait mieux que n'importe quoi d'autre.

c'est fait !

Pat (juste un peu énervé la)

[Manu]

Je ne cherche rien à part un bon échange d'argument et des avis critiques pour me chambouler/conforter

dans mes idées : c'est ça un débat. Il n'y a que toi à prendre ça comme un avis d'évangéliste ou d'intégriste.

Mais il est vrai que dans ce genre d'échange, on a tendance à prendre une position un peu tranchée pour

pousser l'autre dans ses retranchements et du coup éprouver les idées de chacun !

Je n'ai jamais dit, mettez du Java partout dans toutes les applis quoi qu'elle fasse.

Je suis aussi partisant d'utiliser un langage adapté dans chaque situation.

Tu as une tendance à prendre des racourcis et à tirer des conclusions attives, fait attention ;) 

Je défendais juste l'idée que le langage Java soit tout à fait adapté à écrire un batch et que de mon point

de vue, un langage orientée donnée ne solutionne pas tout non plus ...

Mais bon, je commencais aussi à arriver à la conclusion qu'on avait fait le tour du débat !

Mais j'y peux, je suis toujours attiré par les joutes verbales (ou écrites), c'est mon côté démocratie participative ;)))
Mais moi je débat et je ne m'énerve pas par contre, j'écoute les arguments de l'autre et j'y réflechis calmement.

Manuel, calme et détendu :)

2012/4/24 Patrice Trognon <ptro...@gmail.com>

prenons un exemple, juste un seul en fait.

[Patrice Trognon]

Dans le texte.

Le 24 avr. 2012 à 19:23, Manu <mek...@gmail.com> a écrit :

Je ne cherche rien à part un bon échange d'argument et des avis critiques pour me chambouler/conforter

dans mes idées : c'est ça un débat. Il n'y a que toi à prendre ça comme un avis d'évangéliste ou d'intégriste.

Mais il est vrai que dans ce genre d'échange, on a tendance à prendre une position un peu tranchée pour

pousser l'autre dans ses retranchements et du coup éprouver les idées de chacun !

Je n'ai jamais dit, mettez du Java partout dans toutes les applis quoi qu'elle fasse.

Je suis aussi partisant d'utiliser un langage adapté dans chaque situation.

Tu as une tendance à prendre des racourcis et à tirer des conclusions attives, fait attention ;) 

Pas faux je te l'accorde.

Je défendais juste l'idée que le langage Java soit tout à fait adapté à écrire un batch et que de mon point

de vue, un langage orientée donnée ne solutionne pas tout non plus ...

Mais bon, je commencais aussi à arriver à la conclusion qu'on avait fait le tour du débat !

Mais j'y peux, je suis toujours attiré par les joutes verbales (ou écrites), c'est mon côté démocratie participative ;)))
Mais moi je débat et je ne m'énerve pas par contre, j'écoute les arguments de l'autre et j'y réflechis calmement.

Ok, j'avais vu une certaine provocation dans ton mail précédent qui a eu tendance à me coller les abeilles alors que comme tu le dis aussi on a plus ou moins fait le tour du sujet, d'ou la réponse montant d'un cran.

Bref, affaire réglée :)

Manuel, calme et détendu :)

Idem, je cuisine, je suis toujours calme et détendu quand je cuisine :)

[Manu]

Parfait, en plus par écrit, le ton n'y est pas, si on se rencontrait de visu, tu verrais que je suis plutôt constructif

et respectueux dans les débats mais à l'écrit ca ne se voit pas !

Mon mail précédent sur un langage pour un besoin c'était pour répondre dans le ton à celui de David

qui me proposait de faire de l'assembleur. Je pensais faire de l'humour plus qu'autre chose !

Au prochain débat donc !

Bonne soirée !

2012/4/24 Patrice Trognon <ptro...@gmail.com>

Dans le texte.

[David Screve]

On 24 avr, 18:29, Manu <mekt...@gmail.com> wrote:
> Bon finalement je ne tiens pas !
> Mais je vais plutôt te caricaturer à ton tour :)
>
> Donc dans ta vision il faudrait :
>  - un langage dédié IHM côté client
>  - un langage dédié côté serveur/controlleur
>  - un langage dédié web services
>  - un langage dédié accès base
>  - un langage dédié batch
>  - un langage dédié règles métiers
>  - un langage dédié traitement XML
>  - etc
>

Sans reprendre ton découpage pas forcément adapté car c'est un
découpage trop technique à mon sens, je dirais Oui, si ça peut
permettre de traduire plus facilement en langage informatique le
besoin initial de l'utilisateur. Comme on utilise majoritairement des
langages faiblement contextuel et totalement déterministe, on est
obligé de les spécialiser pour avoir une puissance d'expression
adaptée au contexte.
L'idéal serait bien sûr de pouvoir utiliser le langage naturel.

Par exemple, ça ne viendrait à l'idée de personne de sérieux de coder
un compilateur dans un langage impératif directement.

David

[David Screve]

On 24 avr, 18:29, Manu <mekt...@gmail.com> wrote:

> Bon finalement je ne tiens pas !
> Mais je vais plutôt te caricaturer à ton tour :)
>
> Donc dans ta vision il faudrait :
>  - un langage dédié IHM côté client
>  - un langage dédié côté serveur/controlleur
>  - un langage dédié web services
>  - un langage dédié accès base
>  - un langage dédié batch
>  - un langage dédié règles métiers
>  - un langage dédié traitement XML

J'ajouterai que déjà, tu codes tes IHM en HTML côté client pendant que
tu proposes de coder le reste en Java....donc, on diverge déjà.
On pourrait parfaitement envisager un langage de description de
traitement batch sur ce même modèle. Après, le compilateur pourrait
générer du code natif ou pour une JVM ou un CLR, peu importe.

David

[Emmanuel Lécharny]

Le 4/24/12 10:09 PM, David Screve a écrit :

>
> Par exemple, ça ne viendrait à l'idée de personne de sérieux de coder
> un compilateur dans un langage impératif directement.

Ton clavier a dû fourcher, je pense ? La plupart des compilateurs ont
été écrit en langage impératif, cela ne pose pas de problème majeur. En
pratique, l'écriture d'un compilateur dans un langage Objet n'apporterai
pas grand chose (même si on considère qu'avec antlr, l'écriture d'un
compilo en Java est une tâche relativement aisée, cela n'implique pas
qu'il faille utiliser massivement l'héritage ou l'encapsulation).

Ou alors ta phrase manque de contexte... Tu peux préciser ta pensée ?

[Rémi Forax]

On 04/25/2012 01:05 AM, Emmanuel L�charny wrote:
> Le 4/24/12 10:09 PM, David Screve a �crit :
>>
>> Par exemple, �a ne viendrait � l'id�e de personne de s�rieux de coder
>> un compilateur dans un langage imp�ratif directement.
>
> Ton clavier a d� fourcher, je pense ? La plupart des compilateurs ont
> �t� �crit en langage imp�ratif, cela ne pose pas de probl�me majeur.

oh, si, oh, si.
C'est pour cela que le C oblige a mettre les d�clarations avant les
d�finitions.
En Object ou en fonctionnel, c'est tr�s facile de ne pas avoir ce genre
de limitation,
en C de base c'est tout de suite bcp plus chiant (basiquement tu as
besoin de continuation).

> En pratique, l'�criture d'un compilateur dans un langage Objet
> n'apporterai pas grand chose (m�me si on consid�re qu'avec antlr,
> l'�criture d'un compilo en Java est une t�che relativement ais�e, cela
> n'implique pas qu'il faille utiliser massivement l'h�ritage ou
> l'encapsulation).

Le compilo est un endroit o� justement tu as de beau arbre d'h�ritage
pour l'arbre de syntaxe,
l'arbre des types et o� tu fait de l'annotation d'arbre et de la
r�-�criture d'arbre.
Oui tu peux tout faire en C, mais un language Objet ou fonctionnel te
rendra les choses
bcp plus ais� car tu pourra utiliser respectivement du pattern-matching
ou le visitor pattern.

>
> Ou alors ta phrase manque de contexte... Tu peux pr�ciser ta pens�e ?
>
>

salut,
R�mi

[Patrice Trognon]

Le 25 avr. 2012 à 03:11, Rémi Forax a écrit :

> On 04/25/2012 01:05 AM, Emmanuel Lécharny wrote:
>> Le 4/24/12 10:09 PM, David Screve a écrit :
>>>
>>> Par exemple, ça ne viendrait à l'idée de personne de sérieux de coder
>>> un compilateur dans un langage impératif directement.
>>

>> Ton clavier a dû fourcher, je pense ? La plupart des compilateurs ont été écrit en langage impératif, cela ne pose pas de problème majeur.
>
> oh, si, oh, si.
> C'est pour cela que le C oblige a mettre les déclarations avant les définitions.
> En Object ou en fonctionnel, c'est très facile de ne pas avoir ce genre de limitation,

> en C de base c'est tout de suite bcp plus chiant (basiquement tu as besoin de continuation).
>

tut tut tut.
petite confusion objet et java la !
c++ et obj-c qui sont des langages objets imposent aussi les déclarations avant les définitions,
c'est java qui a cassé ce modèle de compilation basé sur les .h, ce n'est pas l'objet.

Perso, cette approche introduite par java et reprise depuis m'a choqué quand c'est sorti, et continue
à me déranger, question d'habitude je pense mais j'aime bcp bichoner mes .h.
Quand je lis du code souvent je n'ai pas à ouvrir le fichier d'implémentation pour comprendre ce que
fait telle ou telle classe et comment elle le fait, la lecture de son .h suffit bien souvent, et c'est bien
plus synthétique.

Pat

>> En pratique, l'écriture d'un compilateur dans un langage Objet n'apporterai pas grand chose (même si on considère qu'avec antlr, l'écriture d'un compilo en Java est une tâche relativement aisée, cela n'implique pas qu'il faille utiliser massivement l'héritage ou l'encapsulation).
>
> Le compilo est un endroit où justement tu as de beau arbre d'héritage pour l'arbre de syntaxe,
> l'arbre des types et où tu fait de l'annotation d'arbre et de la ré-écriture d'arbre.

> Oui tu peux tout faire en C, mais un language Objet ou fonctionnel te rendra les choses

> bcp plus aisé car tu pourra utiliser respectivement du pattern-matching ou le visitor pattern.
>
>>
>> Ou alors ta phrase manque de contexte... Tu peux préciser ta pensée ?
>>
>>
>
> salut,
> Rémi

[David Screve]

on est d'accord, on a fait le tour de la question.

On 24 avr, 18:36, Patrice Trognon <ptrog...@gmail.com> wrote:
> il me semble que le sujet est épuisé, tout a été dit ou presque.
> en conclusion on tombe forcement en sujet trollesque en allant plus loin
> non ?
>
> pourquoi argumenter des heures pour celui qui ne veut lire/comprendre, différent
> avis ont été exprimés c'est parfait, chacun y pioche ce qu'il souhaite à la lumière
> de son expérience ou de ce qu'il veut faire, surtout comment il veut le faire.
>
> Pat
>
> Le 24 avr. 2012 à 18:26, Manu a écrit :
>
>
>
>
>
>
>
> > Je ne nourris pas les trolls revient avec des vrais critiques/arguments :)
>

> > 2012/4/24 David Screve <david.scr...@gmail.com>

[David Screve]

> > Par exemple, ça ne viendrait à l'idée de personne de sérieux de coder
> > un compilateur dans un langage impératif directement.
>
> Ton clavier a dû fourcher, je pense ? La plupart des compilateurs ont
> été écrit en langage impératif, cela ne pose pas de problème majeur.

pas d'accord : le parseur n'est jamais écrit en langage impératif...on
utilise des générateurs de parseur de type lex/yacc/bison ou autre.
La génération de code par contre, est souvent codée en langage
impératif.

Faut être un peu fracasse pour se taper un évaluateur d'expression
parenthésée à la mano alors qu'il y a des outils qui génèrent les
arbres d'évaluation tout seuls...

>En
> pratique, l'écriture d'un compilateur dans un langage Objet n'apporterai
> pas grand chose (même si on considère qu'avec antlr, l'écriture d'un
> compilo en Java est une tâche relativement aisée, cela n'implique pas
> qu'il faille utiliser massivement l'héritage ou l'encapsulation).
>
> Ou alors ta phrase manque de contexte... Tu peux préciser ta pensée ?

Je parlais de la grammaire.

[David Screve]

On 25 avr, 09:47, Patrice Trognon <ptrog...@gmail.com> wrote:
> Le 25 avr. 2012 à 03:11, Rémi Forax a écrit :
>
> > On 04/25/2012 01:05 AM, Emmanuel Lécharny wrote:
> >> Le 4/24/12 10:09 PM, David Screve a écrit :
>
> >>> Par exemple, ça ne viendrait à l'idée de personne de sérieux de coder
> >>> un compilateur dans un langage impératif directement.
>
> >> Ton clavier a dû fourcher, je pense ? La plupart des compilateurs ont été écrit en langage impératif, cela ne pose pas de problème majeur.
>
> > oh, si, oh, si.
> > C'est pour cela que le C oblige a mettre les déclarations avant les définitions.
> > En Object ou en fonctionnel, c'est très facile de ne pas avoir ce genre de limitation,
> > en C de base c'est tout de suite bcp plus chiant (basiquement tu as besoin de continuation).
>
> tut tut tut.
> petite confusion objet et java la !
> c++ et obj-c qui sont des langages objets imposent aussi les déclarations avant les définitions,
> c'est java qui a cassé ce modèle de compilation basé sur les .h, ce n'est pas l'objet.

+1

Rémi a dû confondre le codage du parser et le nature du langage....Le
fait est que les parsers C# et Java font plusieurs passes, alors que
le compilateur C/C++/Obj-C ne fait qu'une passe. Mais le coup des
forwards déclarations existe dans tous les langages, y compris en
assembleur où il est indispensable de faire plusieurs passes, comme en
Java.

Les concepteurs de C/C++/Pascal/Obj-C avaient comme objectif de
limiter les passes pour éviter de multiplier les accès disques lors du
parking des .h....ça date de l'époque où on compilait sur disquette...

David

[Emmanuel Lécharny]

Le 4/25/12 10:02 AM, David Screve a écrit :

>
>>> Par exemple, ça ne viendrait à l'idée de personne de sérieux de coder
>>> un compilateur dans un langage impératif directement.
>> Ton clavier a dû fourcher, je pense ? La plupart des compilateurs ont
>> été écrit en langage impératif, cela ne pose pas de problème majeur.
> pas d'accord : le parseur n'est jamais écrit en langage impératif...on
> utilise des générateurs de parseur de type lex/yacc/bison ou autre.
> La génération de code par contre, est souvent codée en langage
> impératif.

Ah, ok, ça éclaire la phrase précédente. Il fallait comprendre :
"Personne n'est assez fou pour écrire une descente récursive à la main
pour écrire un compilateur" (pour autant que le langage cible le
permette !).

Dans ce cadre, oui, lex/yacc/etc est indispensable. Je me suis tapé des
tables shift/reduce à la main pendant mes études, merci, plus jamais ! :)

[Rémi Forax]

On 04/25/2012 10:07 AM, David Screve wrote:
>
> On 25 avr, 09:47, Patrice Trognon<ptrog...@gmail.com> wrote:

>> Le 25 avr. 2012 � 03:11, R�mi Forax a �crit :

>>
>>> On 04/25/2012 01:05 AM, Emmanuel L�charny wrote:
>>>> Le 4/24/12 10:09 PM, David Screve a �crit :

>>>>> Par exemple, �a ne viendrait � l'id�e de personne de s�rieux de coder

>>>>> un compilateur dans un langage imp�ratif directement.

>>>> Ton clavier a d� fourcher, je pense ? La plupart des compilateurs ont �t� �crit en langage imp�ratif, cela ne pose pas de probl�me majeur.
>>> oh, si, oh, si.

>>> C'est pour cela que le C oblige a mettre les d�clarations avant les d�finitions.

>>> En Object ou en fonctionnel, c'est tr�s facile de ne pas avoir ce genre de limitation,

>>> en C de base c'est tout de suite bcp plus chiant (basiquement tu as besoin de continuation).
>> tut tut tut.
>> petite confusion objet et java la !

>> c++ et obj-c qui sont des langages objets imposent aussi les d�clarations avant les d�finitions,
>> c'est java qui a cass� ce mod�le de compilation bas� sur les .h, ce n'est pas l'objet.
> +1
>
> R�mi a d� confondre le codage du parser et le nature du langage....

Que l'on soit bien d'accord, C est aussi expressif que Java mais
j'ai rarement vu un compilo �crit en C qui g�rait des forward refs car
c'est chiant
� g�rer avec un truc qui a pas de GC.
Comme d'hab c'est faisable, je crois que le compilo C++ de HP faisait
un truc similaire pour les templates.
Techniquement, le probl�me est pas qu'il faille �crire plusieurs passes mais
le fait que tu dois it�rer sur ton nombre de d�pendence non r�solu
jusqu'� temps que tu n'en a plus, donc ce n'est pas un truc ou tu peux dire,
si je le fait en deux passes, ou n-passes j'ai r�solu mon probl�me.

> Le fait est que les parsers C# et Java font plusieurs passes, alors que
> le compilateur C/C++/Obj-C ne fait qu'une passe. Mais le coup des

> forwards d�clarations existe dans tous les langages, y compris en
> assembleur o� il est indispensable de faire plusieurs passes, comme en
> Java.

non, tu peux aussi faire du code � trou, que tu remplira plus tard,
c'est ce que font la plupart des assembleurs enfin les plus anciens
car a cause des adressages court/long tu vas souvent ins�rer des NOP.

>
> Les concepteurs de C/C++/Pascal/Obj-C avaient comme objectif de

> limiter les passes pour �viter de multiplier les acc�s disques lors du
> parking des .h....�a date de l'�poque o� on compilait sur disquette...

Les concepteurs de C avait ce but effectivement,
les autres ont commenc� leur language soit en patchant un compilo C
existant soit en �crivant un pr�-processeur par dessus en compilo C
existant.

>
> David
>

R�mi

[Manu]

En Java, il y a les interfaces ;)

2012/4/25 Patrice Trognon <ptro...@gmail.com>

[David Screve]

Rien à voir...Une interface n'est pas une classe...Java force à
mélanger interface d'une classe et implémentation dans le même
fichier, ce qui, implicitement, fait que tu vois l'implémentation
quand tu lis l'interface. Le concept de boite noire de la POO n'est
donc plus respecté. C# a cette même faiblesse.
Là où les interfaces de java sont faibles, c'est qu'elles n'ont pas de
comportement par défaut, contrairement à une classe virtuelle en C++,
et qu'on est obligé d'implémenter toute les méthodes, et, de surcroit,
dans le même fichier .java.
A mon avis, face à C#, Objective-C et C++, les interfaces Java sont
une de ses principales faiblesses et la feature qui a le plus de
retard face à la concurrence.

David

On 25 avr, 20:51, Manu <mekt...@gmail.com> wrote:
> En Java, il y a les interfaces ;)
>

> 2012/4/25 Patrice Trognon <ptrog...@gmail.com>

[Jean Paliès]

Vous voulez sans doute initier un autre thread ? Le sujet des batches en java s'éloigne à grande vitesse.

Jean

Jean Paliès

[Patrice Trognon]

Mouaih, enfin c'est loin d'un .h.

À moins que tu fasses une interface avec l'ensemble des méthodes pour toutes tes classes, et de toute façon tu n'y trouves pas les attributs ;)

Petit canaillou va.

Patrice

[Manu]

Je suis démasqué ;)

2012/4/25 Patrice Trognon <ptro...@gmail.com>

Petit canaillou va.

[Joseph Pachod]

Pour en revenir au sujet "langage OO ou pas pour du batch", perso j'ai
une expérience qui plaide plutôt en la faveur du langage OO. C'était
dans une banque et chaque nuit des batchs tournaient pour plein de
choses pour la plupart liées au fonctionnel. Les batchs étaient, bien
sûr, en cobol...

Mais au delà, ces batchs étaient un vrai fouillis: la compétence
moyenne du développeur cobol ne vole pas haut, du moins à ce que j'en
ai vu, et c'étaient pour l'essentiel du code mal écrit, avec des
optimisations de performance au cas par cas, là où les administrateurs
de la "chaine batchs" étaient venus taper. Les copier/coller étaient
nombreux, le code mort (ou supposé comme tel mais à laisser au cas où)
également, les tests inexistants.

Pire, et c'est là un point essentiel à mes yeux, la logique métier
derrière ces move et autres perform était très peu lisible. On ne
voyait que des codes, flags et autres entiers changer de valeur avec
éventuellement quelques commentaires. Une partie, ou plutôt des
parties, de ce code était également utilisé pour les transactions web
en journée, donc hors du traitement batch.

In fine, ce code exprimait du fonctionnel qui serait bien mieux servi,
à mon sens, par de la programmation objet. Non seulement les outils de
modélisation sont plus nombreux mais le langage permet aussi d'être
plus lisible (enum/constantes communes et réutilisées par exemple).

Après, si les batchs relèvent juste du simple transfert/conversion de
données entre BDD, c'est différent, clair. Mais si de la logique
métier commence à se mêler de tout cela, perso je commencerai à me
poser la question du langage OO.

Côté perfs, au risque d'être naif, je serai moins certain des soucis:
- un code bien fait permet normalement aisément de faire des
optimisations, qui seront réalisées après benchmarking en conditions
réelles,
- sur les millions de lignes que nous traitions, Hotspot et ses
copains devraient avoir le temps d'inliner à mort: les problèmes ne
seront sans doute pas là où on les attend.

Je me contenterai juste de vérifier à priori les performances du
driver, mais bon, faire tourner du java dans un environnement IBM pour
attaquer du DB2 ne devrait pas être sujet à lenteur, ou alors IBM est
vraiment décevant sur ce coup. La technique des fichiers plats évoquée
plus haut serait une solution de repli: la forme des données importe
peu tant qu'elle permet d'être suffisamment rapide. La maintenance et
la lisibilité du code faisant toutes ces manipulations m'importent
bien plus.


En dehors de ce débat sur le langage le plus adapté, un point hyper
important, et déjà évoqué, et la logique de lot de traitement avec
possibilité d'interruption en cours de lot et de reprise, ce qui est
tant important pour les perfs que la robustesse de la chaine.
D'ailleurs, malgré la toute puissance du cobol et l'énorme tas de
serveurs utilisé pour ces traitements batchs, le niveau d'isolation
des transactions avait été baissé, à read committed de mémoire. Ca
avait été la source d'un beau bug à la plus grande perplexité de mes
collègues pour qui le tout puissant couple cobol/DB2 était parfait
ainsi que ces saintes transactions...

[Patrice Trognon]

D'où l'idée d'un AGL métier fonctionnant par écrans + procédures, et générant le code java avec foultitude de règles de validation afin d'éviter ce que tu décris, le code mal gaulé par ces développeurs qui ne volent pas bien haut.
Cela permettrait de garder ces développeurs tout en sachant qu'ils vont produire un code de meilleurs qualité puisque celle ci sera garantie par l'outils.

Parce que ces développeurs qui sont à peine foutus de bien écrire du cobol (puisque tu as ouvert la porte que j'évoquais à mots çaches allons y) imagine les dégâts si tu leur fait coder du java, et quand tu dois en plus leur faire comprendre qu'ils doivent aussi écrire des objets techniques pour que leurs objets métiers puissent bien vivre, ça va te donner une sacrée horreur, et encore heureusement qu'il n'y a pas de gestion de mémoire en java sinon le mur est vite trouvé.

Quand les banques sont passe au java elles y ont vu le cobol des années 2000, ben pour avoir forme nombre de cobolistes à java dans ces années la c'est loin d'être gagné, surtout que rapidement en plus de leurs objets métiers on leur a dit qu'ils allaient aussi devoir faire du java-web, et la on se retrouve à des années lumière de leur métier de base vu que dans la grande majorité ils ne connaissent pas les mots comme thread, socket, port etc.

Bon je m'égare.

Le batchs, sujet de fond, on y reste en fait.

Pendant des années je le suis demandé comme faire en sorte que ces développeurs puissent faire leur boulot, à savoir développer les chaînes qu'ils faisaient hier en cobol maintenant en java, sans que ce ne soit une torture pour eux et pour ceux qui vont devoir reprendre leur code, toutes les réponses proposées depuis ne me conviennent pas car trop technique (il faut bien avoir conscience qu'ils ne conceptualisent pas ce qu'est un objets après des mois d'écriture de java) .
Je suis aujourd'hui convaincu que l'approche par un AGL qui permet de désigner des écrans et des traitements (interactifs ou batch), avec un moteur de génération du code qu'on veut derrière (ejb, java web, Play, swing, ...) est la bonne. Je ne comprend pas pourquoi aucun éditeur n'a eu cette approche.

Mes critiques sur le langage sont toutes plus ou moins dans ce sens, je ne critique par java par rapport à nous/vous développeurs core, je sais bien que lisant du scala le java c'est du petit lait même avec ses framework les plus complexes, quand je critique telle ou telle techno c'est à ces développeurs que je pense, car le simple fait de vous écouter est impossible pour eux ils ne vous comprennent pas, et pourtant ils réalisent les grosses applications des banques en java.

Quand je dis que l'objet ne sert à rien pour faire des batchs, c'est par rapport à eux qu'il faut l'entendre. Bien sur que vous ou moi si on a des batchs à faire on va faire de la poo (enfin juste un peu parce que je ne pense pas que ce soit forcément utiles dans ce cas précis)

Voilà, je voulais juste préciser ma pensée cela demandait un mail un peu plus long.

Patrice

[Joseph Pachod]

Re

Merci Patrice pour cette longue réponse.

Je vais tenter de faire court.

On est d'accord sur le constat, cad bcp de développeurs sont très
moyens, mais pas sur la conclusion à en tirer. Si je te comprends
bien, tu proposes "d'abaisser" les outils pour leur rendre la tache
plus aisée. Perso, je ne pense pas que ce soit possible: si les
développeurs ne montent pas en compétence, le résultat ne sera pas
glorieux quoi qu'il en soit et bien couteux. Au contraire, il faut
qu'ils montent en compétence, et cela passe aussi par avoir des outils
adaptés et non limitatifs. Mais bon, c'est quasi un débat
philosophique en fait.

Si on le prenait à l'inverse: avez vous déjà vu des environnements
fournissant des DSL simplifiés pour permettre à des
développeurs/codeurs métier pas très pointus de faire le boulot donner
un résultat appréciable? Pour ma part, que ce soit dans la banque ou
l'automobile, je n'ai jamais vu ça. Au contraire, ça donne un
pourrissement graduel pas très glorieux et très couteux. Dans la
banque, j'ai vu quelques équipes qui produisaient du bon code, mais ce
n'était guère reconnu et, de façon général, le résultat de l'action
d'un bon développeur qui a monté le niveau au sein de l'équipe. Ces
équipes auraient très bien pu bosser sur des technos plus modernes (et
certaines le faisaient avec succès).

A l'inverse, donner à des développeurs les moyens de leur fonction et
faire en sorte qu'ils s'intéressent me semble plus concluant, même si
je l'avoue mon expérience dans le domaine relève plus de la PME, mais
le fait demeure: le cout, l"efficacité et la maintenabilité n'ont rien
à voir. Et dans un cas comme dans l'autre sur des codebase de plus de
10 ans.

++

[Patrice Trognon]

sur le souhait on ne peut que être d'accord Joseph, maintenant
cette montée en compétence en ont ils les moyens pour l'accomplir,
pour ne citer que quelques facteurs :
le temps de le faire ?
la volonté ?
l'entreprise met elle des plans de formation et d'accompagnement assez
ambitieux en place ?
Et enfin les capacités ?

Dans le meilleurs des mondes je suis d'accord avec tes conclusions, malheureusement
force est de constater que ce n'est que très rarement applicable. D'ou mon approche qui
serait une autre solutions et non la réponse unique.

La ou tu trouves tous ces facteurs réunis (et c'est assez rare) en effet ils vont monter
en compétence, j'ai il y a quelques années accompagné une équipe de développeurs
qui venaient du monde oracle (Forms) pour les faire passer a java/struts, plusieurs
formations prévues, puis accompagnement sur plusieurs mois pour lancer puis contrôler
le bon déroulement du projet, cela a été un succès, pour une seule raison ils avaient
le temps de le faire, une forte volonté qui est aussi venue avec le temps puisqu'au
début ils étaient méfiant par rapport à cet étrange langage qu'était java pour eux, mais surtout
une vraie volonté de leur direction que cela réussisse donc des moyens.

je n'ai rencontré cette configuration que trop rarement à mon gout, et la ou tu n'as pas ces
conditions c'est trop souvent un échec cuisant.
Alors entendons nous bien, que ce soit un échec pour l'entreprise je n'en ai que faire puisqu'ils
ne peuvent que s'en prendre à leur incompétence en management, par contre que cela puisse
mettre des gens sur le carreaux et en situation d'echec personnel la ca me touche beaucoup plus !

C'est aux outils informatiques de s'adapter aux humains et non l'inverse que diable !

Pat

[Baptiste MATHUS]

Salut tout le monde,

Ayè, première version brouillon publiée pour revue de la JSR352 "Batch Applications for the Java Platform" :
http://java.net/projects/jbatch/lists/public/archive/2012-05/message/0

Baptiste

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Joseph Pachod]

Salut Patrice

Etant du genre rapide... je réponds enfin ;)

On est entièrement d'accord sur l'ensemble.

Par contre je me suis toujours demandé si ça existe des équipes à même
de faire proprement du code "métier impératif", genre un cobol mis à
jour, sans que la même équipe soit à même de passer, avec
l'encadrement qui va bien, vers de l'orienté objet.

A l'inverse, quel effet cela a sur une équipe d'être limitée à un
pseudo DSL, du code "métier limité", si elle aurait les capacités de
monter en puissance mais que l'entreprise ne lui en donne pas les
moyens. N'est ce pas démotivant sur le long terme, vu que ça revient à
toujours faire la même chose...?

Après il est certain que je suis un éternel
optimiste/idéaliste/whatever et que je fais dans les voeux pieux là.
Mais bon, c'est un peu le but d'une ML de rêver non ? ;) Mon quotidien
est lui, hum, bien plus opérationnel (mais en progrès, enfin, j'espère
lol)

Encore merci pour ta réponse

++
joseph