We are in the process of thrashing out the specs for a new product, and we
are now at the stage where we are thinking of architectural issues.

We have one major issue.

We envisage that the system must be scaleable to the extent that application
server type services will be required. However, the system we are developing
is a piece of software for general sale. In many cases, the overhead of an
app server will not be a major concern, because the cost of the system will
justify the cost of the app server.

Unfortunately, for smaller customers, given the cost of app servers, this
will not be the case, and we will need the system to work without an app
server (we are thinking ejb for the app server).

What I would really, really like, is if we could use the same classes for
both implementations, and just provied additional stuff to deal with the EJB
where it is used.

The problem comes from the fact that when working within an appserver, you
need to create (and find) objects in a certain way, so the implementaion of
many business methods is impacted by the presence of the app server.

I have been trying the factory pattern, and abstracting the business methods
out of the remote interface and the bean implementation into an interfce
they extend and implement seperately. We then have a class that implements
the business methods only (MyClassImpl). Then there is a class that extends
MyClassImpl, and also implements javax.ejb.EntityBean (or session bean)
(MyClassEJBImpl). Now we have a non-EJB and an EJB implementation.

The idea is that whenever we want to create an instance at runtime we
determine whether there is an appserver present, and if there is we create
an instance of (eg) MyClassNormalFactory, otherwise we create an instance of
MyClassEJBFactory. We then call the create method on the factory. The Normal
factory simply returns a new instance of NormalImpl, whereas the EJB factory
does the JNDI lookup to get the Home interface, then calls create on the
home interface.

However, because for EJB we need to always deal with the remote interface,
and for non-ejb we don't want to deal with the remote interface, this makes
the factory difficult to define and however I try to declare the create
method, and cast or cajole the return values, I get type mismatches.

I kind of feel like I'm barking up the wrong tree, but that it's quite a
worth-while venture (only one set of source to maintain).

Also, I suspect that there are other problems in what I'm attempting that I
have not yet encountered.

Has anyone tried to do this before, and if so what was the outcome?

Is there anyone who would like to work collaboratively to see if we can come
up with a solution, so we can make a bit of a pattern out of it?

Thanks

Phil Lewis
Chief Designer
Knowledge Management Software plc

Any opinions expressed in this email are those of the individual and not necessarily 
Knowledge Management Software plc.  This email and any files transmitted with it are 
confidential and solely for the use of the intended recipient.
If you are not the intended recipient or the person responsible for delivering to the 
intended recipient, be advised that you have received this email in error and that any 
use is strictly prohibited.  If you have received this email in error please notify 
the Systems Manager by telephone on 44 (0) 161 227 9009

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to