Vidhita Business Rules Composer (VBRC) is a software for creating, managing, and executing business rules. It consists of a business rules engine and an editor environment. The business rules are declarative and in if-then-else form. VBRC is available as an enterprise or desktop edition. It provides a graphical editor and runtime environment to work with business rules and Java objects.

1. All materials present in this document are the property of Omprovise Software
India Pvt Ltd and publishing of the content without prior approval is
prohibited where applicable

2.  Vidhita Business Rules Composer VBRC is a
software for creating, managing and executing
business rules
 VBRC consists of the following components:
 A Business Rules Engine BRE
 An editor environment for creating and managing rules
 The business rules are declarative rules and are of
the if-then-else form
 VBRC is available in the following editions:
 Enterprise
 Desktop

3.  Business Rules Management System BRMS is
typically used in the financial services industry
by banks and by insurance companies.
 VIDHITA BRMS is designed to run declarative
rules of the if-then-else format
 Vidhita also has a built-in forward chaining
rule engine that supports Rete algorithm for
more complex rules used for problem solving
such as route planning, solving sudoku etc

4.  Vidhita BRE supports plain english rules.
Unlike other rule engines that claim to have
plain english rules, Vidhita rules are 100%
plain english
 E.g
if car.price<20000 and not
contains[HighTheftProbabilityAutoLi
st,car.type] then
potentialTheftRating[car,"low"]

5.  Vidhita uses JavaBeans aka Plain old java
Objects (POJOs) as its domain object model
 Pojos model the real world accurately and are
easily understood by business users
 Examples of Pojos include
 Customer
 Account
 Policy
 Vehicle
etc

6.  Vidhita uses a familiar workflow approach to
the rules compilation and execution.
 The workflow consists of 3 steps
 Generate Interface
 Generate client
 Generate Factstore
 Run Client
 Of these the first 3 are 1-time tasks after which
the runclient task can be run as many times as
needed until the underlying rules change

7.  Compiled rules run faster than interpreted
rules
 This is because the rules are compiled to a
binary format which can then be easily
executed
 Vidhita Rules are compiled into Java class files
and hence run much faster than interpreted
rules

8.  Business Rules by their nature tend to change
very often
 The BRE must be capable of refreshing the
changes made to the rules dynamically
 Vidhita supports the dynamic refresh of the
changed rules class files using dynamic loading
techniques

9.  Vidhita Business Rules Composer VBRC is a
web based application written using Java/J2EE
 VBRC is a Ajax Rich Internet application RIA
developed using the Echo2 web application
framework from Nextapp.com
 VBRC takes the power of the business rule
engine and makes it available as a user-friendly
web based Ajax application

10.  Vidhita BRE has been successfully field tested as it
was part of the “Userv product derby 2005”
 The rules engine used by Vidhita is based on the
popular open source rule engine “Take” developed
by Dr.Jens Dietrich in Massey University, NZ
 Take has been under development for over 10 years
 Take is very mature, feature-rich, and open source
to meet the rigors of the enterprise environment

11.  VIDHITA supports using bindings and
factstores in rules.
 Bindings are used for supplying inline facts
and constants to the BRE
 Factstores provide database integration and
Enterprise edition of VIDHITA makes use of
object-relational mapping ORM in its factstore
implementation.
 Vidhita’s rules can be exposed as web services
and then made interoperable with other
platforms like .NET, mainframe etc

12.  Dynamic refresh of rules classes
 RDBMS support for factstores using ORM
 Built-in JavaBeans Editor
 Hibernate mapping file generation
 Batch mode operation
 Audit trail & reporting
 Access control and security
 Reporting and analytics
 Internationalization
And many others

13.  Vidhita supports 2 kinds of projects:
 Simple – In this type of project, facts are supplied
inline or fed in at the time of rule querying.
 Factstore – In this type of project,
 the facts are loaded from the database
 Draw inferences from the rules
 E.g isStudentOf(“Alexander”, “Aristotle”)
and isStudentOf(“Aristotle”, “Plato”) then
isStudentOf(“Alexander”, “Plato”)
 Bidirectional rules
 getTutors(“Alexander”)
 getStudents(“Plato”)

14.  The Vidhita Business Rules Composer consists
of 2 main components
 The DashBoard
 The dashboard is where the user organizes his rules
