Strict separation of tiers

[David Follow]

Hi folks,

I am planing an architecture with the typical J2EE tier structuring:
client - presentation - business - integration - resource
wherer one tier can only talk to the next tire below.
The integration tier is not CMP but stateless DAOs.

The business tier only talk to the integration tier to retrieve data.
The business tier also doesn't know (or care) where the data comes from
it just goes to the integration tier an asks for it.
The business tier also has a stateful session facade where to keep
user related session information.

For performance reasons I would like to add some type of cache to my system.
And here is where it all starts. Where do I keep the cache?
Like I said, business only asks integration for data, but integration
is stateless and doesn't know about session information.
The only place that is statefull is the business facade in business,
but I don't want to break my rule and retrieve data from integration (DB) and business (cache).

My first idea is to keep a hashmap in integration with e.g. userId as a key
and the cached data as value. However, I am not quit sure if that is
concidered "Best Practice"....

Any good ideas out there on how to solve this issue?

TIA, Detlef

[Parag Doshi]

Originally posted by Detlef Folger:
Hi folks,

I am planing an architecture with the typical J2EE tier structuring:
client - presentation - business - integration - resource
wherer one tier can only talk to the next tire below.
The integration tier is not CMP but stateless DAOs.

The business tier only talk to the integration tier to retrieve data.
The business tier also doesn't know (or care) where the data comes from
it just goes to the integration tier an asks for it.
The business tier also has a stateful session facade where to keep
user related session information.

For performance reasons I would like to add some type of cache to my system.
And here is where it all starts. Where do I keep the cache?
Like I said, business only asks integration for data, but integration
is stateless and doesn't know about session information.
The only place that is statefull is the business facade in business,
but I don't want to break my rule and retrieve data from integration (DB) and business (cache).

My first idea is to keep a hashmap in integration with e.g. userId as a key
and the cached data as value. However, I am not quit sure if that is
concidered "Best Practice"....

Any good ideas out there on how to solve this issue?

TIA, Detlef

you can have a Cache component in your business tier and when someone requests data, you could query the Cache, if the data is not present, retrieve it from your DAO, store it in Cache and return the response back to the client (whoever it might be). That way, your Cache is separate from your session facade and DAO and with proper abstraction you can also have a pluggable Caching solution. If you want to go an extra step, you can have a CacheService, which could be a stateless session bean and it would be responsible for storing and retrieveing data from Cache. Or you can have a CacheManager which would manage the cache and provide services like removing stale cache entries, refreshing cache, storing, retrieving data etc..
The basic idea is to think about your Cache as a separate component apart from your session facade and DAO.

HTH
Parag

[Annie Zhang]

Just want to confirm if this CacheManager should be singleton, which could be shared by all the clients.

[Parag Doshi]

Originally posted by Annie Zhang:
Just want to confirm if this CacheManager should be singleton, which could be shared by all the clients.

Normally, they are as Cache componentss provide common services to all clients.

[Dhiren Joshi]

Parag ,
In the caching mehanism ,how would the cache manager know when to refresh. Some sort of observer observable type of implementation is needed or what ?
Too much of an over kill to call cache everytime when using the EJB's.
Or are u suggesting to integrate the caching and synch it with the EJB's.

What if the DB is updated like from a fast lane reader or a DAO other then the EJB's ? How would the cache manager synch with that ?

Thanks
Dhiren

[Parag Doshi]

Originally posted by Dhiren Joshi:
Parag ,
In the caching mehanism ,how would the cache manager know when to refresh. Some sort of observer observable type of implementation is needed or what ?
Too much of an over kill to call cache everytime when using the EJB's.
Or are u suggesting to integrate the caching and synch it with the EJB's.

What if the DB is updated like from a fast lane reader or a DAO other then the EJB's ? How would the cache manager synch with that ?

Thanks
Dhiren

Dhiren,
All the points you make are valid and those are the considerations you have to take during the implementation of Cache component. There are quite a few readily available caching solutions which can be plugged into the system..the main point to make is that the caching piece can be independent of your business objects and you can either write your own refresh/load algorithms or provide callbacks in your objects to notify the cache manager of changes. The options are endless and easily configurable.

Just to answer your questions, there are many ways a cache manager can update its cache, it can use TTL algorithms, LRU algorithms, it can have callbacks for such events etc. Anytime a update/delete occurs, the cache manager can be notified and it can start the process of updating its caches with the changes (possibly in some background thread)..Like I said, there are endless implementations strategies..thankfully for this assignment, we dont have to draw out each implementation strategy..just having a cache component in the right place should be enough and you just need to indicate the responsibility it undertakes rather than showing how it actually implements it.



Parag

[Dhiren Joshi]

Thanks Parag,
Thats a whole lot of good information on caching u gave. I wasnt going into all these nitty gritty details in the assignment but it helps to know them all the same. I wasnt so well versed about caching algos and mechanisms.
Thanks
Dhiren

[Annie Zhang]

