Clarification and Messaging
J Aaron Farr <[email protected]> Fri, 16 May 2003 13:44:32 -0700 (PDT)
| Newsgroups | gmane.comp.java.eob.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello.
Well, I have my development team at least considering EOB for our object
brokering needs. Before I can sell them completely I need a few clarifications
myself:
- EOB's do not need to extend or use any Avalon API's
- However, EOB's can take advantage of the Avalon framework
- So in a sense, an EOB could be the object brokering of an Avalon service
Additionally, we do a lot of JMS work and I noticed that in your J2EE
comparison table you have the Messaging solution blank. Is something in the
works?
We have a simplified Message Driven Bean (MDB) server which I've been hoping to
port to Avalon for a while now. In considering our messaging options, I've
entertained the idea of working up an Avalon based server which could
potentially do the following:
- Host MDBs (perhaps with some limitations)
- Host custom Messaging Bean which could be an Avalon component
- perhaps have stateful and stateless message bean implementations
- A Message Driven Controller : think the Struts ActionServlet design
- a configurable Message Listener could call message actions
- forward results to other message destinations
- perhaps support forwarding to non-JMS destinations
and so on.
I'm not completely sure how much support I want to give to MDBs. Perhaps it
would be better to offer some sort of adaptor for MDB's one way or the other.
Anyway, these are just early ideas, although some of the code base is already
existing. I'm just wondering if any of these ideas sound interesting to EOB.
In some sense Messaging might be out of your original scope, but having such an
Avalon-compliant system would help round out the Avalon application server
offerings.
Thanks!
jaaron
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful,
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge