Skip to main content

Rules RA

28 replies [Last post]
ivelin
Offline
Joined: 2003-07-13
Points: 0

...continuing the Business Rules RA discussion started on the Mobicents contributors forum.
http://forums.java.net/jive/thread.jspa?threadID=24927&tstart=0

Inviting RA vendors to participate in the design of a portable Rules RA Type.

Ivelin

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
eduardomartins
Offline
Joined: 2005-10-10
Points: 0

The use of MBean binds this RA with J2EE, which may be bad because SLEE does not requires J2EE. I would prefer a SLEE service that implements the RA management by receiving events from the SLEE J2EE connector.

Regards,

Eduardo

ivelin
Offline
Joined: 2003-07-13
Points: 0

JMX is a core API in JSE 5.

ivelin
Offline
Joined: 2003-07-13
Points: 0

Bruno, the current implementation of jsr 94 in drools does not make it easy to distinguish between facts asserted externally and those that result from consequences. this makes practical use inconvenient.

ivelin
Offline
Joined: 2003-07-13
Points: 0
abhayani
Offline
Joined: 2005-04-04
Points: 0

Hi Guys,

I have checked in the second round of code. This piece of code is based on IVR for Banking need.
The important differences are

1) Now once the Fact is asserted we get the consequences immediately (Sync way).
2) Once Sbb get's the consequences, Sbb decides based on consequences what it has to do next? For example go to next sub-menu, begin recording, forward call, go back to previous menu etc.

I am trying to understand the JMF and it is taking quite some time. Recording is not working as of now and I am trying to debug what could be the possible problem. I will try to explain the flow and what is the problem

For the first time when onInvite is called AppSbb calls creates new mediaSession and calls mediaSession.createTransmitterReceiver() which plays the welcome audio. After this user press 4 to begin recording and AppSbb plays the recording.wav audio by again calling to mediaSession.createTransmitterReceiver(). At this point the inboundMediaSource becomes null and when AppSbb calls mediasession.startRecording() the "The inbound media stream cannot be null when recording begins." exception is thrown

Any help from you guys is highly appreciated. Also any feed back is welcome. The source-code for media-rtp is missing. Can one of you update wiki and expalin where to get the media-rtp code from? I believe its sun implementation of RTP but not sure.

Please excuse the quality of code as I am more focused on functionality. Cleaning can be done latter.

Amit.

abhayani
Offline
Joined: 2005-04-04
Points: 0

Hi Guys,

Today I have checked in RulesScannerMBean for Rules RA. RulesScannerMBean will scan directories, rules files after every 'scanPeriod' that user can configure. This is still not completed and I am working on it. I am stuck on how we integrate the ResourceAdaptor and MBean? Is there any generic pattern that mobicents follow? Has any of you ever done this?

I can think of flow as
1. MBean should be deployed before RA.
2. In RA we can get the MBean from MBean server and pass on the rules file name that comes from Sbb (When Sbb calls getNewRulesSession on RulesProvider)
3. MBean has list of File URL's that it monitors and can create WorkingMemory by matching the file name with name passed.
4. If there is change in rules file, MBean can detect this and dispose the WM.
5. RA should be notified of this may be MBean emits an event and RA is listener and RA destroys the activity which is using this wm

Can you guys suggest something better than this?

Thanks for your feedback :)

Amit.

brunoduarte
Offline
Joined: 2006-09-07
Points: 0

Uhmm... Can you please explain us the need of the MBean pls?!

In my understanding RAs run 'outside' of the SLEE container and interact with Sbbs (with events or the interface).

Why don't you implement the RulesScanner directly in the RA?

abhayani
Offline
Joined: 2005-04-04
Points: 0

I have checked in the working model of RulesScannerMBean.
After talking to Rules core team I realize that creating workingMemory from RuleBase is not at all costly but creating the RuleBase is a costly process. Just like in Hibernate creating SessionFactory is costly but Session is something that you can create for every request.

So now the flow is once MBean is deployed it starts scanning for Rules file for URLs specified by user and if found it parses it and creates RuleBase and binds to JNDI using file name as jndi name.

