Re: Clarification and Messaging

Jaaron,

>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
>
Correct. They can be plain interface/impl separated beans

>  - However, EOB's can take advantage of the Avalon framework
>
Correct.

>  - So in a sense, an EOB could be the object brokering of an Avalon service
>
Yes ish.  The beans for EOB are fine graned, like business objects.  If 
you were going to create an Avalon service that, say, was a whle NNTP 
server, you would probably want to mount it into Phoenix directly.  
Avalon's framework and its implementations are far bigger than EOB's scope.

>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?
>
Nothing being developed currently, but much planned.  We have some small 
"async capability over synchronous transport" due soon.  The trouble is 
that is still client server rather than pub/sub.

>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.
>
Sounds neat.

>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. 
>
They do.  If you make a service/block for phoenix, there is no reason 
that EOB could not support it.

>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.
>  
>
In scope, but out of reach presently.

I was planning to do most of the work in AltRMI and merely use it in 
EOB.  There is plenty of room for multiple implementations though.

Show us the API you were thinking of (and soem example of use) in code 
snippet form if you have the time.

Regards,

- Paul



-------------------------------------------------------
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