2 types of clients access the same BD?

[Harry Tan]

supposed I design components to allow 2 types of clients (Web and Swing) accessing EJB Tier.
The design as follow:

WebClient -> Controller ---\
---BD(business delegate) ->SF(SFSB) -> EntityBean(CMP)
SwingClient -> Controller --/


Each clienttype has its own controller to send the request to the BD.

assume this SCENEARIO WITH WEBCLIENT:
A client retrieve a list of flights via SF.
The flights are stored in the SF(for whatever purpose at later stage) while the BD stores the reference of SF.
This client can access to the 'retrieved flights' on subsequent requests on EJBTier (which is stored in SF) because the BD holds the reference of SF.
In this design, each client has an instance of BD and this BD instance is stored in httpsession.


But the problem arises whenever the same BD is used by Swing Client.(Agent).
The SWINGCLIENT SCENARIO:
An agent needs to serve multiple customers but the application only uses ONE instance of BD.
So whenever I use the same implementation of (BD - SF) I face with the problem of state management:
A data retrieved for a particular customer which is available(stored) in SF would not be useful for other clients.

So my questions will be:
1. Shall I use the same BD for Web and Swing client?
2. Where is the best to store the state? in EJBTier or Client Tier? The best for reducing network traffic would be EJBTier.


If I make the SF to be SLSB, I would solve this problem but the data would be manipulated in clienttier.
But whenever I insist to have SF as SFSB to reduce the traffic of transferring huge objects data, what would be the best solution?


Any suggestion on the component design?

[Harry Tan]

formatting error with the design.

it should be:

Web/SwingClient->Web/SwingController => BD(business delegate) ->SF(SFSB) -> EntityBean(CMP)

[Harry Tan]

let me rephrase my concern which related to 'access violation':


My issue is the session handling in EJBTier and Security violation
whenever I use the same interface for web and swing client.
Let me bring you into details:
Assume both clients have following design structure:
Client -> BD(POJO) -> UserSessionEJB(SFSB) -> Facade -> EntityBeans


the problems happen while the clients perform listItinerary() operation:
Assumed I provide this interface "BD.listItinerary(customerId)"

This is a perfect interface provided for Swing(travel agent)
application as any travel agent would be able to list any customer's itinerary by providing his customerId.
But this interface opens up a security issue for 'Webcustomer'
because any hackers could manipulate by passing a different 'customerId' from the logged-on customer.

To prevent the security violation, a method without passing
customerId shall be provided because the CustomerId can be retrieved
from UserSession.

So the best method for both application might not be the same:
Web -> BD.listItinerary()
Swing -> BD.listItinerary(customerId)

But since we are providing the same interface, how are we solving
this problem?

[Albert Maurucier]

Where does the BD reside ?
From: Core J2EE patterns(By Deepak Alur, John Crupi, Dan Malks):
"The Business Delegate pattern is categorized as a business-tier pattern and not a presentation-tier pattern because the Business Delegate is a logical abstraction, not a physical one. When used with a presentation tier, the actual Business Delegate components live in the presentation tier. However, they are a logical extension of the business tier. Because of this, and because of the pattern's close association with business components such as Session Fa�ade (341), we recommend that business service developers implement Business Delegates."
The Bd is alogical extension of the Business tier in the presentation tier, so, each client type should have its own BD.
Regards
Albert

[Harry Tan]

When used with a presentation tier, the actual Business Delegate components live in the presentation tier.

my BD is a POJO and used with presentation tier. So it automatically resides in presentation tier.

I just like to point out that it is not a good solution to have the same interface for customer and travel agent as they're having different roles. The reason is the security violation that could happen.


An example is the case with "BD.listItinerary(customerId)".
*)Whenever this method is invoked by travelagent to lookup for list of customer's itinerary, it is absolutely fine as the TA has the right to do so.
*)But whenever this method is invoked by a customer(after he logged on), he might be retrieving information from other users.

The solution I could think of:
1)provide different BD interface for each role.
-customer role accesses: BD.listItinerary()
-travel agent role accesses: BD.listItineary(customerId)

2)Or perform programmatical security check for each method if we supply the same interface:
-customer gives wrong customerId during BD.listItinerary(customerId) will raise security exception.

Or is my logic wrong from the beginning?

[Dhiren Joshi]

An example is the case with "BD.listItinerary(customerId)".
*)Whenever this method is invoked by travelagent to lookup for list of customer's itinerary, it is absolutely fine as the TA has the right to do so.
*)But whenever this method is invoked by a customer(after he logged on), he might be retrieving information from other users.

The solution I could think of:
1)provide different BD interface for each role.
-customer role accesses: BD.listItinerary()
-travel agent role accesses: BD.listItineary(customerId)

2)Or perform programmatical security check for each method if we supply the same interface:
-customer gives wrong customerId during BD.listItinerary(customerId) will raise security exception.

The business delegate for the travel agent is at the swing app client end.
The busines delegate wil be different for the two, the web customer and client.

The web customer generally uses local EJB's and web delegate. I use the EJB controller and EJBAction 's and so the web doesnt really even had the need for a BD except where access is directly required from a JSP.
Looking at it this way, defining different BD is the way I went with. Well I dont have a BD for the web tier my framework for the web tier is similar to the pet store and using action command strategy I didnt find the necessity of web client BD except in search functionality.

HTH
Dhiren

[Harry Tan]

Looking at it this way, defining different BD is the way I went with

having different problem definitely solve this issue.
But I've found out that many ranchers are using the same interface. So I was wondering how they protect access violation issue as I described with the listItinerary(customerId) method.

[Joseph Zhou]

We have two set of methods anyway, one for customers and another for agents. could set role based security at SFSB side to make each type of client can only call it's own set of methods?

[Rashmi Razdan]

Yes i agree with joseph, role based security (specified on demand) shud solve ur problem.