Caching SFSB handle

[Durgaprasad Guduguntla]

IMO as the FBN application uses the same business tier for web client and swing client, it would be an appropriate choice to cache client state in the business tier as there is no HttpSession available for swing client. If I use stateful session bean for this purpose, I need to pass stateful session bean reference for every subsequent business method call from the client. That means I need to pass the SF handle from the presentation tier to business tier to call the business method and also return back the handle from business tier, for caching it in the presentation tier. In the Core Design Patterns book, I see the Service Locator pattern returning a string representation of EJBObject in the method getId() after writing the object using IO stream and the method getService(id) reads bymeans of IO for returning EJBObject reference. I am thinking of caching IdString in the HttpSession for the web client and in local memory for the thick client. Is it the correct approach? But I suspect on top on stateful EJB, there is an additional overhead of writing and reading objects using IO streams which involves resource consumption and impacts performance. Is there any good pattern that solves this problem? Can someone share thoughts on this?

[Dan Drillich]

Durgaprasad,

The Context Object is a good solution for this case. As the Core J2EE Patterns book says:

Context Object is a generic object used to share domain-neutral state throughout an application.

Regards,
Dan

[David Follow]

Hi,

I don't understand why you need to get that ID and pass the reference to your SFSB in every subsequent call? Why don't you just store the business delegate (which hides your remote interface to your SFSB) in the httpSession in case of the web client and in local memory in case of the application client?

D.
[ November 10, 2006: Message edited by: David Follow ]

[David Follow]

Originally posted by Dan Drillich:

The Context Object is a good solution for this case. As the Core J2EE Patterns book says.

Dan,

what do you mean with "Context Object"? Do you mean the InitialContext object? Can you please explain some more?

D.

[Durgaprasad Guduguntla]

Originally posted by David Follow:
Hi,

I don't understand why you need to get that ID and pass the reference to your SFSB in every subsequent call? Why don't you just store the business delegate (which hides your remote interface to your SFSB) in the httpSession in case of the web client and in local memory in case of the application client?

David,

Caching BD seems to be a good idea if you are using SFSB as the entry point for your business tier. But if you have BD -->SLSB Facade --> SFSB design, you may need to pass the ID to reconnect to the same SFSB instance. I believe that SLSB facade scales well for workflow invocation which can create SFSB on demand and store the client specific conversational state in SFSB. Further I am not sure whether EJBObject is serializable if you want to store BD in HttpSession. Here I see some other problems:

- Assume somehow EJB Object is cached in client side and the container times out SFSB and in that instant the client attempts to access the bean. Which mechanism would ensure that the client invokes the method on live bean?

- If the client terminates the session, we should be able to terminate its SFSB instance as well by calling remove() method on SFSB to save server resources. How can we do this?

Can someone clarifies on the above points?
[ November 10, 2006: Message edited by: Durgaprasad Guduguntla ]

[Dan Drillich]

So, we assume that we have at least one stateful bean in the solution, otherwise there is nothing to speak about. Right?

The handle has to reach the first stateful bean in the business tier. If there are more stateful beans in the business tier, then the front one should have their handles.

So, the Context Object might be the solution, or we can simply propagate the single handle from the presentation tier to the business tier and vice versa when we create the front stateful bean.

How does it sound?

Regards,
Dan

[David Follow]

Durgaprasad, Dan,

I was breaking my head about this SLSB/SFSB thing for quiet some time. After all, I decided, that my entry point to the business tier will be stateful because if you look carefully at the use cases, I believe that all of them have to maintain some state information on the business tier.
Creating and changing an itinerary requires to hold some information (such as flights) the customer has selected. At one point in time the customer decides to actually buy an itinerary and puts it in some kind of shopping cart. If he orders an itinerary it is once again stateful.
So I believe all the use cases involved keep state in the business tier, therefore I decided to have a SFSB as the main entry point to the business tier.
My BD holds the reference to the SFSB and can be kept in the httpSession and in the application clients local memory.
Durgaprasad, to answer your question, the remote reference is not serializable (in case of passivation) therefore you will need to passivate its handle and reconstruct the actual remote interface on activation.

Does all this above make sense?

D.

[Dan Drillich]

David,

What you are saying makes perfect sense.

Regards,
Dan

[David Follow]

Dan,

I think having a SFSB business tier controller makes enough sense to me to architect it in such a way. What do you think of this approach?

[Durgaprasad Guduguntla]