projects, associated java beans, factstores etc and also
performs the workflow opearations. Once the
workflow step is complete the rules are ready to be
loaded into the runtime
 Runtime
 The runtime is where the user executes the queries
and views the results

16.  Vidhita BRMS is extremely powerful and allows
adding new projects and addng domain object
javabeans to the project at any time
 A Beans Editor is provided to allow entering the
bean specification as XML file and then
generating the bean source and class files.
 The bean xml file can contain multiple beans
 Beans entered later in the file can depend on
those appearing earlier
 Bean field types can be user friendly names like
number, real, decimal, char, string etc

18.  The beans editor contains the facility to add a
code property
 A code property allows user to enter arbitrary
java code in a bean method
 This would allows users familiar with the java
language to perform complex operations that
would otherwise not be possible using the
getter/setter methods of javabeans
 The result of the generation is displayed in a
pane below with detailed line numbers,
description and status of compilation etc.

19.  The List Editor allows users to input a list of
values from which a java source file is created
which is then compiled to a class file
 The List class is then available for use inside
the rules
 E.g
 Import scenario8.MajorAilmentList
 ref java.util.Collection
MajorAilmentList
 If MajorAilmentList.contains[ailment]
then AutoEliginility[person, ailment,
“not eligible”]

20.  Vidhita supports 2 modes where rules can be
added to a project
 Rule upload
 Rule Editor
 The Rules Editor is a graphical editor where
user can edit various rule file details such as
 Rules Header
 Rules Class Details
 Rules Body
 Aggregations

22.  The header is the top portion that lies above the
rules body
 This section is similar to web mail where user
can do the following
 Set the Id generation strategy
 Set the Id mask
 Paginate the rules
 Insert rows 1, 2, 3 or 5 rows
 Set fullscreen mode

23.  The rules header is also where the user declares
imports, variables and bindings
 There is also provision to enter comments ,
annotations in the header
 E.g
 // script for test scenario 8
 @@dc:creator=jens dietrich
 @@dc:date=05/06/2007
 var scenario8.Person
person1,person2,person3
 var scenario8.Person
grandchild,father,grandfather

24.  This tab in the editor is where the user enters
class names, method and query names, slot
names etc.
 The screen is designed to allow adding and
removing classes to the rules, adding methods
to the class and specifying the params and their
directionality
 A preview of the class tree structure is
simultaneously available in a separate pane
 For factstore projects, it is possible to select if
the method is bidirectional

26.  The body editor is a grid like editor containing
rows where user enters the rule text
 Each row consists of 4 lines. The lines are:
 Comment
 Category
 Description
 Rule Text
 The category is the ruleset category which
allows the user to organize rules into rulesets

27.  The rules text itself is composed of 2 elements
 The ruleId
 The ruleText
 The ruleId is a unique Id generated for each
rule based on the Id generation strategy and
mask selected by the user
 The ruleText contains the rule
 The ruleText textfield provides content assist
feature when user enter a javabean class name
and presses the dot . Character

28.  The body editor tab features the following
buttons:
 Save
 This button allows user to save unfinished work and
return to complete editing the rules
 Save Validate
 This button validates the rules before saving
 Validate
 This button only validates and does not save
 Preview
 This button allows the user to preview the rules

29.  The summary section allows the user to review
the information entered in the other tabs
 The summary section has following buttons
 View Aggregation
 View Class Details
 View Header
 View Body
 View All

31.  Vidhita business rules composer organizes its
data in projects
 Each project can be either simple or factstore
 Each project can have multiple rule files only one
of which can be active at any time
 The rules manager allows to view the project rule
files, create method (edit/upload), date created,
active/inactive status, valid/not valid status etc
 Further, user can view, edit, delete or download
the rule file

33.  Bindings specified in rules can be edited using
Bindings editor
 Any element with a ref before it is treated as a
binding
 Bindings are like javabean fields except there
isn’t a javabean to wrap the fields
 Each field is independent and has its own type
and name
 A mechanism to configure editors for bindings
is provided similar to javabeans

35.  A binding can have a type which is a user
defined type or javabean
 E..g ref Branch br (where Branch = Java Bean)
 The bindings editor configuration allows user to
specify a UDT editor as the editor of the UDT
 The bindings editor then allows the user to edit
the binding using the UDT editor
 The value entered is a java object which is
serialized and stored for later use at runtime

36.  Vidhita provides a general purpose file upload
component that can be used to upload txt files,
rules files, xml files, jar files etc
 Each upload can be configured with a filter that