Now when the RA and Sbb are deployed; when the Sbb makes first request to create RuleSession (Activity), RA will do the lookup of RuleBase (jndi name will be the file name) and create a WorkingMemory out of this RuleBase and pass it on to RuleSession. The flow continues.

Now if user makes any change to rules file scanned by Mbean it automatically creates a new RuleBase and rebinds to same jndiname. Mbean also exposes functionality where user can change the path where the rules files are kept (as far as file name doesn't change, RA will always find it in jndi lookup)

Bruno does this answer your question? How can we achieve this management capability if I add the Scanner directly to RA and not as MBean? The point is latter in time we can add more management attributes as what is the average time it takes to fire rules, min, max time. Which rule is used the most etc which I haven't thought of implementing as now but can be added as feature if need arises.

ivelin
Offline
Joined: 2003-07-13
Points: 0

Nice design, Amit.

I would only ask that we separate the Rules RA Type document and discussion from the Rules RA implementation.

On the Rules RA impl:
1) I assume the MBean is created dynamically by the RA Impl when an RA entity is activated. Is that so?
2) Does the MBean support decision tables hosted on arbitrary URL?

abhayani
Offline
Joined: 2005-04-04
Points: 0

>1) I assume the MBean is created dynamically by the RA Impl when an RA entity is activated. Is that so?
Actually speaking there are no dependencies between MBean and RA Impl. As soon as MBean is deployed it starts scaning the URL that user has entered in jboss-service.xml file. If user doesn't want to happen this statically even that is supported. To achieve this user will not have an entry for URLs attribute in jboss-service.xml. Now the MBean is deployed but is not doing anything as we haven't given it the URL to scan for. User makes use of addURL operation and adds the URL to scan. As soon as MBean finds one of the rules file (.xls, .cvs, .drl) it creates RuleBase and binds to JNDI.

>2) Does the MBean support decision tables hosted on arbitrary URL?
So the answer is yes. URL could be added dynamically to MBean by calling addURL operation that is exposed by MBean. URL could be a rules file hosted by server or rules file local to your machine.

ivelin
Offline
Joined: 2003-07-13
Points: 0

> >1) I assume the MBean is created dynamically by the
> RA Impl when an RA entity is activated. Is that so?
> Actually speaking there are no dependencies between
> MBean and RA Impl. As soon as MBean is deployed it
> starts scaning the URL that user has entered in
> jboss-service.xml file. If user doesn't want to
> happen this statically even that is supported. To
> achieve this user will not have an entry for URLs
> attribute in jboss-service.xml. Now the MBean is
> deployed but is not doing anything as we haven't
> given it the URL to scan for. User makes use of
> addURL operation and adds the URL to scan. As soon as
> MBean finds one of the rules file (.xls, .cvs, .drl)
> it creates RuleBase and binds to JNDI.

Why is jboss-service.xml needed. Shouldn't the MBean be part of the RA deployment process with default settings specified in the RA descriptor?

>
> >2) Does the MBean support decision tables hosted on
> arbitrary URL?
> So the answer is yes. URL could be added dynamically
> to MBean by calling addURL operation that is exposed
> by MBean. URL could be a rules file hosted by server
> or rules file local to your machine.

So the URL can point to a DRL file as well as a CSV or XSL file?

abhayani
Offline
Joined: 2005-04-04
Points: 0

>Why is jboss-service.xml needed. Shouldn't the MBean be part of the RA deployment process with default settings specified in the RA descriptor?

Thanks Ivelin, good idea. I will look at it.

>So the URL can point to a DRL file as well as a CSV or XSL file?
Yes

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

1) After looking at both, I'm not very convinced of much more functionality, regarding SLEE logic needs for rules, even if after a quick look, the lack of a rules language can "kill" a standard. Anyway, since session is very similar to working memory as an activity, we could implement 2 ra types: jrules and jsr94.