The requirements emphasize many times on scalability and warranted growing user base for the application. Remember the users need not require to login to prepare the itineraries, they can do it anonymously. In most of the cases user do search for flights, check the availability and are not likely to confirm itinerary. In view of this, SFSB facade would be a costly operation as it will create SFSB instances for every user session.

The search for flights is a stateless operation. For the subsequent steps, you can initiate a DTO which passes the user selections to business tier from presentation tier. In the multi-step process of itinerary preparation, this DTO is passed back and forth between presentation and business tiers and got populated fully. Once the user intend to confirm itinerary, you create SFSB and move itinerary state to the SFSB and make it available for change itinerary and pay for itinerary use cases. That way we can limit SFSB usage and make the application more scalable. How does it sound?

[Dan Drillich]

David,

Sure, however, what is this 'SFSB business tier controller'? I think it can be either the business delegate or the session facade. I, personally, prefer the latter.

Regards,
Dan

[Andrew Zilahi]

David,
I like the idea of caching the BD in session scope, but wouldn't storing ServiceLocator instead be better? Please advise.

thanks,
Andrew

[David Follow]

Durgaprasad, Dan,

I would prefer a SessionFacade to be the SFSB and also single point of entry to the business tier. Different BDs could however talk to the same SFSB. Therefore for the clients the complexity as in number of methods could be spread across several BDs.

Durgaprasad, I also think and expect that a E10000 easily can handle a couple thousand of parallel user sessions. If not, than Suns top server (at least back then) would be pretty sad.
You can always make a nice an juicy assumptions on the number of system boards the E10k has

What do you think?

D.

[David Follow]

Originally posted by Andrew Zilahi:
David,
I like the idea of caching the BD in session scope, but wouldn't storing ServiceLocator instead be better? Please advise.

thanks,
Andrew

Andrew, in my approach the SL is something very independent of the system. In fact, my SL could be used in any project.
The BD is the one that hold the reference or handle to the SFSB.

D.

[Durgaprasad Guduguntla]

Originally posted by David Follow:
I would prefer a SessionFacade to be the SFSB and also single point of entry to the business tier.

What do you think?

D.

David,
I agree SFSB would be a nice choice as the server is capable of handling multiple sessions in EJB tier and in view of both types of clients. I am also leaning towards SFSB facade after reading thourgh the Blue Prints recommendationand pet store example.

If you cache the SFSB handle in HttpSession, you may want to clean up the session on EJB tier. This can be done using HttpSessionListener which listens to the session termination event on the web tier and call remove() on SFSB. The same thing can be implemented for swing client upon log-off event.
[ November 16, 2006: Message edited by: Durgaprasad Guduguntla ]

[David Follow]

Originally posted by Durgaprasad Guduguntla:
If you cache the SFSB handle in HttpSession, you may want to clean up the session on EJB tier. This can be done using HttpSessionBindingListener which listens to the session termination event on the web tier and call remove() on SFSB. The same thing can be implemented for swing client upon log-off event.

Hi,

good point. I will add it to my supporting document.

D.

[Andrew Zilahi]

David,
I ended up myself having ItineraryProcessor SFSB as being the Session Facade. I have SLSB/MDB for credit card processing, etc, but all communication with EJB occurs via the SFSB. I am still debating if I did the right choice.
BTW, why do you need to clean up the session on EJB tier??

thanks,
Andrew

[David Follow]

Originally posted by Andrew Zilahi:
BTW, why do you need to clean up the session on EJB tier??

The session may time out by itself, but it is always a better choice to call remove() on the session. Depending to what your timeout is set, the SFSB may still be active long after use user has gone or logged out.

D.

[Durgaprasad Guduguntla]

David,
Do we need separate BDs for web client and swing client if BD is cached. Can't we manage with same BD?

[Andrew Zilahi]

Thanks David -- you would want to clean up for better resource management. I guess it's a good point worth mentioning in your documentation.

Durgaprasad, DB should be specific to the client. One reason I can think of is client side caching.

Andrew

[Marta De rossi]

Hi all !
I would like to join the discussion since I have taken a different approach.
I started with a SFSB facede for keeping Session information, then I decided to change it.

In fact I don't like very much to use both a Stateful SB and HTTPSession to store the handle(of SFSB). It seems more complicated and error-prone to keep up with both this session information.

Now I re-engineered it with just SLSB. I have inserted the ShoppingCart object in the HTTPSession for web clients and just kept it in memory for plain Java Clients.

I think it could make also the application more scalable.
I hope that my approach will not be a failure when I deliver my assignment


What do you say ?
Thanks
Marta

[Brian Smith]

Hello Guys,
This is very interesting dicussion topic and also this area is where I am struggling at. Thanks for initiating this topic.

