Re: [JBoss-user] Design Question
I'm not sure I understand the desire to not have the key in a persistence store. This would mean that if your systems (or jBoss) crashes, your site is unusable until a human being inputs a new key. If you are worried about putting the stuff on a Internet-accessible machine, put another copy of jBoss inside your firewall and call out to a statefull session bean to get the key if you need it. Or another db would also work. In fact, I would put it in the database, locked down under another user id. The DB shouldn't be outside the firewall either, so hacking really should not be a problem. I see several issues with using the user's password. Most systems use a one-way encoding algorythm to store the password, so you can't recover the cleartext of the password that the user entered. Thus, you could never decrypt the cc info, since you can't get the cleartext password back. If you use a two-way encryption algorithm to encrypt the password, then you are back to your original problem, where do you store the key.Also, I'm assuming you are encrypting the cc number itself, so the idea of having an audit trail of the cc numbers defeats the whole purpose to begin with. Marc Brian Topping wrote: How about using an entity bean against a separate data source pointing at a memory DB such as hypersonic? You could configure it not to cache, then when the process died, your single data entry would go with it. To prime the db, the operator would hit an operator page that also had access to that data source. But it seems like you could avoid this problem altogether by crypting each user's wallet with the password that they selected in their account setup. In this manner, each account would have a different key against the respective wallets, eliminating the ability for a cracker to get all the credit card numbers if the master password was cracked. Then you don't have to have so much concern about a persistent password, they are always based on the session. Lost passwords would be managed by assigning a new password, not sending it back to them via email or whatnot. And if they change their password, they lose their wallet, which is smart business anyway. You'll need to keep audit trails of the credit card used with each transaction, but that can be run off to a separate database. If you had a business reason to persist the encrypted cache (wallet), you could keep a lookaside password cache that works in the way you are already working with. The wallets would each still have a different key, but there is a key escrow that is managed more securely... since the private key isn't needed for operation within the business objects. -b -Original Message- From: Jon Swinth [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 8:41 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] Design Question What is the best way to keep a object bound in memory for stateless session bean use? Specifically, I have a java.security.Key that I need to make available to very specific stateless session bean. Since the key is the private RSA key for the credit card database, I do not want to put it in the DB or on the file system. I do not want it available should the server be compromised. I realize that having it in memory is still somewhat accessable for a hacked system, but it is the only thing I have come up with to make the key available to the bean and still make it difficult for a hacker. The original thought is to put the key into a private static variable within the bean so that all copies of the bean in the JVM would have access to the same key. The question is, wouldn't there come a time when all copies of the bean are removed for lack of access and the key would be lost? This is not a huge problem since the first user to receive an error would simply request that the manager upload the key again. That is unless it happens frequently throughout the day. The idea is that the manager would also specify a timeout when uploading the key so that it would drop from memory after a certain amount of time. I am open to any suggestions. --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL
RE: [JBoss-user] Design Question
[Just got Jon's email as I typed this, so I guess it's academic, but still interesting...] -Original Message- From: Marc Zampetti [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 10:15 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Design Question I'm not sure I understand the desire to not have the key in a persistence store. This would mean that if your systems (or jBoss) crashes, your site is unusable until a human being inputs a new key. Not if the wallets are separately encrypted with the end-user password. If you are worried about putting the stuff on a Internet-accessible machine, put another copy of jBoss inside your firewall and call out to a statefull session bean to get the key if you need it. Or another db would also work. In fact, I would put it in the database, locked down under another user id. The DB shouldn't be outside the firewall either, so hacking really should not be a problem. This really isn't sufficient for reasonable security. When I go home at night, I want to know that even if a hacker gets through one layer of my firewall that there isn't anything he is going to be able to do except start hacking another firewall. My pager might go off while i'm not at the office (then, it might not, if they are good), and if I feel like dealing with it, I'll log in and see what's up and whether I can get them out. You can bet I don't want to deal with it if I am in meat space and having a good time. Hackers *will* get in, and when they do, they don't just disappear. They create backdoors that take a while to get rid of, as in, plan a couple of long days. Unless you have packet sniffing trace units monitoring the wire, there is *no* way to be absolutely sure which machines have been compromised and which ones haven't, so you have to assume they are all bad. (This is where you wish your cluster was diskless boot with hardware-locked BIOS, so you could just restart the machines one by one.) But regardless, this all takes time, and unless you are prepared, the offense has the upper hand. I've been hacked a couple of times (once seriously) and it's scary. It's hard enough to figure out how they got in to start with much less fix the source problem *and* get them out before they actually do something really bad (steal/destroy data that will kill business) If your DB unencrypted and not behind a second firewall, you might as well have just handed over the list of customer credit cards to them. Hopefully it's clear that should not be a problem doesn't cut it when you are talking about customer credit cards, IMHO. I see several issues with using the user's password. Most systems use a one-way encoding algorythm to store the password, so you can't recover the cleartext of the password that the user entered. Thus, you could never decrypt the cc info, since you can't get the cleartext password back. For systems that do not make periodic purchases, this is not a bad thing. I don't want *anyone* to make a purchase unless it is made by the owner of the card. If you use a two-way encryption algorithm to encrypt the password, then you are back to your original problem, where do you store the key. For systems that need periodic access to the card (monthly billing cycle, etc.), that's correct. In that case, I'd almost argue that it's not even worth bothering putting the CC behind an encryption function since anyone with access to the business object source is going to have ability to nab a credit card. So just put the DB and the business objects behind a second firewall and leave it at that. This is true up to the point that you are so big that you can afford a security officer to keep the keys, a release organization to make sure that the released code is what it says it's supposed to be, and developers that can only change the code through the release organization, which checks the changes. To start with though, the security officer can be the president and the release organization simply someone different than the programmers (i.e., a responsible manager) Also, I'm assuming you are encrypting the cc number itself, so the idea of having an audit trail of the cc numbers defeats the whole purpose to begin with. Well, I never test anything and my code sux, so I have to have an audit trail to give me a way of fixing my fukups... :) Seriously, no auditor except Anderson is going to let you by without an audit log. The question is how to manage the problem, it's not going to disappear because it's hard. I know, small businesses don't need all this. Same businesses that will be small forever. Think small, stay small. I'm sure not going to be remembered on the same page as Egghead... peas, -b Marc Brian Topping wrote: How about using an entity bean against a separate data source pointing at a memory DB such as hypersonic? You could configure it not to cache, then when the process
RE: [JBoss-user] Design Question
How about using an entity bean against a separate data source pointing at a memory DB such as hypersonic? You could configure it not to cache, then when the process died, your single data entry would go with it. To prime the db, the operator would hit an operator page that also had access to that data source. But it seems like you could avoid this problem altogether by crypting each user's wallet with the password that they selected in their account setup. In this manner, each account would have a different key against the respective wallets, eliminating the ability for a cracker to get all the credit card numbers if the master password was cracked. Then you don't have to have so much concern about a persistent password, they are always based on the session. Lost passwords would be managed by assigning a new password, not sending it back to them via email or whatnot. And if they change their password, they lose their wallet, which is smart business anyway. You'll need to keep audit trails of the credit card used with each transaction, but that can be run off to a separate database. If you had a business reason to persist the encrypted cache (wallet), you could keep a lookaside password cache that works in the way you are already working with. The wallets would each still have a different key, but there is a key escrow that is managed more securely... since the private key isn't needed for operation within the business objects. -b -Original Message- From: Jon Swinth [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 8:41 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] Design Question What is the best way to keep a object bound in memory for stateless session bean use? Specifically, I have a java.security.Key that I need to make available to very specific stateless session bean. Since the key is the private RSA key for the credit card database, I do not want to put it in the DB or on the file system. I do not want it available should the server be compromised. I realize that having it in memory is still somewhat accessable for a hacked system, but it is the only thing I have come up with to make the key available to the bean and still make it difficult for a hacker. The original thought is to put the key into a private static variable within the bean so that all copies of the bean in the JVM would have access to the same key. The question is, wouldn't there come a time when all copies of the bean are removed for lack of access and the key would be lost? This is not a huge problem since the first user to receive an error would simply request that the manager upload the key again. That is unless it happens frequently throughout the day. The idea is that the manager would also specify a timeout when uploading the key so that it would drop from memory after a certain amount of time. I am open to any suggestions. --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] design question
Some advantages of session beans: 1.) Access via RMI. No need for a web server. You can use a Java thin-client approach. The client is mainly user-interface code. The session beans contain some business logic and make use of data access objects that interface to your legacy application. Rather than using JDBC, the data access objects communicate directly with your legacy app. 2.) If you need your backend to maintain some state for each user, then you might want to use stateful session beans. There are other alternatives, of course. If transactions aren't important and you mainly need to interface a browser based application with your legacy application, mainly passing, for example, form data through to the legacy app with little processing or complex logic, then servlets may be the simplest and best performing alternative. EJBs aren't always the best solution. Original Message: From: Tahir Awan [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Date: Tue, 2 Oct 2001 12:04:11 -0400 Subject: [JBoss-user] design question Hi, (sorry for this rePost but I think someone should be able to answer this). For a new project, I need to decide whether its suitable to use session beans or a servlet/jsp approach is enough. The java application talks to a legacy C++ application and all the communication is XML over Https. There's absolutely no requirement to handle transaction and security in java app (as all is done from legacy app). Assuming that scalability, fail-over can also be achieved through a decent servlet engine. Is there any other advantage of using session-beans (entity beans are already gone as there's no persistance to handle). Thanks in advance. ~tahir ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design Question...
Tim Yates wrote: Yeah, the reason we do it this way (and not via HTTP sessions or cookies), is that it was decided early on that it should be possible to style the site differently dependant on the device that was accessing it, and we couldn't guarantee that storing the HTTPSession, or using cookies would work on any of the four major browsing devices... If you're worried about clients that don't use cookies, you could set your JSP/servlet container to use URL rewriting instead of cookies to identify the session. Then your container could automatically reap expired sessions for you. -- Richard Kasperowski (mailto:[EMAIL PROTECTED]) Tel: 617-576-1552, Fax: 617-576-2441 http://www.altisimo.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design Question...
Sorry, by the site, I meant our website - Original Message - From: Tim Yates [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 30, 2001 4:45 PM Subject: [JBoss-user] Design Question... When a user hits the site, they get allocated a unique 48 character session ID (allocated by me). If they then login, I tie that sessionId to a userId (both rows in seperate tables) ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design Question...
This question is more servlet-interest oriented than JBoss oriented. You might want to check out that mailing list. (http://archives.java.sun.com/archives/servlet-interest.html) The typical way I have handled this in the past is to put the userId (if not the entire User*) into the HTTPSession when it's known. If there's a userId in the session, the user is logged in. Database calls are not necessary (for this). This has the beneficial side effect of automatically logging out the user when their session expires. *Putting the User object into the HTTP session will affect scalability if the User object is: - very large - tied to many other objects - is being passed back to the client (Web browser) by the application server. (I have recently read on a mailing list -- this one? -- that some application servers send the HTTPSession's contents back to the client -- somehow -- to keep from managing session state. This sounds ridiculous to me, but I haven't checked the spec to see if it is valid. Even if it is, I do not know for which app servers it is true. For any where it is, you definitely don't want to put the User object into the session.) ~Mike - Original Message - From: Tim Yates [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 30, 2001 10:45 AM Subject: [JBoss-user] Design Question... Hi there!! When a user hits the site, they get allocated a unique 48 character session ID (allocated by me). If they then login, I tie that sessionId to a userId (both rows in seperate tables) But I have a design question... They can log-out, but many do not (obviously), so what would be the best way of clearing out-of-date sessionIds at regular intervals? As far as I can see, I have two choices... 1) A seperate java server which runs through the instance table every hour or so, and calls my EJB's to delete those rows that have become inactive or 2) Use a Timer MBean to callback after a certain time to remove the row... I am thinking that option 2 would be a much cleaner way of doing things, but what would be the way to do it? Sorry if I am talking rubbish, I have been searching for tutorials, and books all afternoon, and the Web (and Amazon) has come up dry :( Thanks for any input you can give :) Tim Yates ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design Question...
When a user hits the site, they get allocated a unique 48 character session ID (allocated by me). If they then login, I tie that sessionId to a userId (both rows in seperate tables) But I have a design question... They can log-out, but many do not (obviously), so what would be the best way of clearing out-of-date sessionIds at regular intervals? Sorry, just re-read this. So... you're making your own session IDs and storing them in the database? Why? If you let the app server do that work for you, you can take advantage of the solution I suggested before. Assuming that is not an option, I would say you are on the right track with the timer MBean. You'll need a field in your session table that gets updated every time one of your users hits a page. Otherwise you have no way of knowing when they have been logged in for a long time and are still working or have left without logging out. (Another argument for using the non-database solution, IMHO.) ~Mike ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design Question...
Yeah, the reason we do it this way (and not via HTTP sessions or cookies), is that it was decided early on that it should be possible to style the site differently dependant on the device that was accessing it, and we couldn't guarantee that storing the HTTPSession, or using cookies would work on any of the four major browsing devices... - Original Message - From: Mike Abney [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 30, 2001 5:28 PM Subject: Re: [JBoss-user] Design Question... Sorry, just re-read this. So... you're making your own session IDs and storing them in the database? Why? If you let the app server do that work for you, you can take advantage of the solution I suggested before. Cheers!! Tim. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design Question...
Hey Tim, If I correctly understand your qutestion, this is more of a servlet type session management issue. Take a look at the javax.servlet.http.HttpSessionBindingListener interface. It's basically a callback interface for when a session expires. Objects in the session, that implement the interface, will be messaged that they are being removed from the session so that they can respond accordingly (in your case call your Entity or whatever to remove the user/session relationship from the data store). So regardless if your user logs out explicity, or the session expires due to inactivity, your object can be notified and do the appropriate clean up. Hope this helps. Chris Murphy On Mon, 30 Jul 2001 16:45:41 +0100, Tim Yates [EMAIL PROTECTED] wrote: Hi there!! When a user hits the site, they get allocated a unique 48 character session ID (allocated by me). If they then login, I tie that sessionId to a userId (both rows in seperate tables) But I have a design question... They can log-out, but many do not (obviously), so what would be the best way of clearing out-of-date sessionIds at regular intervals? As far as I can see, I have two choices... 1) A seperate java server which runs through the instance table every hour or so, and calls my EJB's to delete those rows that have become inactive or 2) Use a Timer MBean to callback after a certain time to remove the row... I am thinking that option 2 would be a much cleaner way of doing things, but what would be the way to do it? Sorry if I am talking rubbish, I have been searching for tutorials, and books all afternoon, and the Web (and Amazon) has come up dry :( Thanks for any input you can give :) Tim Yates ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Design Question...
You can also switch to a servlet container that supports v2.3 of the Servlet specification, such as Catalina (Tomcat v4.0). The new servlet spec supports event handling, and there is an event for the timeout of sessions. You can add a listener for these events, and do any necessary cleanup when the session times out. Of course, you'd need to add some extra logic to do additional cleanup at startup, in the event of a hard failure in the servlet container. -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Toby Hede Sent: Monday, July 30, 2001 11:34 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Design Question... another way to approach this is through the datbase itself, writing a trigger to remove the data and setting a schedule for processing. most modern rdbms systems have similar implementations - Original Message - From: C Murphy @ Intechtual [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 31, 2001 3:15 AM Subject: Re: [JBoss-user] Design Question... Hey Tim, If I correctly understand your qutestion, this is more of a servlet type session management issue. Take a look at the javax.servlet.http.HttpSessionBindingListener interface. It's basically a callback interface for when a session expires. Objects in the session, that implement the interface, will be messaged that they are being removed from the session so that they can respond accordingly (in your case call your Entity or whatever to remove the user/session relationship from the data store). So regardless if your user logs out explicity, or the session expires due to inactivity, your object can be notified and do the appropriate clean up. Hope this helps. Chris Murphy On Mon, 30 Jul 2001 16:45:41 +0100, Tim Yates [EMAIL PROTECTED] wrote: Hi there!! When a user hits the site, they get allocated a unique 48 character session ID (allocated by me). If they then login, I tie that sessionId to a userId (both rows in seperate tables) But I have a design question... They can log-out, but many do not (obviously), so what would be the best way of clearing out-of-date sessionIds at regular intervals? As far as I can see, I have two choices... 1) A seperate java server which runs through the instance table every hour or so, and calls my EJB's to delete those rows that have become inactive or 2) Use a Timer MBean to callback after a certain time to remove the row... I am thinking that option 2 would be a much cleaner way of doing things, but what would be the way to do it? Sorry if I am talking rubbish, I have been searching for tutorials, and books all afternoon, and the Web (and Amazon) has come up dry :( Thanks for any input you can give :) Tim Yates ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design question - Singleton
It sounds like there is a problem with your design if you are trying to do this - the EJB container controls all instance creation, so you can't really create a true Singleton bean. What are you trying to do? There are many other ways to get Singleton-like functionality with EJBs. I'm assuming the bean is stateless if you want to create a Singleton, and for stateless beans the container will create as many instances as necessary to service client requests. Alex |+-- || Hermann RANGAMANA | || [EMAIL PROTECTED] | || Sent by:| || [EMAIL PROTECTED]| || eforge.net | || | || | || 07/05/01 05:07 AM | || Please respond to jboss-user| || | |+-- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: [JBoss-user] Design question - Singleton | ---| Hi all, I have a session bean, which number of instance should be limited to 1 (Singleton). How can i implement this with ejb? --hermann ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Design question - Singleton
Hi, is it not possible to have a static field in the Session Bean, I mean it is not made persistent anyway. Have you tried this approach with the static field ? Frank ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Design question - Singleton
Hi, I wonder if it is possible to have a static field in the session bean and check if this field is set in the ejbCreate() and then react according to set status of this field. I never tried it but would this be a way to do it ? Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 12:23 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JBoss-user] Design question - Singleton It sounds like there is a problem with your design if you are trying to do this - the EJB container controls all instance creation, so you can't really create a true Singleton bean. What are you trying to do? There are many other ways to get Singleton-like functionality with EJBs. I'm assuming the bean is stateless if you want to create a Singleton, and for stateless beans the container will create as many instances as necessary to service client requests. Alex |+-- || Hermann RANGAMANA | || [EMAIL PROTECTED] | || Sent by:| || [EMAIL PROTECTED]| || eforge.net | || | || | || 07/05/01 05:07 AM | || Please respond to jboss-user| || | |+-- --- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: [JBoss-user] Design question - Singleton | --- | Hi all, I have a session bean, which number of instance should be limited to 1 (Singleton). How can i implement this with ejb? --hermann ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design question - Singleton
The EJB spec forbids an enterprise Bean to use read/write static fields. This restriction is part of the contract with the EJB Container to control the bean lifecycle, e.g. by transparently distributing bean instances across multiple JVMs. I understand GemStone was big on spawning JVMs. The standard EJB singleton technique is to bind the singleton instance to a known JNDI location and access it via JNDI lookup. A JNDI singleton is safe because it is unique in the namespace and the jndi hook prevents garbage collection. Frank Marx wrote: I wonder if it is possible to have a static field in the session bean and check if this field is set in the ejbCreate() -- Fred Loney Enterprise Java Consultant Spirited Software, Inc. [EMAIL PROTECTED] ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Design question - Singleton
Ok , makes sense. but when you leave the Spec a bit behind you can use it with static fields too I guess :-). Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Fred Loney Sent: Thursday, July 05, 2001 4:33 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Design question - Singleton The EJB spec forbids an enterprise Bean to use read/write static fields. This restriction is part of the contract with the EJB Container to control the bean lifecycle, e.g. by transparently distributing bean instances across multiple JVMs. I understand GemStone was big on spawning JVMs. The standard EJB singleton technique is to bind the singleton instance to a known JNDI location and access it via JNDI lookup. A JNDI singleton is safe because it is unique in the namespace and the jndi hook prevents garbage collection. Frank Marx wrote: I wonder if it is possible to have a static field in the session bean and check if this field is set in the ejbCreate() -- Fred Loney Enterprise Java Consultant Spirited Software, Inc. [EMAIL PROTECTED] ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design question
If you want to make it read only, will JBoss allow you to write the remote interface such that it only has getters?The M-H book suggests not even exposing the remote interface for enitity beans. Certainly it would be preferable to have on the getters available to most clients. [EMAIL PROTECTED] wrote: All, We often think of using Entity beans to represent rows or entities in a database, but not much else. Is it a good idea to use an entity bean to represent entries in an LDAP directory? I was thinking aboutu throwing together a BMP entity bean to do this. It would always be in a read-only mode on this, and I'd like to be able to take advantage of the caching features that would be available for 'free' within the container. I currently have a session bean in place that performs look ups and populates serializable data objects to return to the calling clients -- this could be simler if it could just be done via an entity bean. -Jason ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design question
Adam Young wrote: If you want to make it read only, will JBoss allow you to write the remote interface such that it only has getters?The M-H book suggests not even exposing the remote interface for enitity beans. Certainly it would be preferable to have on the getters available to most clients. A remote method is a remote method. There's nothing saying that an entity has to be mutable at all [EMAIL PROTECTED] wrote: All, We often think of using Entity beans to represent rows or entities in a database, but not much else. Is it a good idea to use an entity bean to represent entries in an LDAP directory? I was thinking aboutu throwing together a BMP entity bean to do this. It would always be in a read-only mode on this, and I'd like to be able to take advantage of the caching features that would be available for 'free' within the container. I currently have a session bean in place that performs look ups and populates serializable data objects to return to the calling clients -- this could be simler if it could just be done via an entity bean. -Jason ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design Question
I notice that some folks advocate the entities inheriting from the value objects... It seems like this won't work with EJB2.0 as the accessor methods for a CMP bean have to be abstract... Any thoughts on the best way to pull this off without duplicating tons of code in the entity beans and the value objects? Hunter From: DeGreef, Chris J. (AIT) [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Wed, 16 May 2001 15:39:04 -0400 To: '[EMAIL PROTECTED]'[EMAIL PROTECTED] Subject: RE: [JBoss-user] Design Question I have had good luck with a similar design. Here is what I do in cases like this. Most of this was found by reading articles / books and trial and error. In a JSP file I use the useBean to create / find a bean that resides in the same VM as the servlet engine. This bean follows the command pattern. When it is executed it creates a session bean (on the EJB container), pushes the data into the session bean, and generally interacts with it. Most likely the session bean updates some of its instance variables during this time. Just before the execute is completed, the command class pulls the variables back into it (refreshed). At critical moments the session bean may have interacted with entity beans, if necessary. The command classes never talk directly to entity beans (perhaps bypassing imporant business logic) and the JSPs never talk to anything except the command classes. The command classes provide a tidy place to handle all of the JSP data conversion requirements; like converting the information to and from string representations. It also allows you to control the communication to the EJB container. For instance, all of the data could be sent (or retrieved) in one message send. The session beans are a good place to put all of the business logic. The entity beans are a good place to handle all of the data mapping issues. Has anyone had experience implementing this pattern on a large scale? (large volume?) -Original Message- From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 1:03 PM To: JBoss 2 Subject: [JBoss-user] Design Question Okay... Starting the design on my first ever EJB/JBoss project. It's only going to be accessible via the Web... I want to make sure I make an educated decision on the design. This is what I'm thinking: Requests come in via a servlet, which invokes methods on a stateless session bean that uses CMP entities to create details objects, which are placed in the request scope for JSPs to display. For parts of the site that are transactional, input will be received by the servlet then fired off to the appropriate stateless session beans and then to the entities as necessary. Any major flaws in this generic description? It seems to be similar to what sites like TheServerSide.com have implemented but since I've never done this before, I may be misunderstanding something basic. It seems like creating read-only details objects are the best way to push content out to the JSPs for display. Is there another approach (besides calling entities directly - this seems way too expensive) that I am ignoring? Hunter ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design Question
Hunter Hillegas wrote: Okay... Starting the design on my first ever EJB/JBoss project. It's only going to be accessible via the Web... I want to make sure I make an educated decision on the design. This is what I'm thinking: Requests come in via a servlet, which invokes methods on a stateless session bean that uses CMP entities to create details objects, which are placed in the request scope for JSPs to display. You might want to look at the Struts framework for help there (jakarta.apache.org) For parts of the site that are transactional, input will be received by the servlet then fired off to the appropriate stateless session beans and then to the entities as necessary. The entities are called from the stateless bean, correct? This is the easiest/best way to handle the transaction. Any major flaws in this generic description? It seems to be similar to what sites like TheServerSide.com have implemented but since I've never done this before, I may be misunderstanding something basic. It seems like creating read-only details objects are the best way to push content out to the JSPs for display. Is there another approach (besides calling entities directly - this seems way too expensive) that I am ignoring? You're heading in a pretty good direction, IMHO. -danch ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Design Question
I have had good luck with a similar design. Here is what I do in cases like this. Most of this was found by reading articles / books and trial and error. In a JSP file I use the useBean to create / find a bean that resides in the same VM as the servlet engine. This bean follows the command pattern. When it is executed it creates a session bean (on the EJB container), pushes the data into the session bean, and generally interacts with it. Most likely the session bean updates some of its instance variables during this time. Just before the execute is completed, the command class pulls the variables back into it (refreshed). At critical moments the session bean may have interacted with entity beans, if necessary. The command classes never talk directly to entity beans (perhaps bypassing imporant business logic) and the JSPs never talk to anything except the command classes. The command classes provide a tidy place to handle all of the JSP data conversion requirements; like converting the information to and from string representations. It also allows you to control the communication to the EJB container. For instance, all of the data could be sent (or retrieved) in one message send. The session beans are a good place to put all of the business logic. The entity beans are a good place to handle all of the data mapping issues. Has anyone had experience implementing this pattern on a large scale? (large volume?) -Original Message- From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 1:03 PM To: JBoss 2 Subject: [JBoss-user] Design Question Okay... Starting the design on my first ever EJB/JBoss project. It's only going to be accessible via the Web... I want to make sure I make an educated decision on the design. This is what I'm thinking: Requests come in via a servlet, which invokes methods on a stateless session bean that uses CMP entities to create details objects, which are placed in the request scope for JSPs to display. For parts of the site that are transactional, input will be received by the servlet then fired off to the appropriate stateless session beans and then to the entities as necessary. Any major flaws in this generic description? It seems to be similar to what sites like TheServerSide.com have implemented but since I've never done this before, I may be misunderstanding something basic. It seems like creating read-only details objects are the best way to push content out to the JSPs for display. Is there another approach (besides calling entities directly - this seems way too expensive) that I am ignoring? Hunter ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Design Question
Chris, Yes I did experiment this approach and it worked great. Many people may think we are adding too many layers to accomplish the tasks but I believe this approach gives a very clean separation between the biz logic and presentation layers. Something to note. I found that useBean is kind of misleading for EJB developers because it doesn't refer to Entreprise Beans to me. I implemented the command pattern using just a 'regular' class which interacts with an ejb session bean. I still use the useBean tag to instanciate (automaticly) my 'regular' java class. I believe that is the way you did as well. I am correct ? Dovan DeGreef, Chris J. (AIT) wrote: I have had good luck with a similar design. Here is what I do in cases like this. Most of this was found by reading articles / books and trial and error. In a JSP file I use the useBean to create / find a bean that resides in the same VM as the servlet engine. This bean follows the command pattern. When it is executed it creates a session bean (on the EJB container), pushes the data into the session bean, and generally interacts with it. Most likely the session bean updates some of its instance variables during this time. Just before the execute is completed, the command class pulls the variables back into it (refreshed). At critical moments the session bean may have interacted with entity beans, if necessary. The command classes never talk directly to entity beans (perhaps bypassing imporant business logic) and the JSPs never talk to anything except the command classes. The command classes provide a tidy place to handle all of the JSP data conversion requirements; like converting the information to and from string representations. It also allows you to control the communication to the EJB container. For instance, all of the data could be sent (or retrieved) in one message send. The session beans are a good place to put all of the business logic. The entity beans are a good place to handle all of the data mapping issues. Has anyone had experience implementing this pattern on a large scale? (large volume?) -Original Message- From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 1:03 PM To: JBoss 2 Subject: [JBoss-user] Design Question Okay... Starting the design on my first ever EJB/JBoss project. It's only going to be accessible via the Web... I want to make sure I make an educated decision on the design. This is what I'm thinking: Requests come in via a servlet, which invokes methods on a stateless session bean that uses CMP entities to create details objects, which are placed in the request scope for JSPs to display. For parts of the site that are transactional, input will be received by the servlet then fired off to the appropriate stateless session beans and then to the entities as necessary. Any major flaws in this generic description? It seems to be similar to what sites like TheServerSide.com have implemented but since I've never done this before, I may be misunderstanding something basic. It seems like creating read-only details objects are the best way to push content out to the JSPs for display. Is there another approach (besides calling entities directly - this seems way too expensive) that I am ignoring? Hunter ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Design Question
|Something to note. I found that useBean is kind of misleading for EJB |developers because it doesn't refer to Entreprise Beans to me. I sure does refers to EJB to me, javabeans as EJB is a standard pattern (hide the EJB semantics), marc ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
