July 2008 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : So instead of naming it a decision, you could call it exclusive gateway right away. The reason why I prefer BPMN glossary over jBPM terms is that these people did a good job finding terminology and add short, descriptive explanations to the core concepts. | First, I think you overrate the BPMN spec as the final thing that concludes the battles in BPM. Second, API mainly deals mostly with runtime constructs. BPMN deals with process definition constructs. Third, for the simple constructs like exclusive gateway it is possible. But the more complex you go, the harder it will be to map the analysis constructs to implementation constructs. Only if the direction for BPMN 2.0 would be to add exact executable semantics to BPMN, then it would become a viable option to make sure we cover all the constructs. Forth, if BPMN becomes executable, then we should do that as a separate language. (maybe as a jPDL variant, depending on how close it is) If we take BPMN as a basis in the API, then we introduce a mismatch between XPDL and BPEL, both of whom are also supported on the PVM and those also have their own naming scheme. "heiko.braun(a)jboss.com" wrote : | Whereas in the PVM, we still have 3 or 4 kinds of "Executions". | Can you elaborate on this ? Different views on an execution were introduced to provide proper interfaces in each use case. You helped to induce that change. We changed from offering all methods and throw an exception when a user invokes an invalid one, to only offer the appropriote methods in the different use cases of an execution. I don't yet see the relation with this post. "heiko.braun(a)jboss.com" wrote : If we could manage to become explicit in our jBPM4 terminology the same way, then I wouldn't complain. But currently I see a 200 pages document with very precise terminology (BPMN) and a redundant, hard to understand API (PVM) which is only obvious to it's inventor. | | So give me one good reason why we should chose the hard way and try to be superior to the BPMN spec leads and come up with something on our own. Because BPMN is not doing the same thing as what we're doing. We're defining a framework for building state machines and executable process languages. BPMN defines a process modelling notation. Some of the languages that can be implemented on PVM even have a more technical background that is not always related to BPM: pageflow, programmatic state machines, naked BPEL. So that is why I think it is better to have a naming scheme that is neutral to all the targetted specs, patterns and languages out there. The API naming convention is important, but IMHO, there are much more important debates to have: 1) The runtime data structures. Those determine which control flow constructs can be build on it. 2) Do the PVM runtime structures cover the BPMN interpretations. For each possible runtime interpretation of BPMN constructus, can we build executable constructs for it on the PVM. This again boils down to the runtime data structures. When it comes to the power of a BPM/workflow engine, then mostly, your discussing the capabilities of the runtime datastructures. (In)validating those is more important then the API naming scheme. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166911#4166911 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166911

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by heiko.braun＠jboss.com

But thanks for the examples. I'll take a look them and get back to you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166904#4166904 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166904

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by heiko.braun＠jboss.com

anonymous wrote : | BPMN is not a proven concept. | Tom, maybe you got me wrong here. I am not talking about BPMN or BPEL as a whole. When I say concept, I mean the BPMN composites. I.e. gateway, signal, event, whatever. They all have distinct meanings and an established name. So instead of naming it a decision, you could call it exclusive gateway right away. The reason why I prefer BPMN glossary over jBPM terms is that these people did a good job finding terminology and add short, descriptive explanations to the core concepts. Whereas in the PVM, we still have 3 or 4 kinds of "Executions". If we could manage to become explicit in our jBPM4 terminology the same way, then I wouldn't complain. But currently I see a 200 pages document with very precise terminology (BPMN) and a redundant, hard to understand API (PVM) which is only obvious to it's inventor. So give me one good reason why we should chose the hard way and try to be superior to the BPMN spec leads and come up with something on our own. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166903#4166903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166903

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by heiko.braun＠jboss.com

anonymous wrote : | introducing use of BPMN terms into the execution domain, e.g., as the basis for names in an API, would be a really bad idea. | Why? Come on guys, add some meat to the discussion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166899#4166899 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166899

17 years, 2 months

1
0
0 / 0

jBPM3 module ownership

by Thomas Diesler

Hi Tom, could you please comment on https://jira.jboss.org/jira/browse/JBPM-1403 cheers -thomas -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler BPM Product Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 4: Identity and Task projects

