tag:blogger.com,1999:blog-5869426.post1697878324780103232..comments2024-03-25T09:15:58.430+00:00Comments on Drools & jBPM: A Vision for Unified Rules and ProcessesMark Proctorhttp://www.blogger.com/profile/03304277188725220501noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-5869426.post-31424753378256487652021-04-05T09:37:18.133+01:002021-04-05T09:37:18.133+01:00Đặt vé tại phòng vé Aivivu, tham khảo
Ve may bay ...Đặt vé tại phòng vé Aivivu, tham khảo<br /><br /><a href="https://aivivu.com/ve-may-bay-di-my-us-gia-re-bao-nhieu-tien/" rel="nofollow">Ve may bay di My</a><br /><br /><a href="https://aivivu.com/ve-may-bay-di-hcm-sai-gon-bao-nhieu-tien/" rel="nofollow">vé máy bay hà nội sài gòn bamboo</a><br /><br /><a href="https://aivivu.com/ve-may-bay-di-ha-noi-han-bao-nhieu-tien/" rel="nofollow">book vé máy bay đi hà nội </a><br /><br /><a href="https://aivivu.com/ve-may-bay-di-nha-trang-cxr-bao-nhieu-tien/" rel="nofollow">giá vé máy bay đi nha trang khứ hồi</a><br /><br /><a href="https://aivivu.com/ve-may-bay-di-quy-nhon-gia-re-bambooo-vietjet-vietnam-airlines/" rel="nofollow">vé máy bay tphcm quy nhơn</a><br /><br /><a href="https://aivivu.com/dich-vu-xe-dua-don-taxi-san-bay-noi-bai-gia-re/" rel="nofollow">dịch vụ xe đưa đón sân bay nội bài</a>vé máy bay từ canada về Việt Namhttps://aivivu.com/ve-may-bay-tu-canada-ve-viet-nam-gia-re/noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-12173059178496458362007-12-01T06:38:00.000+00:002007-12-01T06:38:00.000+00:00Greetings, Programs:Lots of comments - this makes ...Greetings, Programs:<BR/><BR/>Lots of comments - this makes 15 so far - and most seem to have lost the idea of AI in the beginning. (WHAT did he say??? Forget it! He's some kind of lunatic, radical, old time AI guy!) OK, all jokes aside, let's go back to what we were trying to do originally; we were trying to emulate the human mind. The two main branches of AI back then were RBS (RuleBased Systems) and ANN (Artificial Neural Nets) and development in both fields seemed to go to different corners to die in oblivion. <BR/><BR/>Somewhere along the way during the Great Winter of AI in the late 80's and early 90's, the business guys came to the rescue by using rules in the business world. In about 2000 they (meaning ILOG and ND) developed the spreadsheet approach to doing rules - and the business guys just ate it up. They started queueing up to spend millions of dollars, pounds, yen and Euro to get the "jump" on the competition. It became all the latest craze.<BR/><BR/>This is nothing more than giving the business guys access to Java code (or C++ or whatever) to make changes so that they don't have to go through IT to make the changes for them. And we, the geeks in AI, have the audacity to call this structured programming approach a BRMS, Business Rules Management System. Y U C K ! ! !<BR/><BR/>Any time that we have to do something really cool and really "intelligent" that would give that business user a REAL jump on the competition, they get sold a bill of goods by some sales guys who can not understand the difference between declarative programming and procedural programming. (And I have knows some rulebase guys who could not understand the difference!) A spreadsheet approach is something that is understood by sales, understood by the business guys and is understood by the pseudo-geeks at the vendor pretending to be rulebased professionals. <BR/><BR/>Why do we do it? Because doing something declarative would mean totally restructuring and rethinking the entire business process. It would mean having to understand using a non-procedural approach by using something like Intelligent Agents (remember FIPA?) and tying to get ANN into the rulebase. All of this is nothing more than trying to simulate an Analog Computer that also has storage of rules available. <BR/><BR/>So why do we do it? Because we're all whores and we have all sold out to the easiest (not necessarily the best) solution. All of us can understand the necessity for process and flow of documents and things of that nature because we have grown up that way. <BR/><BR/>But - what if we stopped and began to actually think about what we need to do and how to go about it the most intelligent way? Would we do it differently? Maybe not. But we never go down that road because it takes more time and is more expensive and the bloody salesmen can't explain it in their silly Power Point presentations.<BR/><BR/>So, BREAK OUT of the mold. Try to think. If you can understand the Rete Algorithm (and about 80% of the Senior Rulebase Consultants can not do that) then you can help design a system that will actually "THINK" rather than just implementing rules though up by some underpaid employee who didn't understand the business in the first place.<BR/><BR/>OK, Rant Over - go back to sleep. <BR/><BR/>SDG<BR/>YaakovAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5869426.post-76293255133177433682007-11-24T14:54:00.000+00:002007-11-24T14:54:00.000+00:00this is just my bias opinion. usually in large fir...this is just my bias opinion. usually in large firms, those pieces are owned by different groups, so it's politically undesirable to unify those. Trying to get those groups to work together might be like sky diving without a parachute.<BR/><BR/>Small startup is the only place where I feel that has a good chance of working.<BR/><BR/>The other major challenge I see the process may be long running and could take days to complete. In those cases, many products persist the state to a database or file system and then reload it. One could consider that a stateful application, but it's more like a continuation. A business rule engine shouldn't be handling persistence in my mind. It should be handled at a higher level like a rule service. To the consumer, it looks like a stateful session, but under the hood it's really stateless.<BR/><BR/>Running a rule engine in a stateful mode should only be done for real-time, event processing or reactive systems. That's my bias 2 bits.woolfelhttps://www.blogger.com/profile/13814445471254728002noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-18896286539732161472007-11-24T12:18:00.000+00:002007-11-24T12:18:00.000+00:00Mark,Sounds like you should check out NASA's RCS s...Mark,<BR/><BR/>Sounds like you should check out NASA's <A HREF="http://www.ai.sri.com/~prs/rcs.html" REL="nofollow">RCS system</A> and <A HREF="http://en.wikipedia.org/wiki/BDI_software_agent" REL="nofollow">BDI agents</A>. There's already been a lot of work done in this area.<BR/><BR/>r.<BR/><BR/>PEGPeter Evans-Greenwoodhttps://www.blogger.com/profile/15136540674610946829noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-64833270245409476472007-11-24T09:00:00.000+00:002007-11-24T09:00:00.000+00:00Unification doesn't mean one modelling paradigm - ...Unification doesn't mean one modelling paradigm - you can't model everything with just a process paradigm, or a rules paradigm. <BR/><BR/>When the execution environment provides seamless communication between your rules and process it makes it easier to exploit the overlaps. <BR/><BR/>There is also a lot of core areas in the code, api and infrastructure that you can leverage.<BR/><BR/>Rules themselves should not be procedural, but life is never that simple, so to model many problems you start to pollute those rules model with procedural execution semantics. Unification is about extracting that information to be properly modelled in a procedural graph language. At the same time the rules metaphor can make our procedural metaphor much richer.<BR/><BR/>Typically when a process has to make a decision it's an evaluation of the context at that point in time - while we will still allow this we also allow the conditionals on splits (decisions), milestones, timers to be control by a rule LHS "when" statement. <BR/><BR/>Let's take another use case, campaign management. The emailer task in the process definition can have its data driven by a lhs "when " rule statement. We can then combine the rules and process definitions to provide strategies for this to ensure maximum delivery - i.e. only send 100 in the last 2 hours to this domain, then switch to another domain.<BR/><BR/>Kris, the brains behind this, has spent 6 years on his Phd researching clinical diagnosis, which is both rules and process intensive, and this vision of finding out the overlaps of rules and processes and make sure they are easily exploitable in a single platform is the results of this - along with the model of user pluggable "work items" to enable a stronger declarative programming paradigm.Mark Proctorhttps://www.blogger.com/profile/03304277188725220501noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-18637087292892179092007-11-24T01:55:00.000+00:002007-11-24T01:55:00.000+00:00Although the idea of a unified approach sounds des...Although the idea of a unified approach sounds desirable, I don't think it is feasible. At best, I think the only thing you can do is unify the runtime semantics. Trying to cover all modeling scenarios, feels like an unwieldy thing to do. The industry can definitely improve it and make it better.woolfelhttps://www.blogger.com/profile/13814445471254728002noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-53817643377487336652007-11-22T15:31:00.000+00:002007-11-22T15:31:00.000+00:00As i said over on JT's blog,1) What does the busin...As i said over on JT's blog,<BR/><BR/>1) What does the business get or see from this approach? Can business people manage their rules and decisions directly or do they have to depend on a modeling expert?<BR/><BR/>2) I would simply state that everything is inextricably linked, one could say that rules and data are are more tightly linked than rules and process, given the similarity of data models and terms & facts models. I know you don’t want separate process and rule platforms, do you want to get rid of separate data platforms as well? If it is the nature of the marketplace that today there are separate process products and separate rules products, that will change when vendors realize that it makes sales sense to combine them as a product, and I think recent purchases/mergers are showing this to be happening already. Still, some customers may prefer ‘best-of-breed’ solutions and want to integrate the whole themselves. There have always been pros and cons to both approaches beyond this domain, and I can’t see anything yet that will change the minds of those who favour either approach.<BR/><BR/>Anyway, my 2 pennies/pence worth.David Wrighthttps://www.blogger.com/profile/05103379078232846587noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-81144339916312590162007-11-21T10:25:00.000+00:002007-11-21T10:25:00.000+00:00marcs vision lets hope that in the future the life...marcs vision lets hope that in the future the life as software architect for business applications becomes easier :-)<BR/>I'm developing an ERP solution (driven by workflow, business processes and business rules), so its the daily frustration how to make all things run and how to integrate the business guys into the development lifecycle.<BR/>its always dificult to tell a business guy when a part of his work is a drools-ruleflow-process and when its a jbpm-process.<BR/>at the moment we're using drools-ruleflow only for complex rules where the order of steps is important or with complex conditions when a step can be executed. but if its long-running we have to use jBPM because the flow is persisted. or if there are different actors we also use jBPM because drools has no swimlanes.<BR/>as you see: some decisions are only technical - if the rules-engine and the process-engine were better integrated I can imagine easier ways ;-)<BR/>to hide this from the business guys and make life easier, I'm trying to unify it the following way:<BR/>using a customized MagicDraw UML activity diagram together with domain specific UML profiles for business processes and rules.<BR/>now the business people can model all the processes using a single environment.<BR/>but this is only the first step - our project is model-driven and uses the MagicDraw - EMF - integration and also the openArchitectureWare (oAW) tools from eclipse modeling project:<BR/>domain specific oAW-XPAND-templates generate ruleflows and jPDL and much infrastructure - code.<BR/>at the moment its not so easy to bring it all together because same data can exist inside jBPMs context and also as facts inside the drools engine. but using oAW-XPAND-templates we can hide this technical barrier from the business application developer.<BR/>if something of Marcs vision becomes true it will be easy to change the behavior of the templates to support PVM+ or something else.<BR/>of course it would also be great to have drools and jBPM integrated inside eclipse IDE with ONE editor for ruleflows and business processes and to have ONE web-based management tool like BRMS and ONE Monitoring/Auditing-Tool for rules and processes together and and and... ;-)<BR/>but I also have to mention that the combination/integration of rules and processes is not the only scenario where we use drools inside our application: drools also works perfectly as rules-only-engine to make complex validation inside the GUI of an eclipse RCP client.<BR/>thanks to drools and jBPM (and using eclipse as a platform) its possible to develop flexible business applications. we'll publish our way to integrate drools and jBPM in some weeks as open source and are looking forward what will happen with Marcs vision.<BR/>ekkehardekkehttps://www.blogger.com/profile/12524911202665703266noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-10048644683712626512007-11-20T17:13:00.000+00:002007-11-20T17:13:00.000+00:00ah... so you have to put the html tags in yourself...ah... so you have to put the html tags in yourself :-)<BR/><BR/><A HREF="http://processdevelopments.blogspot.com/2007/11/unifying-processes-and-rules.html" REL="nofollow">My blog response</A>Tom Baeyenshttps://www.blogger.com/profile/03067067751334471585noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-59395219427161775922007-11-20T17:12:00.000+00:002007-11-20T17:12:00.000+00:00http://processdevelopments.blogspot.com/2007/11/un...http://processdevelopments.blogspot.com/2007/11/unifying-processes-and-rules.htmlTom Baeyenshttps://www.blogger.com/profile/03067067751334471585noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-43484849423038957482007-11-20T10:55:00.000+00:002007-11-20T10:55:00.000+00:00I've gotta agree with Mark and disagree with JT, a...I've gotta agree with Mark and disagree with JT, assuming that we're trying to capture interesting business logic (non-trivial decisions or exception rich processes), which we do as this is the bit the business really cares about.<BR/><BR/>Integrating rules and process is a good thing and I hope this goes somewhere, as we've been <A HREF="http://www.capgemini.com/ctoblog/2006/08/processes_rules_and_thing_in_b.php" REL="nofollow"> too hung up on technology platforms and not focused on what sort of things business solutions need to do</A>. The sort of business logic we see in the wild doesn't make this distinction between rules and process; complex decisions are often <I>decision making processes</I> that involve trial-and-error, while any worthwhile process is exception rich, requiring embedded decisions. Often the two are interwoven. The separation between rules and process is just an artifact of where the technologies came from, and not where we want them to be. Having separate rules and process engines creates a huge amount of overhead that we can better do without.<BR/><BR/>There's a lot of good technology we could be looking at to help push this forward, from <A HREF="http://www.laas.fr/~felix/publis/pdf/ijcai89.pdf" REL="nofollow">PRS</A> to modern beasts which vendors like <A HREF="http://www.oslo-software.com/en/index.php" REL="nofollow">OSLO</A> are offering.Peter Evans-Greenwoodhttps://www.blogger.com/profile/15136540674610946829noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-91716265593094155672007-11-20T01:55:00.000+00:002007-11-20T01:55:00.000+00:00Yaakov Kohen has just blogged this blog with some ...Yaakov Kohen has just blogged this blog with some intereting comments on the lines of giving people enough rope to hang themselves with :)<BR/><A REF="http://javarules.blogspot.com/2007/11/blogs-on-top-of-blogs.html" H>http://javarules.blogspot.com/2007/11/blogs-on-top-of-blogs.html</A>Mark Proctorhttps://www.blogger.com/profile/03304277188725220501noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-15156983703226659042007-11-20T01:41:00.000+00:002007-11-20T01:41:00.000+00:00"As you might expect, I disagree and posted a resp..."As you might expect, I disagree and posted a response here!<BR/>JT<BR/>James Taylor"<BR/><BR/>One of the beauties of a unified modelling environment is you get to choose how you want to model things. Just because you can model and deploy everything on a single engine session, doesn't mean you have to - you get to model your environment how you like from a collection of fully stateless services to a single fully stateful session and all the variations in-between - all with the unified tooling, apis, deployment and management - not forgetting the advantages of unified auditing frameworks, when Mr Sarbanes Oxley comes calling. I'm not pushing one approach to solving enterprise problems over another, but I am pushing the idea to give the user a choice to make those decisions themselves. You want a rule centric view of your current model, you got it, you want a process centric view of your model, you got it, you want something in-between, you got it - it's the users choice they know their requirements best. It's my fault in being ambiguous with my frustrations, after all blogs are just informative rants :) My frustration wasn't with SOA and decision services which is why I say "Not to mock this model, as it is actually quite useful" but more that the industry stops here, when more can be achieved. I don't want to go to FileNet for my workflow and Ilog for my rules, meaning I have to learn and manage two ways to deploy the stuff, two different apis and two server side management systems and have my interoperability points limited to the integration that those two companies thought to provide - and suffer from impedance miss matches else where. And when you start to take a more unified view of things it starts to allow for some more interesting behaviour, that would also be valid in SOA environments too. Rules and processes are inextricably linked; you simply cannot have processes without rules of some level, while rules can do without processes there are many types of problems that are hard to solve cleanly without them (which is why many rule companies are introducing simple ruleflow capabilities).<BR/><BR/>So I agree with you on the importance of SOA and decision services, sorry I phrased my frustrations badly in the blog. What I'm proposing does not limit any of the bulleted points you make on decisioning, in fact it enables them. But I don't agree with your view that unifying rules and processes is like unifying the UIs and Databases, the two are very complimentary with lots of overlap - but luckily I'm willing to put my money where my mouth is, so watch this space :) The important thing is we need to push our understanding and vision in these areas, R&D has moved far too slowly in the rules industry and we have to push the boundaries and see what falls out.<BR/><BR/>Mark<BR/>http://blog.athico.com The Drools BlogMark Proctorhttps://www.blogger.com/profile/03304277188725220501noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-33218160125612615612007-11-20T00:54:00.000+00:002007-11-20T00:54:00.000+00:00It's not that the business rule industry can't do ...It's not that the business rule industry can't do stateful. It's that users and developers don't know how to use it correctly. think of it this way. How many people use stateful EJB and how many use stateless EJB?<BR/><BR/>Most developers just don't understand how to build scalable stateful applications. I'm of the opinion that doing stateful applications right, takes lots of experience and patience.<BR/><BR/>I've blogged about this before, but I think it merits repeating. The kinds of things you want to use in a stateful manner are facts that are relatively static or have a well define life cycle. The dataset should also be manageable and small (less than 100K rows). For example, say I am building a trading system with routing rules. The kind of data I want to keep in the engine is security data. by that I mean information about the security, like issuer, legal entity, long rating, the exchange, subdivisions and other static information.<BR/><BR/>I've used these patterns in the past. I think if you interview 30 "rule developers" less than half of them will know of this rule pattern and even fewer have used the technique.<BR/><BR/>also, if you look at the research into reactive databases, there's lots of interesting literature about how to manage state effectively.<BR/><BR/>one easy way to achieve a reactive rule system would be to combine coherence with a rule engine. When the facts passes a set elapsed time, it can put the facts into coherence. when the engine needs it, it can ask coherence for it. This way, it becomes more transparent and the rule engine doesn't have to handle persistence.<BR/><BR/>That was the main reason I chose to use HashMaps for jamocha when I started. Since there's already a high performance and scalable data grid (ala coherence), makes sense to use it.<BR/><BR/>Daniel has a new entry about his team playing around with Ehcache, so I think they are also experimenting with similar ideas. Ehcache is nice, but it's no where near coherence.woolfelhttps://www.blogger.com/profile/13814445471254728002noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-57537209051794786952007-11-19T23:54:00.000+00:002007-11-19T23:54:00.000+00:00As you might expect, I disagree and posted a respo...As you might expect, I disagree and posted a response <A HREF="http://smartenoughsystems.com/wp/2007/11/19/please-dont-just-unify-rules-and-process/" REL="nofollow">here</A>!<BR/>JT<BR/>James Taylor<BR/><A HREF="http://www.smartenoughsystems.com/wp" REL="nofollow">The Smart (Enough) Systems blog</A><BR/><A HREF="http://www.ebizq.net/blogs/decision_management" REL="nofollow">My ebizQ blog</A><BR/><A HREF="http://www.smartenoughsystems.com/wp/about-the-book" REL="nofollow">Author of Smart (Enough) Systems</A>James Taylorhttps://www.blogger.com/profile/04589456040368641147noreply@blogger.comtag:blogger.com,1999:blog-5869426.post-87245463270203533412007-11-19T21:44:00.000+00:002007-11-19T21:44:00.000+00:00Dear Marc, this is very interesting initiative. As...Dear Marc, this is very interesting initiative. As I can see RuleFlow defines order of RuleSets to be executed. One thing that it is not clear (for now) is how rules are integrated in the process ? And how did you mapped process events to the rule constructs (if any) ?Milan Milanovichttps://www.blogger.com/profile/13206585053483450196noreply@blogger.com