2) I'm not convinced of the need for the async model here, just like in the data ra, since 99,99% of the time, the one that sends the conditions is the one that wants the actions. For exceptions you can have a service enabler that fires a event. Also, just like a sbb should not "wait" it's thread, it's reasonable that the sbb shouldn't use actions that plays with threads, e.g. timers. I mean, actions that play with external resources, should do it the same way sbb does, using external resource adaptors or facilities. Makes sense?

Eduardo

Message was edited by: eduardomartins

abhayani
Offline
Joined: 2005-04-04
Points: 0

After carefully looking into JBoss Rules we have found that there is a way to Synchronously assert the fact and get the consequences at the same time using Globals. I have modified the AppSbb and RulesActivity such that as soon as you assert a fact, the same Sbb gets the consequences immediately and sbb can take further action based on the consequences.

I agree with you Eduardo that we have to keep the RAType generic enough that any Rules Engine implementing JSR94 can be used within RA hence I have modified the RulesActivity such that it has a method "public Hashtable executeRules(final List objects);" so any implementing code takes the List of object as Facts that it needs to assert and returns back the Hashtable which is consequences. We can debate on whether the return type is Hashtable or List but thats not very important.

Amit

brunoduarte
Offline
Joined: 2006-09-07
Points: 0

Another way to get JBoss Rules to synchronously assert the fact and get the consequences is using the implemented JSR94 API.

I can't think any situation were this api won't be enough in our context. In my opinion our apprehension with JSR94 should be at the rules engine level and not at the RAType level. In what limitations are you basing your decision?

Bruno

abhayani
Offline
Joined: 2005-04-04
Points: 0

Amit, I don't think 94 places any constraints on the format of the rule set file. It should be possible to specify the type of file (drl vs xls) by passing properties to the rule execution set provider when creating a set.
http://labs.jboss.com/file-access/default/members/jbossrules/freezone/do...

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

Is there any reason for not considering Java Rule Engine API (JSR 94) instead?

abhayani
Offline
Joined: 2005-04-04
Points: 0

JBoss Rules is JSR 94 compliant

eduardomartins
Offline
Joined: 2005-10-10
Points: 0

I mean the RA Impl and RA Type. I'm seeing people discussing details not JSR 94

ivelin
Offline
Joined: 2003-07-13
Points: 0
abhayani
Offline
Joined: 2005-04-04
Points: 0

Hi Guys,

I have checked in the first round of code in mobicents-examples/rules-ra and mobicents-examples/rules-sbb. There is quite some change in design compared to what we started with as explained bellow

1) AppSbb receives Invite as intial event.
2) AppSbb creates instance of CallFact which is populated with fromURI and toURL. This is the fact used for assertion.
3) AppSbb creates a new instance of RulesActivity using RulesResourceAdaptorSbbInterface
4) AppSbb attaches itself to the Rules ActivityContextInterface
5) AppSbb asserts CallFact on RulesActivity and last step is to call fireAllRules()

6) As initial design RulesResourceAdaptor is responsible for creating instance of WorkingMemory depending on the *.drl (MobicentsCallTest.xls) files passed.
7) RulesResourceAdaptor also creates instance of CallWorkingMemoryListener which is actually called by JBossRules asynchronously when ever Fact is asserted.
8) RA caches this WorkingMemory as its costly to create new instance of WM every time.

9) CallWorkingMemoryListener emitts FactAssertedEvent everytime Fact is asserted
10) AppSbb listens for this event and acts accordingly (onFactAsserted)

However there are few loopholes.
1) onFactAsserted is called for every fact that is asserted irrespective of which AppSbb has created this CallFact. Need to find someway to ignore the event if CallFact is not the same that AppSbb has created initially.

2) the .xls file needs to be in classpath for WorkingMemory to be created. There needs to be a better way of handling this such that drools file is continuously monitored and RulesRA should drop the instance of WorkingMemory if there is any change made in rules file (.xls, .cvs , .drl etc).

Guys please jump if you have any better ideas.

Thanks,
Amit.

ivelin
Offline
Joined: 2003-07-13
Points: 0

Good first round.

Some comments:

>8) RA caches this WorkingMemory as its costly to create new instance of WM every time.

What do you mean by that? An WM instance should be associated with an activity.