by tom.baeyens＠jboss.com

that is a work in progress. rough lines are in svn project. though i'm not sure what its current state is given the migration and refactorings. it will be brought in a better shape when i'm working on jPDL, which should be next month. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166891#4166891 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166891

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

here's a typical example that shows how hard it is to bind executable semantics to analysis models. http://davethinkingaloud.blogspot.com/2008/07/business-process-failures-e... This is from a vendor that is based on BPMN and tries to make it executable with BPEL. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166882#4166882 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166882

17 years, 2 months

1
0
0 / 0

[Fwd: Google Alert - jbpm]

by Tom Baeyens

china seems to be discovering jBPM :-) regards, tom. -------- Original Message -------- Subject: Google Alert - jbpm Date: Sat, 26 Jul 2008 01:40:58 -0700 From: Google Alerts <googlealerts-noreply(a)google.com> To: tom.baeyens(a)jboss.com Google News Alert for: *jbpm* 开源SOA如何证明业务处理的价值 <http://smallbizit.ctocio.com.cn/pinglun/442/8214942.shtml> IT专家网 - 重庆,China 要能够容纳下一代电信产品的需求，Fricke说，公司需要将提供服务的方式自动化，通过企业服务巴士(ESB)以及JBoss jBPM，一个基于J2EE的开源的工作流管理系统。 *...* See all stories on this topic <http://news.google.com/news?hl=en&ncl=http://smallbizit.ctocio.com.cn/pin...> 开源框架Hibernate3的新特性以及发展趋势 <http://tech.ccidnet.com/art/3539/20080630/1492653_1.html> 赛迪网 - Beijing,China 具有以下发展趋势：（1）与其他开发框架的集成将越来越成熟：如与struts、sp ring、jbpm的集成，充分发挥Hibernate自身的优势，也吸取了对方框架的优势，在软件系统的 *...* See all stories on this topic <http://news.google.com/news?hl=en&ncl=http://tech.ccidnet.com/art/3539/20...> �源框架Hibernate3的新特性以及�展�� <http://big5.ccidnet.com:89/gate/big5/java.ccidnet.com/art/3539/20080630/1...> �迪� - Beijing,China 具有以下�展��：（1）�其他��框架的集成�越�越成熟：如�struts、sp ring、jbpm的集成，充分��Hibernate自身的��，也吸取了�方框架的��，在��系�的 *...* See all stories on this topic <http://news.google.com/news?hl=en&ncl=http://big5.ccidnet.com:89/gate/big...> 实例证明开源软件SOA具有很大价值 <http://tech.sina.com.cn/s/2008-06-27/1039711229.shtml> 新浪网 - Beijing,China Fricke说，为了满足下一代电信产品的需求，该公司使用企业服务总线和基于J2EE 的开源软件工作流管理系统JBoss jBPM实现了把服务提供给客户的自动化。 *...* See all stories on this topic <http://news.google.com/news?hl=en&ncl=http://tech.sina.com.cn/s/2008-06-2...> Google Blogs Alert for: *jbpm* Vermont IT Jobs: Software Developer, Burlington Vermont <http://www.thedatafarm.com/blog/2008/07/26/VermontITJobsSoftwareDeveloper...> By Julie Lerman The Software Developer will support our existing products and help Vertek build our next generation workflow platform which leverages Red Hat’s *jBPM* workflow engine with a Google Web Toolkit (GWT) Web 2.0 presentation framework. *...* Julie Lerman Blog - Jobs - http://www.thedatafarm.com/blog/ <http://www.thedatafarm.com/blog/> [Seam Users] Seam with *jBPM* - task(slash)process id may not be null <http://www.seamframework.org/Community/SeamWithJBPMTaskslashprocessIdMayN...> By Jakub Naruszewicz I'm seam beginner and I have got problems with integrating seam with *jBPM*. (using JBoss AS 4.2 and Seam 2.0.2). I have got two Stateful Session Beans: @Stateful @Name("startProcess") @Scope(ScopeType.BUSINESS_PROCESS) public class *...* SeamFramework.org - Seam Users - /Community/SeamUsers </Community/SeamUsers> ------------------------------------------------------------------------ This once a day Google Alert is brought to you by Google. Remove <http://www.google.com/alerts/remove?s=EAAAAJDw2k6B274AO-BWsW7Nmu4&hl=en&gl=> this alert. Create <http://www.google.com/alerts?hl=en&gl=> another alert. Manage <http://www.google.com/alerts/manage?hl=en&gl=> your alerts.

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

