[J2EE] Which tools can [re]configure messaging at runtime?

Discussion in 'Java' started by Unimaginative Moniker, Aug 30, 2012.

  1. Using JBoss EE 5, I'm trying to figure out which messaging tool I should use to allow classes to be dynamically assigned a messaging queue/topic/buss that may have been created just for them.

    Truly modular, I want to be able to create 'modules' in a send/receive configuration that the user has decided on via some sort of drag-n-drop gui. Sothey drag a few boxes out, connect them with lines. Now that front end (haven't decided which yet) will inform the back end classes to instantiate, and how each will talk to the other.

    Example...

    Class A has data it passes to Class B
    Class B passes that data to Class C
    Class A also sends data directly to Class C

    You see, I want each class to do something with the data, yet have a standard interface to ensure the next class down can/will receive it.

    I've done some pretty interesting things in SE with queues & topics, but the EE env is new to me, and messaging is one area where EE is supposed to shine.

    I keep hearing rumors of EJB going away, but in EE6 3.1 is used... Is JMS and MDBs the real way to future-proof, or do I need to select one of the myriad of ESB messaging packages out there (a la Mule, JBoss ESB, etc.)?

    If it's a matter of personal taste, I understand. I'm interested in how you[could|would] CRUD at runtime your messaging architecture..

    TIA!

    :)
    Unimaginative Moniker, Aug 30, 2012
    #1
    1. Advertising

  2. Unimaginative Moniker

    Lew Guest

    Unimaginative Moniker wrote:
    > Using JBoss EE 5, I'm trying to figure out which messaging tool
    > I should use to allow classes to be dynamically assigned a messaging
    > queue/topic/buss that may have been created just for them.


    Well, the inbuilt JMS queues are what you want. How to configure them
    is another question.

    > Truly modular, I want to be able to create 'modules' in a send/receive
    > configuration that the user has decided on via some sort of drag-n-drop gui.


    I don't know about that, but the management screens for app servers include
    JMS configuration.

    > So they drag a few boxes out, connect them with lines. Now that front end
    > (haven't decided which yet) will inform the back end classes to instantiate,
    > and how each will talk to the other.
    >
    > Example...
    > Class A has data it passes to Class B
    > Class B passes that data to Class C
    > Class A also sends data directly to Class C
    >


    I don't think you should conflate queues with services.

    Queues are like pipes - they're just how the stuff gets there.
    Where it gets is the business of business logic.

    You can have services listen to their own queues, and the
    type of routing you mention can be done various ways, some
    of which you mention in your post.

    > You see, I want each class [sic] to do something with the data,
    > yet have a standard interface to ensure the next class down can/will receive it.
    > I've done some pretty interesting things in SE with queues & topics,
    > but the EE env is new to me, and messaging is one area where EE
    > is supposed to shine.
    >
    > I keep hearing rumors of EJB going away, but in EE6 3.1 is used...


    What rumors? From what sources?

    > Is JMS and MDBs the real way to future-proof, or do I need to


    My vision of the future says to live in the present.

    The best way to future-proof (whatever the heck /that's/ supposed
    to mean!) is to study older Java EE technology.

    > select one of the myriad of ESB messaging packages out there
    > (a la Mule, JBoss ESB, etc.)?


    Depends. What do you need to do?

    > If it's a matter of personal taste, I understand. I'm interested in
    > how you [could|would] CRUD at runtime your messaging architecture..


    "CRUD"?

    It's not a matter of personal taste. You don't use tools for the sake of
    using tools. You use tools appropriate to the demands of the job.

    EJBs are useful where they're useful. Likewise queues. Likewise app
    servers themselves. Asking what to use in advance is a fool's errand.

    In general terms the sorts of things you're asking can be readily
    accomplished using things like queues attached to particular services.
    But queues are not services - they're a distinct layer. They serve
    infrastructure purposes, like performance balancing. The use case
    you described is a business-logic question. You want certain services
    to coordinate in certain ways to process certain scenarios. That's not
    a queue question.

    I worked on a project a few years ago where an earlier programmer had
    stuck a JMS queue into the middle of our Java EE application to communicate
    with a single endpoint from a single client in the same application space.

    Eliminating that queue and an entire subsystem of associated kludgery
    cut project size significantly, allowed us to merge two separate builds into
    one, and concomitantly reduced testing time for the project by 40%.
    That queue subsystem was replaced by a single method call.

    --
    Lew
    Lew, Aug 30, 2012
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. HS1
    Replies:
    0
    Views:
    454
  2. Ross M. Greenberg

    LAMP & J2EE as opposed to LAMP vs J2EE

    Ross M. Greenberg, Dec 12, 2004, in forum: Java
    Replies:
    6
    Views:
    1,388
    Robert kebernet Cooper
    Dec 24, 2004
  3. T.G.
    Replies:
    1
    Views:
    501
    Raymond DeCampo
    Jan 4, 2006
  4. Younger Dryas
    Replies:
    2
    Views:
    2,441
    Sharad Kala
    Feb 15, 2004
  5. mehdi mousavi
    Replies:
    0
    Views:
    1,031
    mehdi mousavi
    Feb 15, 2009
Loading...

Share This Page