We have a requirement that it would seem using EJB inheritance would be a nifty solution. However, it seems that we are limited by our current IDE from using inheritance the way I would like.
Here's an oversimplified model: suppose Client A wants a model which has an association such as Account <--> Contact, where a Contact instance serves in role "insured". Client B wants a model which holds the same structure just mentioned, but adds an additional association between Account and Contact where Contact serves in role "collector".
Although we could just make the associations between Account and Contact many-to-many, that's not the central issue here. The central issue is that there are different structural requirements from client to client. If I try to use EJB inheritance, then I model Client A with Account <--> Contact, and I extend the Account EJB for client B by adding another association to my "new" EJB, customized for Client B, which extends Client A's version. The structural differences from client to client may not just be association-based, but certain clients may need additional fields and not use existing fields. We want to be able to maintain the integrity of our common code base as we bring on new clients, with minimal impact to existing code.
It's problematic to use inheritance in the way I'd like here. In my IDE (VisualAge for Java 3.5.3, moving soon to 4.0), if I want to extend EJBs I am forced to place them in the same "EJB Group" (when an EJB Group contains Entities, it maps to a single database schema). I can't easily separate the EJBs by client or even by level-of-abstraction. If I try to fudge the inheritance myself, then much of the automatic code generation which maintains the associations and generates the database schema is incomplete (the inherited associations are not auto-generated into the schema) and unmaintainable (if I change it and then edit anything my edits are automatically overwritten). If I add a new association between an inherited EJB and an existing EJB (such as between Client B's Account and existing Contact) then the code for Contact is modified in order to maintain the bidirectionality of the association. If I don't want the existing Contact to be modified, then I have to descend Contact as well, and customize it as well for client B.
So, I invite your thoughts:
- How are others out there managing to support multiple clients, whose structural data needs may vary somewhat, while maintaining the integrity of the common code all clients depend on?
- Is inheritance a good route to pursue to solve the problem?
- Should I resign myself to having one giant "all-inclusive" schema for all clients with possibly many sparsely populated columns because they are used only by certain clients?
Charles May
Software Engineer
Technology Delivery Department (TDD)
Mellon Financial Corporation
Pittsburgh, PA
business: mailto:[EMAIL PROTECTED]