Originally posted by Marta De rossi:
Hi all !
In fact I don't like very much to use both a Stateful SB and HTTPSession to store the handle(of SFSB). It seems more complicated and error-prone to keep up with both this session information.

Now I re-engineered it with just SLSB. I have inserted the ShoppingCart object in the HTTPSession for web clients and just kept it in memory for plain Java Clients.

I think it could make also the application more scalable.
I hope that my approach will not be a failure when I deliver my assignment


What do you say ?
Thanks
Marta

As far as whether it's gonna work, it absolutely works. However, is this an ideal approach, I am not sure as the sun blue prints, its advisable to store the session in the EJB tier if the EJB tier is presence in the design in such a way that you don't have to maintain it in two places separately for Web Client and Java Client. Also, Is it scalable? I don't know - please how do you think it would be a scalable approach.

If I understood correctly, this dicussion seems to have suggested that it's a good idea to store the session centrally in a Business Delegate what would work both for Web Client and Java Client - leads manageability definitely. But I stil don't know how its gonna be implemented though. Do we store the Session Facade (SFSB) in some sort of collection in the Business Delegate? How do we design the Business Delegate? as a SLSB? How does clients access this BD? through Service Locator? How does the individual client keep its handle to the Session Facade? Please help understand this.

Thanks.
BR

[Andrew Zilahi]

Originally posted by Marta De rossi:
Hi all !
I would like to join the discussion since I have taken a different approach.
I started with a SFSB facede for keeping Session information, then I decided to change it.

In fact I don't like very much to use both a Stateful SB and HTTPSession to store the handle(of SFSB). It seems more complicated and error-prone to keep up with both this session information.

Now I re-engineered it with just SLSB. I have inserted the ShoppingCart object in the HTTPSession for web clients and just kept it in memory for plain Java Clients.

I think it could make also the application more scalable.
I hope that my approach will not be a failure when I deliver my assignment


What do you say ?
Thanks
Marta

Have you also considered the volume of data stored in http session and also being passed back and forth between tiers when you store the whole shopping cart instead of just a reference to sfsb?

[Andrew Zilahi]

Originally posted by Brian Smith:
Hello Guys,
This is very interesting dicussion topic and also this area is where I am struggling at. Thanks for initiating this topic.



As far as whether it's gonna work, it absolutely works. However, is this an ideal approach, I am not sure as the sun blue prints, its advisable to store the session in the EJB tier if the EJB tier is presence in the design in such a way that you don't have to maintain it in two places separately for Web Client and Java Client. Also, Is it scalable? I don't know - please how do you think it would be a scalable approach.

If I understood correctly, this dicussion seems to have suggested that it's a good idea to store the session centrally in a Business Delegate what would work both for Web Client and Java Client - leads manageability definitely. But I stil don't know how its gonna be implemented though. Do we store the Session Facade (SFSB) in some sort of collection in the Business Delegate? How do we design the Business Delegate? as a SLSB? How does clients access this BD? through Service Locator? How does the individual client keep its handle to the Session Facade? Please help understand this.

Thanks.
BR

BD is a POJO on the client/web tier, not a SLSB.

[Brian Smith]

Andrew,

Originally posted by Andrew Zilahi:


BD is a POJO on the client/web tier, not a SLSB.

Yes according to this CoreJ2EE Patterns, it is a POJO. It also says that BD belongs to Business Tier which will be instantiated by FrontController or Application Client controller to access Service Locator to access session facade to get the business logic execute. Please let me know If I am wrong.

Thanks,
BR

[Andrew Zilahi]

You are correct -- In your last posting you mentioned this "How do we design the Business Delegate? as a SLSB?", hence I brought this up

[Marta De rossi]

Hello,

Originally posted by Brian Smith:
Also, Is it scalable? I don't know - please how do you think it would be a scalable approach.

well in my opinion it should be a scalable solution because I don't need to create a SFSB for every client but I just use some SLSB to serve all the request.

On the other hand, as reported on this thread, I agree that passing session information across tiers could be a poor design choice.
I'll take a look at this forum is somebody passed using just SLSB.....
Thanks
Marta

[Steve Taiwan]

I like Marta De rossi's idea.

The architecture of my last project is VB --> JCOM --SLSB. There is no way to store seesion or system information in such architecture
so we used Context Object to store the necessary information and passed it backware and forward in many tiers. No performance issue about Context Object. We pretty much like this design. I believe SFSB is too heavey and is not easy for programmers to implement. Most time SFSB shall be my last last last one choice.