only allows files of certain file types to be
uploaded
 Uploads are stored in a user specified directory
 If the directory is added to the filesystem
classloader search path, then the directory
contents are also available to the application
immediately

38.  Vidhita features a batch uploader that allows to
upload .zip, .jar files etc
 The classes in the archive are automatically
extracted and copied to upload location
 Options are available to control extraction like:
 Skip/copy class files
 Compile/skip/copy java files
 Skip/copy other files
 Verbose mode
 Async copy etc

39.  Vidhita provides a mechanism to configure
editors for individual javabean fields
 The user selects an editor from a list of available
editors depending on the type of the javabean
field
 Common editors include IntegerEditor,
DoubleEditor, StringEditor, BooleanEditor etc
 Specialized editors such as combobox editor,
Spinner Editor, Color Editor,
DateChooserEditor are also available

41.  Available Editors
 BooleanPropertyEditor
 BooleanAsCheckBoxPropertyEditor
 StringPropertyEditor
 DoublePropertyEditor
 FloatPropertyEditor
 IntegerPropertyEditor
 LongPropertyEditor
 ShortPropertyEditor
 ColorPropertyEditor
 DateChooserDatePropertyEditor
 SpinnerPropertyEditor
 ComboBoxPropertyEditor
 UDTPropertyEditor

42.  The Beans layout screen is one of the most
complex screens in the entire application
 The screen consists of 5 panes:
 Bean selection Pane
 Editor Selection Pane
 Editor Property Pane
 Property Sheet pane
 Assigned Mappings Pane

43.  The beans layout editor also allows to set the
layout style for a bean, whether it is 1-column,
2-column, 3-column or custom layout
 Custom layout is available to plugin layouts
created using visual designers
 For Bean properties that are themselves beans, a
UDTPropertyEditor is provided
 The ComboBox property editor allows to set a
bean field value to be set from a predefined set
of values

44.  Vidhita features a very powerful rule execution
runtime environment
 Active project and rulefile selection
 Layout selection
 View selection viz dynamic view, wizard view
 Mode selection e.g whether run rules on tab out,
user initiated
 Rules history viewing
 Rules derivation log viewing
 And many others

45.  The runtime screens display javabeans as GUI
elements like textfields, combobox etc
 Vidhita runtime provides automatic generation
of screens from javabeans
 Optionally editors can be configured for each
javabean attribute
 The runtime then fetches the stored editor
configuration and displays the screen
 Similarly, the layout configuration specifies if the
UI should be laid out in 1,2-3 column or custom
layout.

46.  The dynamic view is a very powerful feature that
allows you to run the rules and see the results in
real-time
 This view allows you to change a parameter on
the screen and immediately see its effect on the
result in the result pane
 The result pane configurations allows you to
layout the screen in tabs and target queries to
individual tabs
 It is possible to select whether rules should be
executed for each screen element on tab out or
finally when user presses run

48.  This view allows user to execute the rules
using a wizard navigation paradigm
 Wizards typically collect all the necessary data
in a progression of screens before finally
performing some action
 The wizard view allows the user to select the
rule to be executed
 The Wizard view then allows the user to input
data one screen at a time where each screen
contains the fields for a single javabean

50.  Some rules use javabeans that contain other
javabeans
 The runtime detects such javabeans and draws
the nested bean in a separate box at runtime
using any configured editors
 The values provided by the user for the nested
bean are automatically copied to the parent
bean before the rules are executed
 This nesting can be any for any number of levels

51.  In Take, the BRE engine for Vidhita, only an
interface is generated for the factstore and it is the
programmers responsibility to provide an
implementation class for this interface.
 Vidhita however provides an editor to
create/edit the factstore template, the output of
which is a template for a class that implements
the factstore interface
 The editor provides a number of features that
hides the underlying complexity of creating the
class

52.  Creating the factstore template class is a 1-time
only task
 The template editor provides guard regions for
readonly code
 The editor provides macros for prdefined
constructs like set, foreach, if-else etc
 The editor allows plugging in various
persistent systems like RDBMS, LDAP, XML
Files and even external web services

53.  Hibernate ORM is a natural fit for the factstore
implementation due to the following:
 Multiple Query constructs e.g sql, hql, criteria
 Table-Entity binding for sql and hql
 Lazyloading allows a graph of objects to be retrieved at
