• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

EJB based Architectural problem ! pls help with suggestions

 
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

We have a J2EE based product that has had several production deployments.

I will describe our architecture to give you an idea to provide suggestions :


|------| |------|
|tomcat| - |JBoss |
| JVM | | JVM |
|------| |------|
| |
|----------| |-------------|
| Session | | Application |
| Database | | Database |
|----------| |-------------|



* Tomcat JVM deployed a MVC web application, that
- creates a Session, when a user is authenticated, and persisted in a separate session database

- A typical session object has the user authentication details,
a.) logged on user,
b.) assigned role,
c.) company name etc.,

* JBoss serves all remote functional services, used by the tomcat WEB container, via EJB Stateless session services
- Each EJB Stateless service calls several methods and functional services across application tiers
such as

calls calls calls
Stateless Session Bean A => Class A => Class B => DAO => JDBC calls to the DB


PROBLEM :

Given this scenario, the problem that i am facing is.

1.) How do i pass, and have access, the session object credential information from Tomcat to EJB container, with out having to pass as a parameter. Because there are hundreds of services that needs to get the signature change, if done the brute force way.

2.) Let's say, we could get the session object credential to the EJB bean in step 1.
How do i pass that information all the way through the method calls, from all the application tiers all the way through EJB to the DAO layer.


I know some people might suggest using Thread Local variable functionality for the problem 2. But it is not advised or j2ee compliant to use threads and thread local objects in EJB container because the results are not predictable and not guaranteed to work in different J2EE application servers.

Appreciate all the help and suggestions
 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by steve mcdonald:

1.) How do i pass, and have access, the session object credential information from Tomcat to EJB container, with out having to pass as a parameter. Because there are hundreds of services that needs to get the signature change, if done the brute force way.

2.) Let's say, we could get the session object credential to the EJB bean in step 1.
How do i pass that information all the way through the method calls, from all the application tiers all the way through EJB to the DAO layer.



Is there one common [or at least a few common] parameter[s] passed to nearly each method?
Could you let those parameters _extend_ that info so they carry that additional info by inheritance?

Or form a (or a few) new parameter carrying the old object _and_ the additional credential info within one new _compound_ object?

After that you could Eclipse > Refactor > Rename to globally rename the old parameters to the new (compound) parameters - an uggly solution for an uggly but just technical problem, but we did decide to do so in a former project.

And / or provide some session-owned object groups with an additional constructor parameter to a [newly inherited?] super class? But only for session-owned ones - maybe dangerous...

What do the Single Sign On specialists say?

Still hoping someone has a better idea...
Thomas
[ March 23, 2006: Message edited by: Thomas Taeger ]
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can rely on the propagation of client role( not the client id ) between the containers -and you have to some how device a way to populate the rest of the user specific data from the role. This may be a problem if there are multiple users with the same role, which is usually the case. In most scenarios I have dealt with, it was sufficient to configure EJB methods to run as specific roles, and let the Web container handle the authentication and assign the role to the callers' context.

How about externalizing your Session database out of the Tomcat JVM? I have seen architectures that use an external database to store and track user activities from log-on to log-off cycle. Since you already have a session database design, it may not be a huge change to pull it out. This design would stillr require you to pass an unique ID across to all method calls, but it will enable you to keep the maintenance cost to the minimum.

You may also want to investigate some Dependency Injection strategy to automatically provision the user informatoin to all interested parties.
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just a note on use of ThreadLocal - since each JVM maintains its own pool of threads, a solution based on ThreadLocal will not work across different containers. If both your web and EJB containers are from the same vendor, you may rely on some proprietary but nonportable solution.
[ March 22, 2006: Message edited by: Ajith Kallambella ]
 
steve mcdonald
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks ya all for the replies.

Well, several users can have/share the same role so that wouldn't work

what is this "Dependency Injection strategy", where can i get more details.

using ThreadLocal and anything to do with threads is not an option.

It is too Bad in EJB architecture, that they wouldn't expose Transaction Context of some sort, where every service call is a transaction and any credentials that need propagation could be saved into the context and that context could be looked up at any application layer to get access.

Some times i believe Microsoft arch has some neat nifty things to solve such problems easily.

The whole point was that, Our application architecture was designed to be a standalone customer installation. Now we are trying to make it a hosted environment, where the same J2EE application, based on the supplied user credentials will work with different customer JDBC connection pools and security etc.,.
 
steve mcdonald
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What i read about the dependency injection strategy was that
the classes are container managed and the helper or any other classes underneath the covers cannot be benefitted. This will not help me in propagating the extra data through the composed classes.

May be i need to read more about it and see if i could use some interceptor or some sort
[ March 22, 2006: Message edited by: steve mcdonald ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic