Another question on multiple Topics, many Topics-to-one MessageBean, etc.
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Doug_Scott
Posted On:   Monday, March 11, 2002 05:49 PM

Please excuse the n-teenth question on this "topic". If you bear with me, I think you'll discover some new twists that haven't been addressed in previous questions or answers. Or maybe some old twists that I missed... I'm about to embark on a J2EE application that implements JMS as a notification service. I'm hoping that I'll discover new and interesting things (that I'll follow up here) and hear about others (from interested readers) that will keep me from going down blind alleys. Core requirements: E   More>>

Please excuse the n-teenth

question on this "topic". If you

bear with me, I think you'll

discover some new twists that

haven't been addressed in

previous questions or answers.

Or maybe some old twists that I

missed...


I'm about to embark on a J2EE

application that implements JMS

as a notification service. I'm

hoping that I'll discover new

and interesting things (that

I'll follow up here) and hear

about others (from interested

readers) that will keep me from

going down blind alleys.


Core requirements:

  • External configuration

    of message recipients - message

    recipients can register interest

    in message types at any time

    after deployment.

  • External

    definition/creation of

    Topics .

  • Message types map to

    Topics .


    So the first bullet is driven by

    the fact that message recipients

    are unknown to the coder, but

    will be registered by

    administrators, after

    deployment, on an ongoing basis.

    This means (to me, anyway) that

    a single Topic

    typically will handle many

    message types, with a single

    MessageBean consuming

    them and distributing them to a

    list of registered interested

    parties. Why? In a perfect

    world, I'd rather write code

    that dynamically spins up a

    Topic for each

    registered message consumer at

    the point of registration,

    otherwise it feels like I'm

    re-writing features of JMS.

    However, 1) my reading seems to

    reveal that Topic s are

    statically bound in a J2EE

    application context and 2)

    elsewhere in this forum, many

    Topic s have been

    pointed to as a performance hit.

    Am I mistaken? (Question 1)


    Question 2 - elsewhere it has

    been discussed that it's

    possible to map many

    Topic s to a single

    consuming MessageBean ,

    but my cursory examination of

    the deployment descriptors

    leaves me suspicious that I'm

    going to fail in my attempt.

    Specifically it looks like the

    mapping of the Topic is

    handled as a child element of

    the enterprise bean descriptor,

    rather than the other way

    around, as I would expect. I

    think that either the

    configuration is going to yak,

    or the second bean descriptor is

    going to replace the first,

    since they are named the same.

    Anyone with any practical

    experience here, specifially on

    BEA Weblogic?


    So I've talked myself into

    bounding a Topic -space

    with at least one Topic

    to support (intially) all

    messages. However now the

    scaling issues come into play:

    suppose some message types pump

    in lots of messages into a

    Topic , while others

    trickle in messages. The

    consumers of those messages

    don't really know about each

    other's existence, they just

    expect delivery in a timely

    manner.


    This makes me think that I need

    a way to externally spin up a

    new Topic , at such time

    an administrator feels it would

    be a prudent thing, and map the

    very active message types into

    that, while leaving the

    previously clogged

    Topic to the

    less-frequent message traffic.


    My application server is

    Weblogic 6.1, and its

    administration panel and

    documentation lead me to believe

    that I can create

    Topic s at-will. This

    seems neat, but also somehow

    feels too good to be true. It is

    also the thinking behind bullets

    2 and 3. If an administrator can

    create new Topic s, then

    I can give him a mechanism for

    mapping them to the more heavily

    trafficed messages. Am I

    mistaken? (Question 3)


    I guess the last question would

    be what am I missing?

    Admittedly, I've tried to absorb

    alot of information in a short

    time, so the possibility of

    having missed critical

    architectural points, leading to

    wheel reinvention, is not

    insignificant.


    thanks - Doug

  •    <<Less

    Re: Another question on multiple Topics, many Topics-to-one MessageBean, etc.

    Posted By:   Laurent_Mihalkovic  
    Posted On:   Monday, March 11, 2002 09:28 PM

    is your use of message beans a requirement or part of your initial solution?
    About | Sitemap | Contact