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]>