once e.g student.getCourses()
 Pre-fetch queries speed up performance
 Table joins return object [] containing entity for each
table in the join
 Supports many different join types like 1-to-many,
many-to-many, 1-to-1, many-to-1 etc and many
different container semantics like box, list, map, array,
set etc

54.  The factstore editor allows previewing the
generated template and also test the factstore
class generation from the template
 The factstore editor provides content assist by
enabling/disabling insertable items depending
on context
 The factstore editor provides JavaDoc API
documentation for Hibernate functions like
Session, Query etc

55.  Vidhita allows user to configure the result pane
for better viewing of runtime results
 Configuration is possible for simple and
factstore projects and for dynamic and wizard
views
 For dynamic projects, result is displayed in tabs
for input and output
 Input tabs are arranged per bean
 Output tabs are assigned labels by the user
 Results for queries can be targeted to
corresponding tabs based on user configuration

57.  Results are displayed in single-line textfield or
multi-line list view
 A Multi-text view is available for displaying
results for all queries in the same field
 Aggregation functions like sum, count, min,
max and avg can be attached to Mult-line list
view to aggregate the results
 Traceability is possible through a ‘show rules’
button which displays the derivation log

58.  Table like layout is possible for factstore project
 Since all input and output to queries are java
beans, the result contains an input and output
column
 Input column displays the java bean input
 Output column displays the result bean
 Table columns correspond to JavaBean fields
 Factstore results can contain 1000s (millions) of
records , so the result displayed in tables is
paginated for easier viewing

59.  Vidhita rules can reference Java methods as
functions and predicates
 E.g rule1: if sameAs[person1.father,
 person2.father] then isBrother[person1,person2]
 Allows use of bean properties as predicates
 E.g rule1: if courses[student,course] and
college[course,college] then
isEnrolled[student,college]

60.  Vidhita RIA Ajax Framework allows executing
long running tasks asynchronously
 This feature is used in the workflow steps to
asynchronously execute the generateinterface,
generateclient, generatefactstore tasks
 The webapplication displays a progress
indicator for the duration of the processing
 This Async Execution is also used to play
animations etc to display status messages to the
user

61.  Supports aggregations in rules
 aggregation totalriskpremium = sum x
riskpremium[loan,x]
aggregation minriskpremium = min x
riskpremium[loan,x]
aggregation maxriskpremium = max x
riskpremium[loan,x]
// rules
rule1: if loan.clientRisk>7 then
riskpremium[loan,100]
rule2: if loan.countryRisk>6 then
riskpremium[loan,50]
rule3: if loan.currencyRisk>8 then
riskpremium[loan,75]

62.  Negation in rules
 rule1: if not isFlightless[bird] then
canFly[bird]
 rule2: if bird.kind=='kiwi' then
isFlightless[bird]
 Implicit default case detection
 E.g rule1: if bean.ranking==42 then
hasCategory[bean,'high']
rule2: hasCategory[bean,'normal']
The above states that if category is not high,
then category is ‘normal’

63.  JavaBean composition. A javabean can nest
other javabeans
 E.g var eurent.RentalCar car
 rule1: if storedAt[car,branch] and not
isScheduledForService[car] and not
assignedTo[car,rental] then
availableAt[car,branch]
 Here RentalCar is a special type of car that
contains the Branch and Rental beans.

64.  Allows calling external web services from
inside rules
 E.g
 AE-PC01: if
hasBeenConvictedUnderDui[driver]
then policyEligibilityScore[driver,
“500”]
 Here, hasBeenConvictedUnderDui can make a
web service call to the local police web service
to fetch the driver’s records if any

65.  Rules files are repositories of Knowledge aka
knowledgebases
 Take BRE supports a pluggable approach to
loading and parsing knowledgebases
 A ScriptKnowledgeSource wrapper class
allows loading of Take scripts from streams,
readers, URL, WebDav and other sources
 Adapters are also available to load rules in
R2ML format for RuleML support

