Owen You're design looks to handle the problem well. You can even adapt it slightly to get the database to help you with referential integrity.
However, what you are doing is handling the inheritance manually. (This is not intended as a criticism.) EJB does not give you any support to do this. That is why you have to do it manually. You cannot create an Entity EJB that is abstract, and then create sub-classes for Class EJB, Group EJB and User EJB. Remember an EJB is a component. It has at least 2 interfaces (Home and Remote) and 1 class (Bean). Which one(s) do you sub-class? I had exactly the same problem with one of the most common sets of business entities to do with managing participants/parties. These are an abstract class called Party, and 2 concrete sub-classes called Person and Organisation. My solution was to implement an EJB for Party that handled Persons and Organisations. I had to manage the differences between the sub-classes manually. It also meant that my DAO were acting like AbstractFactories in that they could return Person or Organisation details, depending on what was actually retrieved from the db. Hopefully, a future version of the EJB spec will deal with inheritance. HTH James -----Original Message----- From: Owen Fellows [mailto:[EMAIL PROTECTED]] Sent: 02 October 2001 10:58 To: Orion-Interest Subject: RE: Design strategy Hello, We have done a similar thing were we don't know the type of class assign the role except at runtime. The solution we used was to have an Object Type table (contain Class, Group, User). Then created a interface which was Roleable (i.e. this class can have a role assigned). In the database you can store each assignment in a different table (ClassRoles, GroupRoles, UserRoles), or have a generic table that stores Roleable_id, Role_id and Object_type_id. This does have drawbacks e.g. the Database does not have enforced consistence as the Roleable_id is not a foreign key on any one table. It may also be slower to retrieve the Roles for a particular (Class, Group, User) as you will have to lookup it object type and then its roles. (You could always cache object types as there will not be that many). I'm sure you can implement a Bean with the above functionality (we haven't used beans for this so I can help there). Hope this is of some help. Owen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of George Mardale Sent: 02 October 2001 06:06 To: Orion-Interest Subject: RE: Design strategy Hello Alex, Thank you for your prompt response. Your suggestions are excellent. You're right, the analysis is not correct. I tried to reduce the problem to a simple example. To avoid complexity, I just limited the relationships to 1..*. Maybe the example is not the best, but I only wanted to know if I could model the "Abstract being" bean in Orion. There are still 2 issues we are unclear about: 1. what are the advantages of dumping entity Class? (Class has specific fields that Group does not have) 2. could you please detail the best way to implement a *-* relationship in Orion? Thanks, George.