I don't think that I do a bad job in analysing and predicting the BPM markets. If you look at this article from Miko Matsumura. http://www.soacenter.com/?p=163 Especially the part about The âMagic Cure for BPMâ Business analysts Rejoice!, expresses the current mainstream thinking about BPEL. Exactly those thoughts I have been expressing constantly for the last for years. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166789#4166789 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166789

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining the API Mission

by tom.baeyens＠jboss.com

"heiko.braun(a)jboss.com" wrote : anonymous wrote : | | The mismatch in naming of workflow elements is nearly as bad as it can get... | | | | I totally agree with this. This was the reason for looking at BPMN in the first place. We wanted to get to "proven concepts" with "established terminology". | BPMN is not a proven concept. Look at the discussions around BPMN 2.0 and you'll see that the future if far from clear or stable. Second, it is a analysis modelling notation with focus on the business analyst. For the terminology part, that is not a good basis for an executable process language. I agree with Ed's comment later on that BPMN terminology is not a good basis for the API. "heiko.braun(a)jboss.com" wrote : | And to be honest, following the discussions around BPMN and executable dialects, I still don't see arguments why it can't be done. Please show me examples of BPMN elements that conflict with execution. | Adding a runtime interpretation to BPMN modelling constructs is possible. But by doing that, you would limit the use of BPMN for its original purpose: analysis modelling. Because when all BPMN constructs have a runtime interpretation, that means that an analyst can not model freely any more. When he/she draws a certain box, he/she has to be aware of the implications when this process is being executed on a computer system. Which eventually will limit BPMN to graphical programming. It is impossible to create an executable process language so that non tech analylsts can model in all freedom and which aftwards turns out to produce exactly the right software. There must be a mapping between analysis and executable process language. The easiest and most practical way to do this is by introducing a one-way translation between BPMN and jPDL. That way BPMN can keep its focus on being a modelling notation for non tech business analysts. And jPDL can keep its focus on being an executable process language that developers can use to produce the same diagram as the analysis model. "heiko.braun(a)jboss.com" wrote : | IMO it's not necessary to have full BPMN support. We just need those parts that we actually can make executable. If I remember correctly BPMN even defines profiles with different scopes. But I think a 60% BPMN support is still better 100% jPDL, which is, by the way, something we cannot even easily compare at the moment, because jBPM doesn't use common BPM patterns and established terminology to express it's features/capabilities. The market doesn't have proven concepts that we can just follow and implement. Two years ago, BPEL was the well accepted standard for BPMN. One year ago, BPMN came into the picture. So everyone focussed on the impossible BPMN to BPEL mapping. Now, as people realize BPEL is best suited for service orchestration, BPEL is starting to fade away as a solution for BPM. Now, the battle for BPMN 2.0 shows that BPMN itself is not a proven concept. There is only 1 product in the BPM area that I have great respect for. IDS Scheer's ARIS. They take the inverse perspective of us. We start from an executable process language jPDL, and we try to bind it to the analysis world without compromise on the technical and executable side. IDS Scheer has by far the most advanced modelling environment, and they only go as far to bind it to implementation details as they can without compromise on the analysis side. All initiatives that try to combine both have been proven to be good only in a niche area. There is no technology that binds the 2 automagically and is able to be more then a niche product. @camunda: IDS Scheer has one of the best round tripping support out there. E.g. they can create graphical diffs of analysis models and calculate the impacted parts in the related executable process. But I think it does not fit our target. As it takes a huge development effort. And it also takes a great effort from to user to bind the analysis and implementation models and keep all of that in sync. I think the latter is only suitable in the very top range of use cases. I think that with a one-way translation from analylsis to implementation model, we can serve more then 90% of the use cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166788#4166788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166788

17 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev July 2008