Design question for typical Message Based J2EE Apps

Question

We�re building a request/response (synchronous) messaging using MDBs and trying to figure out the �blue print� best practice for all components needed. Please let me know if any of the components below seem suspect, and whether I need to add/remove additional ones.
MDBs: Consume MQ and JMS messages and start a Transaction
Message Request Handlers: are created by MDBs . Receive messages in XML format, use utilities to perform XML marshalling and unmarshalling with Value Objects.
Session Fa�ade: Stateless Session EJB.
Business Delegates: Are called by the Message Request Handler to process the message
Business Objects: Biz logic classes
DAO Layer: Data Access for CRUD operations
Messenger : To create a response message and send it back
How is the Session Facade related to the Biz Delegate. Are they one and the same? Are there any online docs to address these layers?

Answer 1

I was trying not to overly complicate this by inlcuding the data structure, but two of the treesets data:
[model.Role@c7d5 code = [audit] description = [Access to data] name = [JIMS Audit], model.Role@4455 code = [basic] description = [Basic access] name = [JIMS Basic], model.Role@d131 code = [privacy] description = [Access to JIMS privacy data]
locationTypeList=[LocationType@b234 code = [amc] description = [Am. Part Code] name = [amc], LocationType@b1ea code = [mat] description = [Management Indicator Ticket] name = [mat], LocationType@313e code =
There are 3 DAO objects and more need to be added now. The user object will need data from all of them. The JSP's access this data directly. It's needed for security and location roles to determine access to functions and data within the app. The user has groups and these groups have security roles and locations that are separate and yet combine to give individual user access and admin rights. The key is that individual groups have separate data relevant to that group as a module that can be modified, added or removed and yet still combines with other groups data to give a total array of values for the individual user. I'm thinking the nature of the nested objects may require inner classes and/or a decorator pattern, but I'm still thinking though it.
Message was edited by:
jamesEston