66.  DE_DAC02: if not driver.isMale and
driver.age<20
then driverCategory[driver,"young driver"]
DE_DAC03: if driverCategory[driver,"young
driver"]
and hasTrainingCertification[driver] then
isEligible[driver]

67.  Webapplications typically are only able to
access resources under the web application
context directory
 Vidhita BRE features a Custom classloader that
allows the application to load classes and
resources from anywhere in the filesystem
 This would be helpful in clustering where
resources need to be shared across nodes in the
cluster

68.  BRE are generally used along with the Imaging
and workflow applications
 Vidhita BRE exposes its rules as webservices
that can be invoked from other applications
 Vidhita webservices are built using the latest
webservices standards including WSDL 2.0,
SOAP, WS-Security, SAAJ etc.
 Vidhita webservices provide interoperability of
the rule engine with other platforms like .NET,
Mainframe etc.

69.  Vidhita RIA Ajax framework makes extensive
use of hibernate object-relational mapping
framework
 Hibernate is the most powerful, open-source
ORM software available in the market
 Hibernate supports automatic binding of
database tables to javabeans which is used in
Vidhita factstore projects
 The lazyloading feature of Hibernate along with
pre-fetch queries is used to retrieve graphs of
objects from the database at once

70.  Vidhita provides the following ORM related tools
for generating mapping files
 Hibernate requires that for each bean there exist a
mapping file before the object relational mapping
can happen
 DDL2HBM – This tool directly generates mapping file
from database schema
 HBM2JAVA – This tools reads HBM files and generates
Java Bean Source files
 Class2HBM – This tool reads Java class files and
generates the mapping file

71.  Spring framework is the defacto IoC container
for dependency injection
 Vidhita integrates with Spring framework to
inject javabeans into the application
 The beans specified in spring-context.xml are
autmatically loaded and available to the
application at startup

72.  Vidhita Business Rules Composer uses the JDK
1.6 ServiceLoader mechanism to locate and run
rules projects
 The client class implements a ClientService
interface and the implementation class is
specified via a file in the Meta-Inf/services
directory
 The runtime then searches the entries in the file
to locate the client to execute

73.  Vidhita Business Rules Composer provides a
comprehensive security framework with
facilities such as
 Authentication
 Authorization
 Single-sign-on etc
 The security framework is based on spring-
security formerly known as Acegi security and
is also the most popular framework for
securing j2ee applications

74.  Vidhita business rules composer provides
adapters for integrating with the popular open
source Rule Engine ‘Drools’ from Jboss.com
 Drools adds support for ‘Rete’ which is useful
for creating problem solving rules such as
route planning, solving sudoku etc
 Vidhita’s support for if-then-else rules
combined with rete support from Drools would
result in a powerful framework capable of
competing with the best of breed rule engines

75.  Add RuleML support via R2ML
 XML based rule exchange language
 Unifies features from different languages,
including:
 SWRL (OWL extension)
 RuleML (Prolog style markup)
 OCL (UML extension)

76.  The Take rule engine that Vidhita uses was
part of the user product derby conducted by
businessrulesforum.com in 2005
 The UServ business rules are expressed in
natural English, and provide a scenario which
emulates a complete vehicle insurance service.
 Its purpose is to compute the annual premium
for a vehicle insurance policy, which belongs to
an eligible customer.

77.  UServ divides its business rules into business
rules sets, each of them addressing different
goals and contexts
 calculates the eligibility scores in order to set
the eligibility status for a client/driver/car,
pricing and cancellation policies at client
portfolio level.

78.  UServ Product Derby provide a concrete business
rules sets separation on distinct categories of rules
such as:
 Automobile Eligibility - establishes the eligibility
category for a car.
 Driver Eligibility - obtain the eligibility category
for a driver.
 Eligibility Scoring - determines the client's
eligibility category based on a scoring system, by
testing the risk ratings for: driver, car and client
categories. If the client is eligible for vehicle
insurance, then the annual premium is calculated.

79.  Automobile Premiums - calculates the car premium,
based on model year, fabrication year, medical or
uninsured motorist coverage.
 Driver Premiums - calculates the premium for
particular driver.
 Automobile Discounts - lowers the car premium
with specific percents, if the car has or not airbags or
alarm system.
 Market Discounts - lowers the total premium (sum
of car premium and driver premium) based on
customer segmentation (elite or preferred).

80. userv.take

81.  Smooth integration of derivation rules into
Java.
 Generation of very scalable code.
 Analysis of rules used to answer queries (white
box computation)
 Possible separation of specification (interfaces)
and implementation (classes) of knowledge
bases.

82.  External fact stores are used to reference facts stored in systems
such as (relational) databases, XML files or stored on remote
systems and accessed via web services, CORBA or similar
technologies.
 These facts are not stored in the knowledge base, but only
referenced. An external fact store has to provide an iterator over
these facts.
 E.g rule1: if is_father_of[grandchild,father] and
is_father_of[father,grandfather] then
is_grandfather_of[grandchild,grandfather]
 external facts1: is_father_of[scenario8.Person, scenario8.Person]

83.  Global annotations are lines starting with "@@".
Using global annotations is recommended for
global meta data such as info about the creator,
the version, the date of the last modification
etc. It is recommended to use standard meta
data vocabularies such as DublinCore for this
purpose.
 E.g @@dc:creator=Jens Dietrich
@@dc:date=2007-09-12
@@special=true

84.  Local annotations are lines starting with a single "@". They
are annotations for the next significant line of execution
 e.g // Auto Eligibility Rule Set
@category=Auto Eligibility Rule Set
@description=If the car is a convertible,
then the car's potential theft rating is
high.
AE_PTC01: if car.isConvertible then
potentialTheftRating[car,"high"]
 @take.compilerhint.class=PotentialTheftRatin
g
@take.compilerhint.slots=car,rating
@take.compilerhint.method=getPotenialTheftRa
ting
query potentialTheftRating[in,out]

85.  E.g
 rule2: if is_student_of[disciple,
teacher] and is_disciple_of[teacher,
grandteacher] then
is_grandteacher_of[disciple,
grandteacher]
fact1:
is_student_of[“Alexander",“Aristotle"
]
fact2: is_student_of[" Aristotle ",
“Plato"]

86.  TAKE BRE uses a new scripting framework,
that integrates better with Java syntax
 Uses the JSP expression language and an
existing JSP-EL (JSR245 ) parser, JUEL
 JUEL is considered production stable. The code
is well tested and feature complete.
 JUEL is the basis for using functions and
variables, parsing and evaluation, value and
method expressions, tree expressions and
elegant syntax of the rules in Take BRE

87.  Predicates are associations between terms.
 Take supports directly
 Java built-in predicates representing operators
comparing numerical primitives
 methods returning booleans
 Java beans properties
 predicates are used in rule heads (then
conditions), facts, external fact sets and queries.
 E,g rule1: if courses [student,course] and
college[course,college] then
isEnrolled[student,college]

88.  Take queries can be bidirectional
 @take.compilerhint.class=IsFatherOf
 @take.compilerhint.slots=son,father
 @take.compilerhint.method=getFather
 query is_father_of[in,out]
 @take.compilerhint.method=getSons
 query is_father_of[out,in]
 Note the reversal of slot direction
in the 2nd
query from in,out to
out,in

89.  The rules are entered as plain text
 However, the Vidhita runtime converts the
rules text into java source files which are then
compiled on-the-fly in to java class files
 The class files are then loaded into memory so
the rules can be executed
 The workflow steps such as generateinterface,
generateclient and runclient all make use of the
java compiler API to compile java files

90. The Vidhita Business Rules Composer allows
traceability by allowing to view the rules that
were fired and to determine which result is in
response to which set of rules getting fired.

91.  Since the generated code is difficult to debug,
there is a DerivationController class containing
the method log(String id, int kind, Object...
param).
 The id is the identifier of the knowledge
element
 the kind argument is a constant defining
whether the knowledge element used is a fact,
derivation rule etc

92.  The following checks are available:
 CheckPredicatesInQueries
 Check whether the predicate used in queries is
supported by facts, rules and external fact sets
in the knowledge base
 CheckVariablesInQueries
 Check whether variables in rule heads also
occur in the bodies of the respective rules

93.  Dynamic refresh of changed rules classes is
facilitated by 2 means
 Direct byte-code replacement
 This technique requires use of the third-party
software JRebel from zeroturnaround.com
 OSGi Framework
 This requires that the application be packaged as a
OSGi compatible war file and deployed in a OSGi
container such as Equinox or Felix. It is then possible
to use either the FileInstall bundle or the
PackageAdmin.refreshPackages call directly to
refresh loaded OSGi bundles

94.  Vidhita Business rules composer supplies OSGi
versions of its software compatible with both
Equinox and Felix OSGi containers
 The Equinox version uses SPRING DYNAMIC
MODULES FOR OSGI(tm) SERVICE
PLATFORMS
 The FileInstall bundle runs on both Equinox
and Felix containers
 It should be noted that the filesystem
classloader will no longer be available with
OSGi since OSGi only sees bundles registered