j'aurai besoin que les gurus qui traînent par là critiquent un peu les idées que j'ai pour une architecture d'application.
 
donc déjà, le besoin :  
Le produit est sensé permettre le transport et la transformation des flux de la boite. Potentiellement, toute application (quelque soit le langage) doit pouvoir envoyer un flux vers le produit pour demander théoriquement n'importe quoi. Le n'importe quoi doit avoir été implémenté par le produit quand même, c'est du genre transformation, regroupage, utilisation d'outils tiers sur le flux, sortie PDF, impression... Avec éventuellement une notion de priorité sur les flux, pour l'impression par exemple... Le flux d'entrée sera normalisé à terme, mais aujourd'hui il peut avoir n'importe quelle tête.
 
mes idées :  
puisque tout doit pouvoir parler, j'ai pensé à des points d'entrée multiples (webServices, API, Servlet...) qui normaliseraient le flux reçu (en attendant que les applications clientes le fassent elles-même) et l'enverrait vers un EJB Session (stateless ?) qui analyserait le flux pour voir quels sont les traitements à appliquer.  
Chaque traitement possible sera wrappé par un EJB Message (MDB) (gestion de la priorité) qui écouterai une file d'attente. Une file spécifique à chaque traitement donc.
Le sessionBean enverrait donc un message sur la file du traitement et attendrait une réponse dans un topic JMS. A la fin du traitement, le mdb posterai un message sur ce topic. Le topic étant commun à toutes les instances de session bean. Comme chaque flux est identifié, le bean vérifie si le message concerne sont flux, et passe au traitement suivant la cas échéant.  
 
et parce que sinon c'est pas drôle, je vous annonce que JMS et les EJB c'est tout nouveau pour moi, donc si c'est de la mouise, dites-le moi, merci d'avance.

A priori tes idées sont bonnes mais tu t'es posé la question pourquoi tu voulais utiliser des EJB ?  
Essaye de regarder l'alternative Spring + ActiveMQ (ou MQ d'IBM) , tu peux implementer des trés sympatique MDP (message driven Pojo) , c'est leger, flexible car tu te fermes pas la porte car par la suite tu pourras wrapper tes mdp par des EJB ...
http://www.nofluffjuststuff.com/bl [...] emId=96149
 
Sinon si tu as des questions specifique je pourrais peut etre t'aider, vu que je bosse sur une appli d'integration entierement basé sur EJB/MQ

Merci de ton avis éclairé.
 
je pensais mettre un ejb parce que je voulais attendre une réponse de mes mdb, et ça me semblais mieux comme ça.
 
Pour Spring, j'ai peur de rajouter une couche en plus, en j'avais regardé (rapidement) Spring il y a quelques temps, et ça me semblait pas mal abscons...

bon, ben ce que j'ai lu dans l'article que tu as linké est très simpa, ça semble intéressant. J'ai plus qu'à comprendre ce que sont l'injection de dépendances et AOP... et voir ce que Spring propose...

et hop une petite intro spring http://ego.developpez.com/spring/
 

merci merci.
 
Mais bon, comme ça te semble pas être trop pourri (même si j'aimerai avoir d'autres avis, pour la route), je vais commencer par maquéter ce que je décrivais plus haut. Après, je recommencerai avec Spring, pour apprécier la différence.
 

oki, tu bosses avec quel serveur d'appli, JBoss ? et ton implémentation JMS tu a choisis quoi ? je te conseille ActiveMQ

on est tout bleu ici, donc c'est IBM à fond. Le serveur est WebSphere 6.0 et j'essaie d'utiliser le moteur JMS inclus et de me passer de WebSphere MQ (MQ Series). En plus il faudrait que le tout soit valider (pareil pour Spring d'ailleurs, et même pour cette archi à base d'EJB).

hum... j'ai quelques soucis (évidemment) avec ce code là :

public class TheSessionBeanBean implements SessionBean {
 
    private static final long serialVersionUID = 2531865006068619999L;
 
    private SessionContext sessionContext;
 
 
    private Connection taskConnection;
 
    private Session taskSession;
 
    private MessageProducer taskSender;
    
 
    private Session topicSession;
    private MessageConsumer topicSubscriber;
    private Connection topicConnection;
 
    private InitialContext initContext;
    
