Prameya,

Thanks for your comments on the book. I have replied inline.

> Let me first congratulate you on the best J2EE book ever written. I am
> getting involved with a J2EE project. I would like to discuss here at very
> high level an architecture that I want to present. I want your expert
> advice and views.
>
> This is distributed application which would use Session Façade for
external
> interface. Session Façade are implemented as stateless session beans and
in
> most cases a Session bean would implement applications use case. However,
> Session beans  themselves do not implement the business logic. They don't
> do work themselves; they delegate to other objects to do the real work.
> Session beans are the client interface to the underlying system. They
> encapsulate the subsystem-specific knowledge and not unnecessarily expose
it.
> Session Façade methods map to Action Objects that implement the business
> logic and interact with Data Access Objects. An Action object represents a
> unique business process that a session bean may invoke. Action objects are
> required to handle business processes that are not related to simply
> creating, reading, updating, or deleting data.  Action Objects would be
> plain java classes and not EJBs and would invoked from the session bean.
> Action objects do the businees logic and also acces data acess objects.
> Data Aceess object would either use entity bean, JDO or even JDBC to
> implement persistence.
>
> Though I have defined it a very high level do you see any problems with
the
> implementation. I am mostly worried about using plain java classes (Action
> Objects) running in the container and invoked from the Session beans. The
> reason for this is that I can use good OO design principles in designing
> the action objects to the correct granularity imposed by the application
> rather than EJB technology. Session beans however manage transactions and
> security. Action objects are not called by anyone except session beans.
> Also, this design would be of help if me move to web services as stateless
> session beans can be exposed as web services and J2EE 1.4 spec supports
it.

The architecture you describe sounds good.  There are a number of advantages
in using plain java classes inside the EJB tier. For example, it should
prove easy to test your business logic, as it probably won't be dependent on
EJB container services.  Your design will enable you to make use of
CMT--assuming that you want all your business objects to be invoked in the
one transaction.  As you know from reading the book, I'm generally wary of
EJBs invoking other EJBs, which involves multiple JNDI lookups, complex
exception handling etc. I think using ordinary classes is a good choice.

How are you creating your business objects in the EJB tier? Are they held in
each EJB instance, or are they created to service each call?

Good luck!

Regards,
Rod