I just thought of another question regarding the implementation of the CacheManager. If it is implemented as a session bean, should it use fast lane reader and value list handler to maximize the performance, instead of using DAO directly? (That is what I read from some post). However, fast lane reader is normally called from jsps instead of from EJBs. How could the CacheManager session bean use the fast lane reader?

Thanks,
Annie

[Dhiren Joshi]

Annie,

I just thought of another question regarding the implementation of the CacheManager. If it is implemented as a session bean, should it use fast lane reader and value list handler to maximize the performance, instead of using DAO directly? (That is what I read from some post). However, fast lane reader is normally called from jsps instead of from EJBs. How could the CacheManager session bean use the fast lane reader?

If Any EJB is used then it is not considered a fast lane reader though I would accept that if DB is not handled by EJB that would be a fast lane reader but a fast lane reader pattern is without EJB references.
DAO is always used with Fast lane reader and a value list handler for performance. I guess I dont quite get your point about a fast lane reader and EJB being integrated into one.
They are two different pattern implementations so fast lane reader would not have any EJB's.
Some one please correct me if I misunderstood this..

Thanks
Dhiren

[Parag Doshi]

Originally posted by Annie Zhang:
I just thought of another question regarding the implementation of the CacheManager. If it is implemented as a session bean, should it use fast lane reader and value list handler to maximize the performance, instead of using DAO directly? (That is what I read from some post). However, fast lane reader is normally called from jsps instead of from EJBs. How could the CacheManager session bean use the fast lane reader?

Thanks,
Annie

Annie,
I am not sure if I understand the question properly, but, from what I understand, a CacheManager manages caches of objects. It doesnt care where the data comes from, who creates them or what processing is done on them. It just manages the lifecycle of the cached object and has nothing to do with retrieval of the data.
You can use whatever mechanism is best for retrieving data depending on the requirements. With respect to FastLaneReader, its basically is for bypassing the EJB layer and directly accessing the DAO via a business delegate or some web tier component (though I have heard of stateless session bean based FLRs too).

Parag
[ October 14, 2004: Message edited by: Parag Doshi ]

[Annie Zhang]

I also heard of stateless session bean based FLRs. That confuses me.

Is this fair to say like this? (CacheManager is just a plain class)

Jsp--Servlet--CacheManager--ValueListHandler--FastLaneReader--DAO--DB
| | |<<manages>>
| | |
|------------ Cached objects

[Dhiren Joshi]

I found a link on serverside.com
serverSide Link

The solution in the EJB specifications is to recommend modelling of only those tables as Entity Beans which are not to be accessed directly by other sources as this directly has bearing on distributed caching by container. So a third party caching doesn't seems to help anyway here. (Use SB+DAO for fast lane reader there).

Mentions SB --> DAO(fast lane reader)

This makes me rethink the definition of fast lane reader as I understand it now.

Fast lane reader byPasses EJB from an Entity stand point becuase Entity bean querying DB would be slow whereas if the same task is done by implementation of fast lane reader using the DAO it would be faster.
Entry point from SB is acceptable as long as SB did not call an entity bean in the entire business flow.

I am kind of confused but this is the best I could find ..

Any suggestions..
Thanks
Dhiren

[Parag Doshi]

Originally posted by Annie Zhang:
I also heard of stateless session bean based FLRs. That confuses me.

Is this fair to say like this? (CacheManager is just a plain class)

Jsp--Servlet--CacheManager--ValueListHandler--FastLaneReader--DAO--DB
| | |<<manages>>
| | |
|------------ Cached objects

Annie,
It would be more like this:

JSP --Servlet--ActionClasses---BD---SF---VLH-----DAO-------DB

where:

        uses                manages
VLH -----> CacheManager --------->Cache

where
BD = BusinessDelegate (if you have implemented one)
SF = Session Facade
VLH = ValueListHandler. This is the first half of the fastlanereader This uses the cachemanager to cache the results.
CacheManager = manages caches of objects.
DAO = This is other half of the fastlanereader

The idea is that the web tier should never know that the data caching strategies of the business tier. The VLH decides what data to cache and what subset to return to the client. So the VLH uses the services of a CacheManager to store the results in a cache. The CacheManager provides centralised services to all components in the business tier for their caching needs.
The DAO is mainly concerned with data retrieval strategies and has nothing to do with the caches.
The ValueListHandler and the DAO both combined provide the services of fastlanereader. There are strategies which suggest that the VLH could be implemented as a session bean (hence the SB-DAO FLR strategy), but my personal opinion is that the VLH provides more general services than for a particular user. So, making it a session bean doesnt seem logical (atleast to me). I see the VLH as providing fast search/caching/sub-lists/iteration functionality to different components and not necessarily limited to holding state for a particular user.

HTH
Parag
[ October 15, 2004: Message edited by: Parag Doshi ]

[Annie Zhang]

Your explaination definitely helps clarify some of my confusion. Then I revisited the Blueprints. I got what you mean.

Thanks a lot!
Annie