MDB doing too much processing - bad design?


EJB design: MDB doing too much processing - bad design?

  1. MDB doing too much processing - bad design? (5 messages)

    I understand MDB are just a special case of SLSBs. However, I can't find information explaining if doing too much bussiness logic inside a MDB is considered to be a bad design. Should a MDB do message processing only and delegate bussiness logic to SLSBs?. We are facing this design problem in one of our projects. In one of the sketches we have done, the MDB has to make some DB inserts + other bussiness logic, and we are a bit concerned whether this should be avoided or not. Does a MDB perform equal to a SLSB?

    Thanks in advance,

  2. Dislaimer: I'm not too experienced with MDBs, so please correct me if I've got something wrong here!

    Q: "too much business logic inside a MDB is considered bad design"
    A: MDB does not make any difference if you think about dividing code into several classes instead of one huge class. If there are parts of logic that are intuitively possible to encapsulate into a helper class, by all means do so. It clears up your code and the performance hit doesn't exist (the opposite is more likely).

    Q: "Should MDB do message processing only and delegate business logic to SLSBs?"
    A: In my opinion, the MDB should only delegate - not do any processing itself unless we're talking about really small stuff (something like 100 lines of code), which can easily and cleanly be implemented as the MDBs private methods etc.
    About delegating to SLSBs - I don't see why you should use an EJB at all for this unless the processing requires (sub)transactions or you have the components already implemented.

    Q: "Does a MDB perform equal to a SLSB?"
    A: Well, MDB is acting asynhronously (unlike SBs) so the response time requirements are probably a lot lighter. There should be no big difference in the performance of MDB lifecycle management compared to SLSBs, but there could be some gap between the invocation process (MDB is listening for a queue/topic, while the SLSB is invoked using RMI). I don't know.
  3. Too much processing in a MDB ca actually good design bc MDB are asynchronous, then the user is not going to suffer from your processing!
  4. long as does not contain 15,203 lines of processing logic...
  5. Hi!

    I do not agree here!!!

    I think an MDB should parse the message and delegate to an SLSB. Are there any clients suffering from this? No! Reasons for my opinion:
    - You can test (and debug!) the business logic in the SLSB standalone without using any messaging.
    - It is possible to reuse the same business process in a synchronous call if you want to in the future.
    - Using this extra layer in the design, makes it possible to use different programmers for messaging stuff and business logic. This may be of interest in a large project.

  6. Being able to test your code outside of the MDB could be taken one step further. If the code does not need any services provided by the container you could implement the logic in a plain old java object.