Currently the design is to cache the instances of the Stateful Session beans, and do that in the Actions themselves. One SSB per Action. The reason for the SSB is primarily for the transaction support (online ordering) but also because addition EJB use will be needed in the future anyway (interfacing with an existing system that will eventually use Message Driven Beans to communicate...using simply JDBC to populate a "posting" table now).
You are correct in that the web interface is for an existing application (the one that will eventually talk through a message queue...but today only works with posting tables...another reason why transaction support is a good thing). I guess it might make sense to keep the intermediate information (the lists that can be ordered, the patients the items can be order for, etc.) in the servlet's session as you say. The SSB's though would still be used though to get the intermediate data to be passed back and held in the servlet. Example...the user needs to get a list of patients that the order will be applied to. The RetrievePatientsAction gets invoked, and it in turn creates a SSB (if one isn't already cached) to perform the actual business logic needed to do this step. Using that data, a JSP is created and the user selects a patient, and then requests a list of items applicable to that patient. Then the request to retrieve that information is passed in and a similar process occurs to the one above. Finally, all of the information is available, and an order is place that goes through a similar process. This is a semi-contrived example of course but it is an example of what the thinking is. -----Original Message----- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 12:21 PM To: Struts Users Mailing List Subject: Re: Semi-OT: Saving state when using EJB Session Beans and Struts It's difficult to know what scenario you are talking about here. I assume you mean to cache the EJBs in the user's servlet session, so you will have several remote EJBs in there depending on how many different actions the user has accessed. It sounds like you need to do this to allow transaction management across a group of data operations? I would not do it by caching the EJBs at all, or having stateful session beans. I would keep my actionformbean in the user's servlet session instead, accumulating the data over several http requests and then marshall the whole collection of data across to the EJB session in one. Struts is good at that. I expect you'd give yourself more headaches than it's worth, trying to collect the user's session data in the EJB layer. It sounds like you are writing a web interface for an already existing client-server app. On 03/02/2004 03:42 PM Smith, Darrin wrote: > Thanks for the reply! > > That is kind of what is going on already. The Action's act as the local > Java class talked about in the Business Delegate Pattern that create and > cache the Stateful Session Bean (a different one per Action). They (the > Actions) then use the Session Bean's business logic. This is done in a > standard way though where each Session Bean will implement an interface that > is common to all of the other Session Beans in the application. This way > each action simply calls a factory and based on the way the factory is > called, a Stateful Session Bean for that type of action is returned, then > cached in the Action. All actions then can make the submit(...), > inspect(...), etc. calls common to all types of Session Beans (but performed > differently by each one). > > The question is though, for these actions, shouldn't they keep session state > that will match the Stateful Session Beans? Typically, I know you want have > your Model hold Session state while your client holds request state, but in > this case, where the Action needs to remember the cached Session Bean, > doesn't it seem to make sense to mark the Action as session scope in the > struts config file as well? > > > > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Monday, March 01, 2004 5:35 PM > To: Struts Users Mailing List > Subject: Re: Semi-OT: Saving state when using EJB Session Beans and > Struts > > > On 03/01/2004 05:47 PM Smith, Darrin wrote: > >>In short, the Actions will be calling various Stateful Session Beans to do >>the actual work. These are used for various reasons with the main one > > being > >>their built-in transaction support (online orders...need to be either >>done...or not done). How should state be handled and at what level >>(page...request...session...) in the upstream struts portion? > > > Hmmm. Thought someone more knowledgeable would answer this, and was > waiting with interest myself. Oh well. Without too much experience with > EJBs myself, I can say a couple of things: the gurus say 'use the > business delegate pattern with an EJB session facade'. Secondly, it > depends heavily on what your stateful session beans are holding as > state. Care to name something? > > Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