There should be a way for the SBB to request end of the activity explicitly similar to the interface for NullActivity. There should be probably an implicit way for the activity to end if there are no timer facility or SBB attached to it, again similar to the NullActivity semantics.

> However there are few loopholes.
1) onFactAsserted is called for every fact that is asserted irrespective of which AppSbb has created this CallFact. Need to find someway to ignore the event if CallFact is not the same that AppSbb has created initially.

Yes, it should be possible for SBBs to filter out their own assertions.

> 2) the .xls file needs to be in classpath for WorkingMemory to be created. There needs to be a better way of handling this such that drools file is continuously monitored and RulesRA should drop the instance of WorkingMemory if there is any change made in rules file (.xls, .cvs , .drl etc).

Right. DRL or XSL decision table files should not have to be required on the classpath.

abhayani
Offline
Joined: 2005-04-04
Points: 0

In Response to brunoduarte
Thanks Bruno for your interest. Here is the idea that I have in my mind let us discuss if we can improve on this.

>Why do you need a Rules RA if you only want to compile DRL files and get the working memory (5/6 lines of code)?
Well the idea is to have a RulesRA that can take any .drl files and give the further course of action depending on business rules ( drl ) that you pass to RA. CallBlocking, Forwarding is good example but can be used for other use case too. May be billing?

>How can you have a cache of working memory without being aware of the changes in DRL files (you need to process the file)?
Something that we need to implement. Do you have any idea on how we can achieve this?

>Last but more important, why don’t you want the RA to be aware of the facts?
Well keep Facts very generic so that other application like Billing can make use of same RulesRA. May be a Fact is generic java class with a Map and a String. String is used for assertion rule while Map will be used to store the consequences. This will evolve as we progress but the idea is to keep the RulesRA generic.

brunoduarte
Offline
Joined: 2006-09-07
Points: 0

>>How can you have a cache of working memory without being aware of the changes in DRL files (you need to process the file)?
>Something that we need to implement. Do you have any idea on how we can achieve this?
Not really an idea but it seems that you need an specific service to manage a cache system (eg, jboss cache)? Independent of the Rules Engine!

> >Last but more important, why don’t you want the RA
> to be aware of the facts?
> Well keep Facts very generic so that other
> application like Billing can make use of same
> RulesRA. May be a Fact is generic java class with a
> Map and a String. String is used for assertion rule
> while Map will be used to store the consequences.
> This will evolve as we progress but the idea is to
> keep the RulesRA generic.
It seems I misunderstood that. You don't want the RA to be aware of the facts itself but the type of facts. As you mentioned, this is easy to solve if you represent the facts in a generic way (eg, list of strings).

Let me introduce another variable to the discussion. Why do you need an asymmetric behavior?

Bruno

abhayani
Offline
Joined: 2005-04-04
Points: 0

>Let me introduce another variable to the discussion. Why do you need an asymmetric behavior?

Sorry I didnt understood. What do you mean by asymmetric behavior?

brunoduarte
Offline
Joined: 2006-09-07
Points: 0

Oops.. It's a bug!
You should read 'asynchronous' instead.

Bruno

ivelin
Offline
Joined: 2003-07-13
Points: 0

because the underlying JBoss Rules API is asynchronous in nature. Multiple facts can be asserted as a result of introducing an external fact to the working memory. Not only that but also some facts can be consequence of a time based condition.

How do you imagine these cases working in a synchronous way?

abhayani
Offline
Joined: 2005-04-04
Points: 0

Some more progress on design front.

The first four points listed on forum http://forums.java.net/jive/thread.jspa?threadID=24927&tstart=0 are still valid.

For every Activity that RulesRA creates, RulesRA also creates instance of WorkingMemoryEventListener and registers to itself. As soon as the Fact is asserted by SBB, the WorkingMemoryEventListener creates a corresponding event and fires on this AC. The SBB listens to this event and the asserted Object has the information of further action like Block, Forward or VoiceMail. The idea is to keep the Fact a very generic object that RulesRA can take which is not at all dependent on Rules API as wew want to keep the RulesRA generic.

Amit.