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

  • Thread starter Unimaginative Moniker
  • Start date
U

Unimaginative Moniker

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!

:)
 
L

Lew

Unimaginative said:
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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top