    public void ejbCreate() throws EJBException {
        System.out.println("dans ejbCreate" );
        try{
        initContext = new InitialContext();
        
        ConnectionFactory taskFactory = (ConnectionFactory) initContext.lookup("jms/con/def" );
        taskConnection = taskFactory.createConnection();
        taskSession = taskConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        
        ConnectionFactory topicFactory = (ConnectionFactory) initContext.lookup("jms/con/topic" );
        topicConnection = topicFactory.createConnection();
        topicSession =
            topicConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        } catch (Throwable e) {
            e.printStackTrace();
        }
        
    }
    public void ejbActivate() throws EJBException, RemoteException {
        System.out.println("dans ejbActivate" );
    }
 
    public void ejbPassivate() throws EJBException, RemoteException {
        System.out.println("dans ejbPassivate" );
    }
 
    public void ejbRemove() throws EJBException, RemoteException {
        System.out.println("dans ejbRemove" );
        try {
            if (topicSubscriber != null) {
                topicSubscriber.close();
            }
            if (topicSession != null) {
                topicSession.close();
            }
            if (topicConnection != null) {
                topicConnection.close();
            }
            if (taskSender != null) {
                taskSender.close();
            }
            if (taskSession != null) {
                taskSession.close();
            }
            if (taskConnection != null) {
                taskConnection.close();
            }
            if (initContext != null) {
                initContext.close();
            }
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }
 
    public void setSessionContext(SessionContext arg0) throws EJBException, RemoteException {
        System.out.println("dans setSessionContext" );
        sessionContext = arg0;
    }
    public SessionContext getSessionContext() {
        System.out.println("dans getSessionContext" );
        return sessionContext;
    }
    
    public String traiterFlux(String flux) {
        try{
            Destination destination = (Destination) initContext.lookup("jms/q/myListener" );
            taskSender = taskSession.createProducer(destination);
            taskSender.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
            taskSender.setTimeToLive(0);
            taskConnection.start();
            Message message = taskSession.createObjectMessage(new ModelBean("traite ça : "+flux));
            taskSender.send(message);
            
 
            Destination topic = (Destination) initContext.lookup("jms/topic/ordonnanceur" );
            
            topicSubscriber = topicSession.createConsumer(topic);
            topicConnection.start();
            Message reponse = topicSubscriber.receive();
            if (reponse == null) {
                return "réponse null";
            }
            return ((TextMessage) reponse).getText();    
        }
         catch (Throwable e) {
            e.printStackTrace();
            return "problème";
        }
    }
}

 
le mdb ne reçoit jamais de message suite à taskSender.send(message); et je fais un Message reponse = topicSubscriber.receive(10000), le mdb commence à travailler après la fin du traitement de l'EJB...
 
qu'est-ce que j'ai raté ?

il se passe rien du tout ou bien ca tre balance un stack trace ?

pas de stack trace, et pas d'appel j'ai mis un point d'arret dans onMessage...
 
chui en train de remanier la gestion des connexions, et accessoirement de les fermer proprement dans des blocks finally...

en fait, il me renvoie systématiquement "réponse null" et ensuite seulement il passe dans le mdb.
 
un problème de connexion/session ?!

Ouais surement, tu utilises WS MQ ? Tu vois pas ton message dans le MQ manager ?  
sinon dans la console d'admin de ws tu peux tester ta connexion JMS

le problème c'est que individuellement, tout fonctionne. C'est uniquement quand je veux tout appeler que ça commence à faire n'imp...
 
Je peux poster dans le topic, dans la queue, je peux recevoir... mais poster dans la queue puis attendre une réponse dans le topic, pas poussib'

 
c'est pas un besoin, ça, c'est un fantasme de spec technique.

et pourtant...

pourtant ?
je pinaille juste sur le vocabulaire, hein, pas sur la faisabilité ou l'interet du truc ..

ah ok
 
bref, spec ou besoin, ça doit faire ça à la fin.
 
sinon, pas d'avis sur le reste ?

j'peux pas avoir d'avis valable sur une archi sans connaître les besoins

euh... c'est ça le besoin, sérieux.
 
tu attends quoi toi ?

tu repasseras quand on saura pour quel secteur d'activité et pour quel service c'est

disons qu'il n'y a pas de cible précise en fait. C'est sensé tout gérer. Tout doit pouvoir entrer, tout doit pouvoir sortir, et doit pouvoir appliquer n'importe quel traitement sur l'entrée pour fabriquer la sortie.
 
principalement, ça doit prendre en entrée un fichier de conf (flux de données), l'envoyer vers un moteur de composition (fabrication de documents) et les retourner en PDF. Mais ce n'est que la première tâche qui sera implémentée, ensuite, une ribambelle d'autre seront ajoutées, que l'on ne connait même pas aujourd'hui.

et ben commence par faire ça, et puis ton boss il reviendra quand il aura une nouvelle feature.

oui, mais le but c'est faire le dev en prévoyant d'implémenter plus tard toutes les features possibles et imaginables.
 
sinon, pour mes soucis d'envoi/réception, pas d'idées ?

KISS, YAGNI
 
Et surtout, n'oubliez pas que 51% des projets d'ERP atteignent soit le double du temps soit le double du budget soit les 2 par rapport aux estimations initiales. 30% des projets ERP sont abandonnés.
 
Quel est le rapport ? ben c'est typiquement le principe des projets ERP le "prévoyant d'implémenter plus tard toutes les features possibles et imaginables."

j'avais bien vu que c'était un truc du style, mais comme on a le temps et le budget, on se lance. Et java a été vendu à mes chefs comme étant la panacée universelle, donc bon...
 
et c'est plus que de la prévision, dans la deuxième boucle, on ajoutera des systèmes de tri des données, de regroupement, d'affranchissement... plein de trucs super cool quoi (). Résultat, j'essaye de voir comment pouvoir implémenter tout et rien à la fois, en gardant tout ça simple. Et je pense même avoir plus ou moins réussi, c'est pas si tordu que ça, si ?
 
bref, personne voit pourquoi je peux pas recevoir de message ?

tu peux montrer le code de ton mdb ?  
sinon t'as tester avec topicSubscriber.receiveNoWait() ?  
 

receiveNoWait() renvoie null aussi, comme le mdb n'est pas appelé...
 

package fr.test.jms;
 
import javax.ejb.EJBException;
import javax.ejb.MessageDrivenBean;
import javax.ejb.MessageDrivenContext;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.Destination;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.MessageProducer;
import javax.jms.ObjectMessage;
import javax.jms.Session;
import javax.naming.InitialContext;
 
import fr.test.jms.model.ModelBean;
 
public class TheBean implements MessageDrivenBean, MessageListener {
 