I am constnatly, periodically reading threads here and do hope someone can porpose a better solution for this issue. I think, if no other solution for this issue, I am gonna use Context Object with SLSB because I have proved it worked well. I also believe Sun gives you an oppertunity to explain your design in the attached document.
[ November 21, 2006: Message edited by: Steve Taiwan ]

[Andrew Zilahi]

Originally posted by Steve Taiwan:
I like Marta De rossi's idea.

The architecture of my last project is VB --> JCOM --SLSB. There is no way to store seesion or system information in such architecture
so we used Context Object to store the necessary information and passed it backware and forward in many tiers. No performance issue about Context Object. We pretty much like this design. I believe SFSB is too heavey and is not easy for programmers to implement. Most time SFSB shall be my last last last one choice.

I am constnatly, periodically reading threads here and do hope someone can porpose a better solution for this issue. I think, if no other solution for this issue, I am gonna use Context Object with SLSB because I have proved it worked well. I also believe Sun gives you an oppertunity to explain your design in the attached document.

[ November 21, 2006: Message edited by: Steve Taiwan ]

Yeah, also think about the fact that you might also have to cache potential results when user refines search for less expensive flights within the hour, unless you decide to hit the DB each time this happens, right? You would have to carry back and forth all that information...

Andrew

[Steve Taiwan]

Dear Andrew.

Yes, I designed to do the second query based on the first query. I think this is much efficient.

If there are 10 itineraries from the frsit query and then user selects one, I only have to do the second query once based on the selected itinerary.If I don't do this, I might have 10*10 query in the first query and have to caache them in the Context Object, which is so fat.

I think i won't put a lot of imformation in Context Object and I don't plan to make Context Object a shopping cart. Airline seat booking is different from buying books in Amazon. So I don't make a shooping cart in the design. At the current stage, I have no plan to implement ValueListHandler

What do you think??
[ November 22, 2006: Message edited by: Steve Taiwan ]

[Brian Smith]

Hello Steve,

Originally posted by Steve Taiwan:
Dear Andrew.

Yes, I designed to do the second query based on the first query. I think this is much efficient.

If there are 10 itineraries from the frsit query and then user selects one, I only have to do the second query once based on the selected itinerary.If I don't do this, I might have 10*10 query in the first query and have to caache them in the Context Object, which is so fat.

I think i won't put a lot of imformation in Context Object and I don't plan to make Context Object a shopping cart. Airline seat booking is different from buying books in Amazon. So I don't make a shooping cart in the design. At the current stage, I have no plan to implement ValueListHandler

What do you think??

[ November 22, 2006: Message edited by: Steve Taiwan ]

I agree with you on the Shopping Cart concept. Its not like other online retailer like Amazon.com, ebay.com etc where you would go and add product on the shopping cart. I am not desiging a shopping cart concept too. However, as far as the Context object vs ValueListHandeler for caching search results, I would prefer ValueListHandler because it lives in EJB tier and thus caching the search results in it would be accessible for all the clients. The Context Object lives in presentation tier plus its design is not intended for caching stuffs particularly the search results.

Also, Guys, FlyByNight already has one Application Server and 2 Web servers, is the intention to separately deploy the EJB plus business objects in Application server and the web tier (Servlets, JSPs, HTML and other stuffs) in those 2-web servers?

Thanks,
BR
[ November 22, 2006: Message edited by: Brian Smith ]

[Steve Taiwan]

Dear Brian

