I didn't mean to be so matter of fact. A session bean is surely not the only way to fa�ade enterprise resources, such as a security service. Here�s where I thought the design would not work.
When the client published a message to the JMS Queue, the EJB container would automatically pull a MDB from the pool to service the request. Since MDB�s are anonymous, there�s no reference from the client to the MDB. For the MDB to know which session bean to perform a callback on, it would probably need to have a remote reference or handle to actually perform the callback. I don�t think serializing a remote reference or handle through a JMS Queue, on to a MDB, so that it can perform a callback on the session bean, is a good idea. Not to mention the performance issue. Remember, the session bean method is blocking the entire time that this is going on. If the MDB didn�t have a remote reference, I don�t think it would be able to return the login result back synchronously to the client. If there�s a way, it�s no clear to me. Remember, MDB�s are anonymous. There�s not remote reference to them. The container is the one that passes the JMS message to the MDB, not the client or the Queue. These are the problems that I see with the approach. You just don�t see this design used for this type of problem. The mainstream approach is to use a session bean (if you are using EJB). There are very common and accepted patterns for something like this. Even if you weren�t using EJB, you could use an ordinary class to communicate with a DB and get the response. That�s why I mentioned using a proxy. I would hide the fact that it�s a session bean or not by using a business delegate interface and that�s what the Action class would know about. I never import any EJB packages into Struts at all. I hide this using a proxy. Again, just my thoughts. Chuck > > > > Chuck, > > I appreciate your insight here. Thanks. > > In general, I agree with your recommendations of using the standard session > bean front to the facade. Storing the remote reference somewhere in the > session context (perhaps in a User bean) again is the right approach. > > But I still feel that a MBD/JMS queue is not always innapropriate as the > front to the facade. Specifically, I think it makes sense when you need to > queue up requests to a particular resource and manage the resource more > closely than having multiple concurrent session beans attempting to access > it. > > The MBD/JMS approach allows you to have a single thread in the back-end > getting the requests off the queue and managing access to the resource one > at a time. This allows you, for example, to serialize transactions against > a back-end system that for some reason can't participate in more than one > transaction concurrently. > > > FWIW - > Kevin > > > > > > > > Chuck Cavaness <[EMAIL PROTECTED]> on 04/26/2002 08:48:25 AM > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > cc: > Subject: Re: Action + Session Beans + JMS > > > 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]> > > > > > > > > --------------------------------------------------------------------------- > 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]>