    private static final long serialVersionUID = 3403509142076163275L;
 
    private InitialContext initContext;
    private Connection connection;
    private Session publisherSession;
    private MessageProducer publisher;
    
    
    public TheBean() {
    }
 
    public void ejbCreate() {
        System.out.println("dans ejbCreate" );
        try {
            initContext = new InitialContext();
            ConnectionFactory factory =
                (ConnectionFactory) initContext.lookup("jms/con/topic" );
            connection = factory.createConnection();
            publisherSession = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        } catch (Throwable e)  {
            e.printStackTrace(System.out);
        }
    }
 
    public void ejbRemove() throws EJBException {
        System.out.println("dans ejbRemove" );
    }
 
    public void setMessageDrivenContext(MessageDrivenContext arg0)
            throws EJBException {
        System.out.println("dans setMessageDrivenContext" );
    }
 
    public void onMessage(Message arg0) {
        System.out.println("dans onMessage " );
        ObjectMessage txtMsg = (ObjectMessage) arg0;
        try {
            String champ = ((ModelBean) txtMsg.getObject()).getChamp();
            System.out.println(champ);
            System.out.println("fin " );
            
            Destination topic = (Destination) initContext.lookup("jms/topic/ordonnanceur" );
            publisher = publisherSession.createProducer(topic);
            connection.start();
            publisher.send(publisherSession.createTextMessage(champ + " reçu !" ));
        } catch (Exception e) {
            e.printStackTrace(System.out);
        }
    }
 
}

 
mais le truc, c'est que le code de l'ejb session a l'air de s'exécuter de façon atomique, il ne semble pas y avoir de concurrence dans l'exécution de l'ejb et du mdb... c'est ça qui me fout dedans.

et voilà la trace :

intéressant : http://java.sun.com/j2ee/1.4/docs/ [...] ml#wp92878

 
cargocult, me voilà !! je vais ajouter un p'tit commit, pour rire...

Ou essaye de foutre ton receive dans une boucle  et catch timeoutexception , juste pour voir si ca fini par arriver, car quand je vois ta stack trace , t'es plus tres loin de la soluce, (tom mdb recois bien le message)

j'ai poireauté 5 minutes l'autre jour, le mdb reçoit le message uniquement une fois l'appel à l'ejb terminé.
 
s'trop les boules !
 
et je comprends pas comment démarrer une transaction... je sens que c'est de la conf coté serveur.

YYYYYEEEEEEEESSSSSSSSS !
 
dans le descripteur ejb-jar.xml, il fallait mettre le type de transaction de l'ejb-session sur Bean, et non pas Container. Et pouf ! ça marche comme je veux.