[Design of JBoss jBPM] - Re: jbpm drools integration meeting
by tom.baeyens＠jboss.com
"kukeltje" wrote :
| Some things I read above:
| 1:
|
| anonymous wrote : This scenario allows for rule bases to be deployed and managed separately from processes but in the same repository. andanonymous wrote : A special simplified use case is when a process archive contains a set of rules in source format.sounds contradictory, do I miss something?
|
The jbpm deployment can detect that there are rule sources in the process archive. Then at deployment, it can compile all the rule files into a rulebase and deploy that to the rule repository with a link to the process definition.
"kukeltje" wrote :
| anonymous wrote : In a process you can then say 'fireAllRules' without specifying a specific rule base. All rules specific to that process right? or also global rules? Making processes dependend on global rules in not neccesarilly a problem, but keeping referential integrity is.
|
The process local rule base would only be to create a simple environment where process and its rules appear as one logical entity. Apart from that, we also must support global rule bases. But in that case, the process developer must always specify the name of the rule base in the process and manage the rule deployment separately. The process local rules are a simplified scenario in case the developer considers the process and rules as one logical entity.
"kukeltje" wrote :
| 2:
| I cannot grasp the first part of this paragraph which might be the reason for the next questions
|
| anonymous wrote : In a subsequent process operation, you might want to fire all rules again. Currently, that would require that all the process variables will have to be fed in again.I do not think this is unwanted behaviour since the chances are big they have changed
|
They need to be re-installed in the rule base because they might have changed indeed. But they should not be re asserted, as that might fire rules and causes consequences (right hand sides) to be executed and that might cause side effects since these already have been executed. The idea is that the working memory should behave as if it is restored transparantly after the previous use. One way would be to serialize it in a process variable, but that would create duplicates of the process variable facts. Only the agenda-part of the working memory should be serialized and the facts should be re-installed without being asserted as that might mess up the agenda.
"kukeltje" wrote :
| anonymous wrote : By default, jBPM will fire all rules when a process variable is updated.I hope you mean after all process variables in a transaction are updated. I do not (never?) want rules to go of after one update if I update several variables in e.g. a task
|
probably it doesn't make sense to fire the rules after each update, but only when a process is saved. every process variable update should then be marked with a flag that triggers the rule firing... i am still in doubt and didn't think this through yet.
i'll respond to the rest later as my 30' internet connection is almost consumed :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964129#3964129
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964129
19 years, 8 months
[Design of JBoss Wiki] - Need Help installing JBoss Wiki on Windows operating system
by mtlforlife
Hello, I'm trying to get some help running the JBoss Wiki on a Windows box (Windows 2000 Professional, Windows XP or Windows Server 2003) and I haven't been able to so far. The current forum postings haven't been able to help me identify/fix what the problem is.
I tried to install with:
* JBoss Wiki Source Version Beta2 (Compiled with Maven 1.0.2 but I had to create a lib folder in the wiki directory for it to complete, the Maven messages requested this after executing the 'maven all' command)
* JBoss Application Server 4.0.4.GA
* JBoss Portal Binary Version 2.4.0-CR2
* JBoss EJB3 RC8-FD (Found and included 3 missing jar files)
When I deploy the wiki.ear file in the '..\server\all\deploy' directory, the JBoss app server returns a failed deployment message in the server.log file, as expected the Wiki does not resolve or show as a portlet in Portal. Same again when I tried using an expanded/exploded version of the wiki.ear.
Can anyone help me, something I?m doing wrong? Settings in configuration files I need make specific to windows? Packaging with Maven?
Thank you
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964124#3964124
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964124
19 years, 8 months
[Design the new POJO MicroContainer] - Re: Pushing beans into the kernel
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote : So the problem is that the KernelController knows nothing about the server. I did get past this doing:
|
|
| | // Register the Server instance in the kernel
| | Kernel kernel = getKernel();
| | KernelController controller = kernel.getController();
| | KernelRegistry registry = kernel.getRegistry();
| | KernelConfigurator config = kernel.getConfigurator();
| | BeanInfo info = config.getBeanInfo(server.getClass());;
| | AbstractBeanMetaData metaData = new AbstractBeanMetaData("org.jboss.system.server.Server", null);
| | AbstractKernelControllerContext serverEntry = new AbstractKernelControllerContext(info, metaData, server);
| | controller.install(serverEntry);
| |
|
| At first this failed because the server instance was being restarted by the kernel while it was already in start due to the ServerLoader calling start. I just worked around this for now by checking for a duplicate call. I need to figure out how to install a bean that is already started.
|
There currently is no way to do this.
Don't get hung up on the kernel controller.install(BeanMetaData)
this is just a convenience over the
controller.install(ControllerContext)
What you need to do is create an AbstractKernelControllerContext
that has a minimal set of actions
e.g. add
| /** The no actions */
| private static final KernelControllerContextActions noActions = KernelControllerContextActions.getNoActions();
|
| /**
| * Create an abstract controller context
| * with no actions and no meta data
| *
| * @name the name of the bean
| * @param target the target object
| */
| public AbstractKernelControllerContext(Object name, Object target)
| {
| super(name, noActions, new AbstractDependencyInfo(), target);
| if (System.getSecurityManager() != null)
| accessContext = AccessController.getContext();
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964123#3964123
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964123
19 years, 8 months
[Design of JBoss jBPM] - Re: jbpm drools integration meeting
by tom.baeyens＠jboss.com
Hi Jeff,
"Jeff" wrote : | 1) Task Assignment.
|
For calculating the actual actorId (user or group) that is responsible for a certain task, i think that rules are not really suited. Jeff, you obviously have more real life experience so i would appreciate your comment on this. One of the big problems i see is that with rules you're not sure if you'll find 0, 1 or more solutions.
But i DO think that rules are suited to calculate all the constraints that people have to satisfy in order to apply for a certain task. So the rule base could calculate those constraints after the rules have fired, a plain hibernate query could be build from those results. Would that approach make sense ? Another advantage would be that we don't have to assert the whole identity store into the working memory. The datamodel of the idenity store might have to have a generic way of managing properies for people so that the rules can produce plain (hibernate?) criteria that express the constraints.
"Jeff" wrote : | Perhaps some kind of
| | partitionable / composite working memory is required.
|
I think that would make sense. But mark and michael will know better then me.
"Jeff" wrote : | 2) Actions / Nodes. This involves invoking rules as at a node
| | in a process, either from an action configured on the node
| | itself or associated with some node event.
|
Maybe the rules only need to be fired when the process data (== facts) change. So i think i should add a variable-update event or something like that. So that the rules can be fired after each variable update. I'm still in doubt wether explicit rules invocations on a specific location in the process make sense.
"Jeff" wrote : | communicate the results of the rule execution. I.e., the
| | right hand side would invoke
| | contextInstance.setVariable("resultsOfRuleExecution", "some result").
|
Another option could be that after a rules calculation, certain facts could be fetched from the working memory and submitted into the process variables. The variable names could be part of the action handler configuration. But probably this is not possible because the working memory doesn't yet have named facts, right ?
So how do we collect the new data that is generated by the rules ? Should the rules themselves distinct between an assert and a setVariable on the process ? Defining contextInstance as a global variable seems the best approach to me. But it would be great if the facts were named, rules only contain asserts and jbpm was able to collect all new asserted information in the process variables transparantly.
"Jeff" wrote : | As noted above, Customers expect to be able to make minor
| | changes to their rules within the context of an executing
| | business process.
|
Maybe my next answer is not quite in the context of your point, but it relates to this and i have been thinking about this after our london meeting.
In my opinion, rules sources, process sources are on the same level as java sources. They're best managed in a source control system like CVS or SVN. The fact that projections of rules and processes can be presented in pictures that make sense for non-tech business people does not change this. We should be careful in our admin consoles not to include process and rule updates that are not synched with the source code just for the sake of the business user. We can only do that if there is a clear strategy on how the sources will be kept in sync. This is important cause i do NOT think that in general, rules and processes are stand-alone things that can be managed by non-techies. While the graphical projection of processes and rules make sense, both processes and rules will most likely include technical details. So processes and rules cannot live in isolation, but they will be integrated in plain java development. Therefor, they cannot be managed by business users alone and it is important that we still keep an eye on the development environment. We should prevent that a developer has to change some code in CVS and then update the rule DB and then update the process DB to start testing. This creates a very difficult deployment structure. Similarly, we have to prevent that the admin console allows for updates in the deployment that have to be synched back with the development sources.
I just want to warn that by focussing too much on the business user, we might introduce a complex sourcecontrol, build and deployment for the development team.
This does not mean that business users can't have what they want. They still can have their GUI editing of processes and rules, but it should be in sync with the technical development source code control system.
"Jeff" wrote : | 3) Decision Nodes.
|
Even if in natural english it makes sense that 'a decision is based on rules', I'm not sure if a rule engine is the proper instrument to calculate a decision-node in a jpdl process. Again as with task assignment, you're not sure if there will be 0, 1 or more results coming out of the rule engine calculation. The decision node needs exactly *1* result: namely the name of the transition to take.
So finding the proper use cases on how the technologies make sense together would be more interesting for me that showing how the two can be hooked up together technically. The latter part is not so hard, i think.
"Jeff" wrote : | This requirement would be supported by a "rule flow jpdl"
| | (much like the Seam "page flow" jpdl).
|
yes, that could be done in another process language. it probably could be done with jpdl as well, but a special purpose process language would give you much more convenience over the more generic jpdl.
"Jeff" wrote : | I am not sure this requirement involves persistent wait
| | states.
|
A node would be a wait state, but it wouldn't have to be persisted.
"Jeff" wrote : | I don't understand Tom's comment "By default, jBPM will fire
| | all rules when a process variable is updated."
|
|
I mean that there is one use case in which the combination of rules and process makes good sense to me (much more then in assignment or decisions): That is where the process variables are the facts in a working memory and the rules calculate derived information from process variables. That derived information might also be stored as process variables (as discussed above). To keep the derived information up to date, all rules need to be fired for each time, a process variable changes. So that is where we need some sort of event in jbpm that allows us to inject the 'fireAllRules' after each setVariable in the jbpm context.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964121#3964121
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964121
19 years, 8 months
[Design of JBoss jBPM] - Re: jbpm drools integration meeting
by tom.baeyens＠jboss.com
Hi, i take the liberty to post jeff's response:
"Jeff" wrote :
| Thanks for including me on the email thread. I am very interesting in this topic, as I have been working with customer to integrate jBPM and Drools.
|
| The emails contain various solutions (combined repositories, variable mappings, etc.), but I am not sure in some cases what problems are trying to be solved. So I though I might back up and start at what I think the jBPM / Drools integration requirements are, and see if that helps me understand this email thread.
|
| I think the goal of jBPM / Drools integration should be to provide the application developers with several integration components out-of-the box that are well documented and address many of the common use cases. In many instances however a customer's requirements will be different enough that they will need to create their own integration components. Even in these cases, what we provide out of the box will help them as a starting point.
|
| I think the requirements for jBPM / Drools integration are derived from a few general use cases:
|
| 1) Task Assignment
| 2) Actions Nodes
| 3) Decision Nodes
| 4) Rule Flow
|
| Before discussing the details of each of these, I think there are a couple general observations that should be made. In terms of "how often they change", I believe that users would like to change their rules the most frequently, business processes somewhat frequently, and code (hopefully), not as frequently. Second, they would like business analysts to be able to make the frequent, minor changes to their rules (example below).
|
|
| 1) Task Assignment. This involves invoking rules from a "RulesAssignmentHandler" to determine the actorId to set on the assignable (TaskInstance or SwimlaneInstance). In this case the organizational model, some domain objects, and the assignable need to be asserted into the rules engine.
|
| The organizational model does not change too frequently (not more than daily in any case), and is perhaps quite large (thousands of employees) so it would be nice to not have to re-assert into working memory each time an assignment is made. The domain objects are changing from process to process, so they should be re-asserted. The assignable could be a global variable.
|
| The rules themselves might be quite numerous. For example, if we had an organizational model where users were mapped to roles within an office, and we wanted to assign a Task to someone in a specific role (based on the task definition) and office based on the state the insured lived in and the type of claim, then there might be a separate rule for each office and type of claim.
|
| Rule "Determine Chicago Office"
|
| when
| Insured ($state : state == "Illinois")
| Claim ($lob : lineOfBusiness == "health") then
| assert(new Office("chicagohealth"));
|
| end
|
| ...
|
| Rule "Determine Actor"
|
| when
| exists Office()
| Office($officeName : officeName)
| $role : Role()
| Membership( role == $role, office == $officeName, $user : user )
|
| then
| $a.setActorId($user.getName());
|
|
| In most cases the same rules would determine task assignment for all tasks within a process definition, so the task assignment rules should be able to be specified for the entire process definition.
|
| If the assignment rules change, e.g., a new office is opened to support the southern half of Illinois, then it is probable the case that the process definition should change. Otherwise in our example, we might have a claim that was being worked in Chicago office suddenly being assigned to the new office.
|
| This type of usage would be supported by a pre-compiled rule base associated with a process definition. (as Tom describes in 1 in his email).
|
| This scenario would also be well supported through the ability to assert the organizational model into the working memory once, and then use this working memory, asserting new instance of domain objects (and I suppose retracting them as well?). It is not really clear to me how this would work, particularly with multiple threads. Perhaps some kind of partitionable / composite working memory is required.
|
| Although each customer would likely have their own organizational model, an out-of-the-box implementation based on the jBPM Identify component would be very useful for customers to understand how rules based assignment can work.
|
|
| 2) Actions / Nodes. This involves invoking rules as at a node in a process, either from an action configured on the node itself or associated with some node event. In this scenario domain objects would be asserted in the working memory, along with the jBPM ContextInstance. The later would be used to communicate the results of the rule execution. I.e., the right hand side would invoke contextInstance.setVariable("resultsOfRuleExecution", "some result").
|
| The ability to describe what domain objects should be asserted by this "RulesActionHandler" on the process definition is required. However this must be extremely flexible, as there are many different possible requirements here: assert all instance of a specific domain object, assert a subset of a specific domain object, assert single instances of many types of domain objects, assert multiple instances of many types of domain objects, etc.
|
| Also, where the domain objects live must be flexible. While it may be convenient to store them off as ContextInstance variable, this involves serializing each object, and, depending on when they are stored in jBPM, the potential for them to become out-of-date. Thus just specifying a set of jBPM constextInstance variable is not enough, there must be a way to describe how to get the domain objects from other repositories (e.g., a hibernate query, a web service, etc.).
|
| As noted above, Customers expect to be able to make minor changes to their rules within the context of an executing business process. So for example a rule compares values from two different domain objects, and if the values differ by more that a specified per cent, then the rule fires and the consequence sets some jBPM ContextInstance variable. In this scenario the user would expect to be able to adjust that deviation percentage, re-deploy the rule file, and when a currently executing process instance gets to the node that fires that rule, it will fire the latest version. So in this case if the rule base was precompiled and stored within jBPM, then there must be a way to modify it while a process instance is executing. I.e., it is okay for the "rule bases to be deployed and managed separately from processes but in the same repository" as long as by separately managed this requirement can be met.
|
| Although each customer would have their own domain model, an out-of-the-box implementation of a RulesActionHandler along with an example would be very useful for customers to understand how rules can be invoked at node.
|
|
| 3) Decision Nodes. This involves invoking rules from a RulesDecisionHandler. In this scenario, domain objects would be asserted in the working memory along with a set of transitions, and the token. The LHS of the rules would specify which transition to take, e.g., token.signal("transition"). The token and the transitions could be global variables.
|
| In this scenario we might expect that if the rules for making a process routing decision change, then we might want to re-deploy the process definition.
|
| Although each customer would have their own domain model, an out-of-the-box implementation of a RulesDecisionHandler along with an example would be very useful for customers to understand how rules based decision nodes can work.
|
|
| 4) Rule Flow - Using jBPM as to control rule flow. In this scenario this is a single working memory for the process instance, and every node in the process definition asserts, detracts, modifies data to this working memory, causing rules to activate / fire. It is another way to control rule flow at a more macro level (for situations where agenda groups, salience, and just good rule design are not enough).
|
| This requirement would be supported by a "rule flow jpdl" (much like the Seam "page flow" jpdl). Nodes would become blocks of rules (like agenda groups with even more control over when they execute). Process variables would constitute the objects asserted. When the process instance is created, the process variables would be instantiated, others may be created as the process proceeds.
|
| I am not sure this requirement involves persistent wait states. That is, I believe the execution of the entire process instance happens in a single transition, with no requirement to persist the intermediate state of the rule execution (I may be wrong here, I have not given this scenario much thought). On the other hand, if persistent wait states within the rule flow are required, then what Tom proposes for storing / reconstructing the working memory would be required as well.
|
| I don't understand Tom's comment "By default, jBPM will fire all rules when a process variable is updated." If the update comes from the rules updating the working memory, then they will fire (if their conditions are now satisfied). How else would the process variables change (from some outside source?). Perhaps Tom has a different use case in mind for number 2, although I don't think it fits in the other use cases I described above.
|
| Jeff
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964120#3964120
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964120
19 years, 8 months
[Design the new POJO MicroContainer] - Re: Pushing beans into the kernel
by scott.stark＠jboss.org
So the problem is that the KernelController knows nothing about the server. I did get past this doing:
| // Register the Server instance in the kernel
| Kernel kernel = getKernel();
| KernelController controller = kernel.getController();
| KernelRegistry registry = kernel.getRegistry();
| KernelConfigurator config = kernel.getConfigurator();
| BeanInfo info = config.getBeanInfo(server.getClass());;
| AbstractBeanMetaData metaData = new AbstractBeanMetaData("org.jboss.system.server.Server", null);
| AbstractKernelControllerContext serverEntry = new AbstractKernelControllerContext(info, metaData, server);
| controller.install(serverEntry);
|
At first this failed because the server instance was being restarted by the kernel while it was already in start due to the ServerLoader calling start. I just worked around this for now by checking for a duplicate call. I need to figure out how to install a bean that is already started.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964024#3964024
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964024
19 years, 8 months