Regarding one Application Server and 2 Web servers, I think what you talked about be right (because I am not from SUN and I don't pass it yet). But in my java work experience, I never did this before. Is it possible that you buy a lot of weblogic licenses only to separate web and application servers in the real world?

[Dan Drillich]

Hi Brian,

Also, Guys, FlyByNight already has one Application Server and 2 Web servers, is the intention to separately deploy the EJB plus business objects in Application server and the web tier (Servlets, JSPs, HTML and other stuffs) in those 2-web servers?

We recently had a discussion about this topic at https://coderanch.com/t/155244/java-Architect-SCEA/certification/sun-as-webcontainer

I believe the wikipedia definition is right; it says:

The term Web server can mean one of two things:
1. A computer that is responsible for accepting HTTP requests from clients, which are known as Web browsers, and serving them HTTP responses along with optional data contents, which usually are Web pages such as HTML documents and linked objects (images, etc.).
2. A computer program that provides the functionality described in the first sense of the term.

What do you think?

Regards,
Dan

[Andrew Zilahi]

Originally posted by Steve Taiwan:
Dear Andrew.

Yes, I designed to do the second query based on the first query. I think this is much efficient.

If there are 10 itineraries from the frsit query and then user selects one, I only have to do the second query once based on the selected itinerary.If I don't do this, I might have 10*10 query in the first query and have to caache them in the Context Object, which is so fat.

I think i won't put a lot of imformation in Context Object and I don't plan to make Context Object a shopping cart. Airline seat booking is different from buying books in Amazon. So I don't make a shooping cart in the design. At the current stage, I have no plan to implement ValueListHandler

What do you think??

[ November 22, 2006: Message edited by: Steve Taiwan ]

Steve,
Can you please clarify what you mean by "If there are 10 itineraries..."? I was talking about caching flights for 1 itinerary only, plus alternative cheaper ones within the hour. I feel that 100 is exagerated (at most 10 in my assumptions).

rgds,
Andrew

[Brian Smith]

Hello Dan,

Originally posted by Dan Drillich:
Hi Brian,



What do you think?

Regards,
Dan

Yes, that's what the web server is meant - serving http requests. Web Server mostly,at least in java world, is like Apache where all the static stuffs like html, images and other css are deployed. Anything to do with dynamic request are routed to Application server where Servlet, JSP, EJB and other business objects are deployed to support business logics. I think the hardwares mentioned in the conversation with CIO can be utilized just this way.
What do you think?
BR

[Durgaprasad Guduguntla]

If we assume that the web container and EJB container are colocated within the same Application server, we can use local interface for the web application and remote interface for the swing client, for accessing the facade to businnes tier. That way we can confine RMI communication to swing client only and on the other hand as the web client uses local communication, there will be a significant improvement in performance. What do you think?

[Brian Smith]

Hi Durgaparasad,

Originally posted by Durgaprasad Guduguntla:
If we assume that the web container and EJB container are colocated within the same Application server, we can use local interface for the web application and remote interface for the swing client, for accessing the facade to businnes tier. That way we can confine RMI communication to swing client only and on the other hand as the web client uses local communication, there will be a significant improvement in performance. What do you think?

That's what I am considering doing. I am wondering if we can know whether web clients performs better over the swing client or vice-versa. One the requirements is to provide FBN reps faster performing client to support their customers over the phone. Please let me know what you guys think.

BR

[Dan Drillich]

If we assume that the web container and EJB container are colocated within the same Application server, we can use local interface for the web application and remote interface for the swing client, for accessing the facade to businnes tier. That way we can confine RMI communication to swing client only and on the other hand as the web client uses local communication, there will be a significant improvement in performance. What do you think?

Durgaprasad, by doing so, local communications within the app server, will be great, but I'm afraid that we don't utilize the three available servers in the best possible way.

Anything to do with dynamic request are routed to Application server where Servlet, JSP, EJB and other business objects are deployed to support business logics. I think the hardwares mentioned in the conversation with CIO can be utilized just this way.

Brian, the requirements speak about one app server and two webservers. We can say that's plain wrong, assume something or overrule the FBN CIO comment. :roll:

Regards,
Dan

[Durgaprasad Guduguntla]

Originally posted by Brian Smith:
That's what I am considering doing. I am wondering if we can know whether web clients performs better over the swing client or vice-versa. One the requirements is to provide FBN reps faster performing client to support their customers over the phone. Please let me know what you guys think.

Brian,

AFAIK the performance of swing client also depends largely upon the capacity of the client machine on which the swing app is hosted. We can assume that FBN provides its travel agents with high capacity machines in order to fulfill such requirements. With the use of local interface, the performance of web client would be higher than that with remote interface. As you told the two web servers can be used for serving static content and one application server for web container and EJB container. I see this thread gives more information on the purpose of two web servers.
[ November 24, 2006: Message edited by: Durgaprasad Guduguntla ]

[Steve Taiwan]

Dear Andrew.

Steve,
Can you please clarify what you mean by "If there are 10 itineraries..."? I was talking about caching flights for 1 itinerary only, plus alternative cheaper ones within the hour. I feel that 100 is exagerated (at most 10 in my assumptions).

In Prepare Itinerary Use Case,
Step 1: Customer inputs basic criteria
Step 2: System responses (10) flights.
Step 3: Customer selects (1) flight.
Step 4: Return (1..n) flights within one hour.

I mean Step 2 query and Step 4 query don't happen at the same time in Step 2.
The result in Step 4 is queried based on Step 3 and hits DB in Step 4 again.
All information you need for Step 4 is on JSP form or Swing Fram of Step 3. Send the necessary information back to business logic.
Then I don't need any cache.

What do you think?