portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Le Strat <dlest...@yahoo.com>
Subject Re: Jetspeed2 development
Date Fri, 24 Oct 2003 03:33:15 GMT
Thanks for your response Prabhu. That makes sense. Do
you have any ideas on ow to go about implementing
something like this in J2?

Looks like the Blackberry is showing handy ;o).

Regards,

David.

--- Prabhu Kapaleeswaran <PKapaleeswaran@ifc.org>
wrote:
> Greetings
> 
> Thank you I definetely agree emai is not the best
> medium
> 
> The way the rules advisor handling this is by
> defining three different users or actors for this
> usecase
> 
> 1 rule creator
> 2 rule modifier
> 3 end user
> 
> The ruke creator typically creates the top level
> rules but apart from creating the rules he also
> creates value holders or place holders in the rule
> which he thinks might change.
> 
> The rule modifier typically specifies values for
> these holes or the holders
> 
> During runtime they mix it to fornm the complete
> rule and then u also have the fact which is the user
> and bingo u have it running
> 
> We can do something similar
> 
> Cheers
> Prabu k
> 
> 
> --------------------------
> Sent from my BlackBerry Wireless Handheld
> 
> 
> 
> ----- Original Message -----
> From: David Le Strat [dlestrat@yahoo.com]
> Sent: 10/23/2003 06:10 PM
> To: Jetspeed Developers List
> <jetspeed-dev@jakarta.apache.org>
> Subject: Re: Jetspeed2 development
> 
> Your response is great. Email is definitely not the
> best kind of medium for that type of discussion as
> it
> usually takes quite a few of them to get on the same
> page. ;o)
> 
> And I think we are mostly on the same page.  Most
> rule
> engines I know use an XML definition to define the
> rule.  As a developer the rule you give as an
> example
> (user.age > 60 and user.sex = male then
> > show him the discounts) is translated as an XML
> document <condition>blabla</condition>.
> 
> Now, in your portlet you reference the rules and get
> a
> dynamic behavior.
> 
> However, in most cases, rules need to be able to be
> managed by business owners and those business owners
> should have the ability to modify the rules
> conditions.  Let's say user.age > 60  doesn't work,
> I
> want to change it to user.age > 45. You need to
> provide the ability to do this while the application
> is running and can't redeploy everything for such a
> change.  Therefore, how do you tie the change made
> at
> runtime, remember that change so that next time the
> application gets redeployed it is not overwritten.
> 
> Thoughts on this?
> 
> We may want to limit the scope of what we are trying
> to do but part of the value of a rule engines is to
> be
> able to achieve this.
> 
> Regards,
> 
> David.
> 
> --- Prabhu Kapaleeswaran <PKapaleeswaran@ifc.org>
> wrote:
> > Greetings !!
> >
> > Just to give you a small brief of what we are
> trying
> > to discuss. This will
> > bring us both to a same pace.
> >
> > A typical rule system has 3 things
> > 1. Rules
> > 2. Facts
> > 3. Agenda
> >
> > The rules are typically defined by a business
> > manager which say something
> > like if the user.age > 60 and user.sex = male then
> > show him the discounts
> > on male items such as a walking stick etc etc.
> >
> > During runtime when a user comes in, this is
> > actually compared to this
> > rule and the execution happens. The actual process
> > is done through a RETE
> > (comb) network (I guess if you search for Charles
> > Forgy, you could get
> > more information). Drool as well as JESS are
> > implementation of RETE.
> >
> > We can do a small portlet which uses the user data
> > structure to go into a
> > rule based system and show advertisements or some
> > kind of personalized
> > message particular this user. We can do this by
> > either integrating to an
> > existing RETE or building a new RETE.
> >
> > We can provide hooks to these engines from
> jetspeed
> > definitely. What I
> > dont understand is what do you mean when you say
> > runtime and deployment ?
> >
> > I am not sure if you are talking about making a
> > framework to capacitate
> > the hooking and people to use this engine.
> >
> > Cheers
> > Prabu K
> >
> > PS : Sorry if my reply seems to be too academic, I
> > just wanted to
> > understand your point of view before we can get
> > started on anything.
> >
> >
> >
> >
> >
> > David Le Strat <dlestrat@yahoo.com>
> > 10/23/2003 10:39 AM
> > Please respond to "Jetspeed Developers List"
> >
> >
> >         To:     Jetspeed Developers List
> > <jetspeed-dev@jakarta.apache.org>
> >         cc:
> >         Subject:        Re: Jetspeed2 development
> >
> >
> > Prabhu,
> >
> > The JSR you mention is JSR94 and has been in
> public
> > review since September 2002.  In any case, I am
> not
> > sure we have to write the tool. We need to write
> the
> > Jetspeed hooks to the personalization engine.  A
> > rule
> > engine like Drools is on its way to JSR94 and
> should
> > be able to be exposed to Jetspeed as a rule engine
> > service (or whatever other rule engine, we could
> > create a wrapper for the rules engine or really on
> > the
> > JSR94 api).  The challenge I see is tiing the
> rules
> > being deployed to their runtime lifecycle.
> >
> > In many personalization engines, the initial rule
> > template is created at development time and
> managed
> > at
> > runtime.
> >
> > At development time, you create a rule that say
> and
> > tie it to some code, jsp tag lib, code, whatever:
> >
> > Show content to User X with Attribute Y and Z.
> >
> > At runtime, the business user changes this to:
> >
> > Show content to User in Group X with Attribute X1
> > and
> > Z2.
> >
> > Now, we need to tie the two and maintain the
> > relationship between runtime and deployment.  Do
> you
> > have experience with this. I think this is where
> the
> > difficult part of the work is.  Thoughts?
> >
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message