The Action class isn't the only place to store a remote reference to a session bean. In fact, it's not a good place. Each user needs to have its own remote reference due to the restrictions how many threads can access a single EJBObject.
In what you describe (locking on a queue), you are in fact, using JMS really as you would a session bean. You can store the remote reference or a handle in a proxy object and put that proxy object into the user's sesson. I like JMS/MDB for many different scenarios, but I don't think it fits here. But obviously everyone has their own approach to architectures. I just would take a closer look at some other documentation and books to see what the pros and cons. Pick up one of the EJB books. The fact that you're using Struts really has nothing to do with this design. You would have the same issues if you were using any other presentation framework. Don't let the fact that you have Action classes throw you. They have nothing to do with this situtation. Chuck At 08:15 AM 4/26/2002 -0400, you wrote: >I disagree - though not completely. I think that the approach Chuck >recommends is fine - and is likely the most popular choice. > >But I think that using a JMS queue or MDB as the front to the facade isn't >always inapropriate. Especially in this case, because: > > - The Action classes are singletons. You can't store a reference to a >session bean in one because other sessions will be using the same object. >- A reference to an MDB or JMS queue doesn't have to have session scope. >Its reference can be stored in the action class and reused. > >- Also, you can write to a JMS Queue/MDB and the immediately lock on a read >on the same to wait for your response. >- Multiple sessions can concurrently lock on a read on the queue - each >waiting for just their own response. > - Make sure when you lock on it, that you specify a timeout so you don't >hang. This way you'll be interrupted if you timeout. > - You can lock on a JMS queue waiting for a particular response - you'll >need to figure out how to look for a particular reponse on the queue - look >at the JMS spec, there are a number of ways to do this. > >I think a MDB/JMS queue may be an appropriate front to the facade whenever >you need to queue up access to a limited resource (such as a specific >entity bean instance, or some other remote system). An MDB makes it easier >to ensure that no two session beans are concurrently attempting to lock a >resource or engage the resource in a transaction. > >Both Weblogic and JBoss have good JMS/MDB implementations. I haven't used >or reviewed other containers' JMS/MDB implementations. > >I agree with Chuck on the use of value objects instead of booleans as a >response. JMS/MDB allow you to write objects into them and also to read >them back out as responses. > >Also, the action class itself cannot be a session bean. The primary >org.apache.struts.action.Action servlet wouldn't be able to instantiate it >or store a reference to it correctly - unless you modified how struts >itself works (you have the source code - go ahead of you want!). > > > > > > > > > > > > > >Chuck Cavaness <[EMAIL PROTECTED]> on 04/25/2002 10:08:21 PM > >Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > >To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >cc: >Subject: Re: Action + Session Beans + JMS > > >I think I understand your design and I really think you need to stick to a >synchronous call, instead of the asynchronous JMS call. By its very nature, >the client publishing the message will not get an immediate response, other >than an acknowledgement for the message itself. > >I think you're better off putting the session bean back into the picture. >You don't have to use entity beans, but a session bean method like >authenticate() that returns some type of ValueObject. I wouldn't just >return a boolean. You would be wise to use an object, where you can plan >for growth. Later, if you needed to return more data, you would need to >change the method signature. If you go ahead and return a lightweight >JavaBean-like object now, more data would only mean additional properties >in the view object. > >This is a very common approach to this type of problem. There are plenty of >design patterns for this scenario. Check out the Session Facade and >ValueObject patterns here: >http://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html > > >My two cents. >Chuck > > > >At 04:57 PM 4/25/2002 -0500, you wrote: > >Hey all, > > > >I have a design question and I'm looking for the best practice in > >handling it. > > > > > > > >I am using a customer login for a proof of concept with regards to the > >architecture, here is the current architecture. > > > > > > > >I have a logon jsp that invokes a logonAction. This action takes the > >login information and publishes a message (JMS) to a MDB (message Driven > >Bean). > > > >The MDB calles a Session Bean the authenticates the user. > > > > > > > >Here is the problem - the action pubs the message and once sent - it > >does not know when the process is complete. > > > > > > > >I initially didn't have the JMS layer - So the LogonAction was calling a > >SessionBean Method - ValidateUser and that method returned a Boolean. > >The LogonAction would use the returned Boolean to figure out what view > >to display. > > > > > > > > > > > >I want an elegant way to know when the validation is complete. I was > >thinking about creating a generic action class that's a session bean. > >But I'm wondering since the action classes are singletons, am I creating > >threading problems by doing this. If I was able to make the action a > >SessionBean - The actionSessionBean could become the manager of the > >process and determine what view to display. > > > > > > > >I also thought about sticking something in the session itself - the > >problem with that is the action will not know when to inspect the > >session since the action is only able to publish the message - but not > >listen to it. > > > > > > > >I hope this is a good enough explanation about what I am trying to > >accomplish. Any suggestions would be greatly appreciated. > > > > > > > >DD > > >-- >To unsubscribe, e-mail: < >mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: < >mailto:[EMAIL PROTECTED]> > > > > > > > >--------------------------------------------------------------------------- >This e-mail message (including attachments, if any) is intended for the use >of the individual or entity to which it is addressed and may contain >information that is privileged, proprietary , confidential and exempt from >disclosure. If you are not the intended recipient, you are notified that >any dissemination, distribution or copying of this communication is >strictly prohibited. If you have received this communication in error, >please notify the sender and erase this e-mail message immediately. >--------------------------------------------------------------------------- > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
