(Attemping to speak around his foot) I'm really not frustrated by the question. Can I try again? You can put anything in a Session, Stateless Session or Entity Bean. The thing is, so much is under the control of the bean's deployment descriptor that its almost meaningless to offer an opinion. Passivation (or not) time-outs, re-entrancy, transaction isolation, identity, access control attributes, finders, persistent store attributes On the database persistence side there are BLOBS, and the "fire exit" of bean managed persistence so you can store it anyway you want to. You can have a real justification (or problem) with most any stance you could take, and the reasons would have nothing to do with JESS, but application and EJB design issues. Some are: 1) Where and why do I need transaction boundaries. 2)What type of rollback, if any is appropriate. 3) Is pooling a help or hinderance to the cause, and if so is there a synchronization of data or state across instances that needs to occur. 4) How should a failover be handled ....... etc. There is Demeter's Law on dividing responsibilities among objects, which is easy to violate with a rules engine; A certain company has already done the "Hey lets autogenerate EJB's from the ER diagram using this cool vendor tool and Blaze can do everything else" (wince) Vendors claim a lot of things, don't they........... The assumption is that the rules engine should sit somewhere as a service, like logging. But your engine likely has core business logic in it. If you have a well defined API between architectural layers, that will drive the location of the engine. If you don't, - watch out for weird coupling and fragility between the engine and everything else. All this frustrates the attempt of a vendor to stamp out a usefull "Session Bean" engine that is anything but a shell. Yep, Blaze has one that is essentially example code and all it really does is call "new" on its version of Rete. On the "analysis and design" remark, I am truly sorry. I don't necessarily have the answers but I do have the scars. The first big project I was officially named architect for had 63 developers, and I wasn't ready for it. We bit off quite a bit more than we could chew, with a lot of encouragement from our customer. The aftermath was ugly, people lost jobs, tanked careers and you know what? It was my fault. Yes, when I heard you ask if an entity (not session) bean can contain a rules engine it was concerning. If you don't understand why I was concerned, well, that makes me more concerned. Your comment about hundreds of concurrent users seems glib and scary in context. We've been doing EJB's here for almost 2 and a half years and its tough. The EJB 2.0 specification is effectively stalled due to some of the same issues. I'm not renown for people skills, but I do try. If anything I've said makes you pause, thats all I ask. Alan Moore wrote: > [aditya wrote] > What I do not understand is why can't you use JESS as a bean ?? > > [alan] > To whom are you addressing the question? > > I don't know of any difficulty Mr. Grounder may be having since I think his > questions are about possible jess "limitations" rather than a specific > implementation roadblock. > > If you are asking "Why can't JESS be used as a bean?" there is no technical > limitation preventing it AFAIK. However, the answer being put forward on > this list is that it may not be the best thing to do *depending on your > circumstances*. > > From Mr. Grounder's questions it seems that his approach will have some > problems but nothing that couldn't be made to work at some level. The > specific problems pointed out by Ernest and others are centered around > partitioning the problem space and taking into account some critical > performance issues. Even these concerns are less about jess-as-bean and more > about some of the proposed rules/facts/use cases mentioned in the earlier > posts. > > Is it the right tool for the job? The answer depends on the job and on how > you use the tool <grin> > > [also, chinnaswamy wrote] > May be some times, my question may not be very clear > and even for that ernest replied for all of my > possible thoughts. > > [alan] > Isn't he kind and generous with his time and efforts? Of course, if he > weren't so damn fast in answering others on the list might pitch in more > often! Maybe I should check the list at 3:00am when he is sleeping... > > Three cheers for Ernest!!! <the crowd roars> > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of chinnaswamy gounder > Sent: Wednesday, March 28, 2001 9:30 AM > To: Greg Ball > Cc: [EMAIL PROTECTED] > Subject: Re: JESS: Re: Can a Rete engine be put in EJB session bean > orentity bean > > Sorry about that if my question I asked you made you > frustrated. > > Thanks a lot to ernest for his patience in answering > my ( some are frustrating ) questions. > > Of course, a rule engine can be a stand alone product > receiving information from enterprise java bean > objects and serve them. This I am fully aware. > > But for your kind information, I need to tell you a > few things. Recently ILOG made a presentation in my > office and claimed that in JRules, the rule repository > is put in Data Base and the rule engine can a stateful > session bean. Pl. take a look at the URL: > http://industry.java.sun.com/javanews/stories/story2/0,1072,22698,00.htm > l. > There it is written, > > " ILOG JRules works on a Java client in the form of an > applet, or on a server as a servlet, EJB component, > CORBA component, or COM+ component" > > In another presentation by Brocat Pte Ltd, their Blaze > Advisor Rule engine stores the rules in files and the > rule engine can be a stateful or stateless session > bean. > > These are the reasons I asked you that question. I > just wanted to clarify that when the other Rule engine > products have a feature, does Jess too have the same > feature or not. But you have gone to the extend of > estimating my future? Anyway, I thank you for your > advice on my 'analysis and design' knowledge. > > May be some times, my question may not be very clear > and even for that ernest replied for all of my > possible thoughts. > > Thanks and regards > > Chinnaswamy > > --- Greg Ball <[EMAIL PROTECTED]> wrote: > > "....... Basically this question is isomorphic to > > asking if your database should be > > an EJB." > > > > Geez, drown the poor guy. Besides I thinks its more > > a matter that the components > > are orthogonal <grin> > > > > Seriously, wishing to help but not offend, may I > > recommend you purchase a book on > > analysis and design? As gently as I can say it, > > the inexperience in your > > questions and your statement about 100's of > > concurrent users point to a really big > > crash in your future. I debated about sticking my > > nose in, but finally decided I > > would rather see you be successfull: Don't bite off > > so much at one time. Is an EJB > > app server really necessary? Maybe concentrate on > > JESS with a simple servlet front > > end. > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, send the words 'unsubscribe > > jess-users [EMAIL PROTECTED]' > > in the BODY of a message to [EMAIL PROTECTED], > > NOT to the > > list (use your own address!) List problems? Notify > > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > > > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/?.refer=text > > --------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the > list (use your own address!) List problems? Notify > [EMAIL PROTECTED] > --------------------------------------------------------------------- > > --------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the > list (use your own address!) List problems? Notify > [EMAIL PROTECTED] > --------------------------------------------------------------------- > > --------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the > list (use your own address!) List problems? Notify [EMAIL PROTECTED] > --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] ---------------------------------------------------------------------
