> 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?
It honestly depends.
I usually use diferent Remote/RemoteHome interfaces for different clients, but
I've had a few cases in which I pulled some other tricks.
> Is inheritance a good route to pursue to solve the
problem?
Usually, no. An
Entity Bean is more than the class that implements the EntityBean interface. You
have the client interfaces(Local/Remote) and both the assembly and deployment
descriptors. To have "clean" reuse of an EJB we all need component-oriented
facilities for EJB reuse, in the EJB spec. These are promised in the 2.0 spec,
but they don't seem to be part of the 2.1 release. Until that kind of facility
is provided, trying to use inheritance is much more complex with EJBs than with
regular Java classes.
> 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?
In the examples you
provide you may still have another options: containment & agregation.
Granted, it will keep things OO at the possible cost of performance, but you can
always implement optimizations later, after you've collected enough data about
how your system performs and which processes need to improve their performance.
Also, you could have a solution that uses both contaiment and some multi-purpose
tables as a compromise solution that will keep your code pretty much clean while
not resigning performance:
Client A -
Facade/Wrapper/Container (may be a Session Bean, Entity Bean, may be a Java
class, may just be a logical division, embodied by a Remote
interface)
Client B -
Facade/Wrapper/Container (ditto)
Account -
EB
Customer -
EB
CustomerAccountRelation - EB with fields: AccountPK,
CustomerPK, role (String).
And
thus:
Client A ---> Account
----insured---> Contact
Client B ---> Account ----collector--->
Contact
or
even:
Client A --------------->
Account
--insured---> Contact
Client B --------------->
Account
--insured---> Contact
--collector---> Contact
Lastly Charles, some
questions:
How do you feel about creating code that is legacy even
while it still is beta? (esp. if you're upgrading your IDE
soon).
I'm unfamiliar with VAJ/Websphere as an EJB enabled
IDE(been a long time :); is the autogenerated relationship managementent that
complex to manage on your own?
Is performance paramount or is maintenance/ability to
manage change more important?
Juan Pablo Lorandi
Chief Software
Architect
Code Foundry Ltd.
Barberstown, Straffan, Co. Kildare, Ireland.
Tel: +353-1-6012050 Fax: +353-1-6012051
Mobile: +353-86-2157900
www.codefoundry.com
Disclaimer:
Opinions expressed are entirely
personal and bear no relevance to opinions held by my employer.
Code Foundry Ltd.'s opinion is that I
should get back to work.
