Hi, first of all - I am glad to see some formal activities around jBPM. I would like to suggest to put some focus as well on authorization that should provide at least some basic option to restrict access to selected processes to users with granted roles, etc. There was mentioned that jBPM 5 will have WSHT - does it mean it will provide extensive support for web services? Currently it is not there and I think Riftsaw is dedicated for Web Service orchestration (BPEL). How jBPM will fit into that?! In general, it looks very promising and I am looking forward to it. Cheers, Maciej _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

Hello Mauricio, hello Maciej, hello folks Am 17.04.2010 14:37, schrieb Mauricio Salatino: > It looks really good. I'm agree to put BPMN2 as default modeling > language. Other languages as jPDL and RuleFlow can be supported as well > but the focus needs to be on BPMN2. I have to say that I partly disagree here. In general the focus should be on BPMN-2.0 but to enable users to have a smooth transition at the beginning jPDL should have the same priority. It would provide a much easier migration from previous engines. This again leads to the question: How far will jBPM 5 be based upon jBPM 4.x. > On Fri, Apr 16, 2010 at 3:17 PM, <swiderski.maciej(a)gmail.com > <mailto:swiderski.maciej@gmail.com>> wrote: > > Hi, > > first of all - I am glad to see some formal activities around jBPM. > > I would like to suggest to put some focus as well on authorization > that should provide at least some basic option to restrict access to > selected processes to users with granted roles, etc. IMHO it should also be possible to leave authorization to the application - for the reason of embeddability. So maybe this should be configurable and pluggable. Anyway in contrast to the jBPM 4.x right now, it should be possible to pass the username to engine when invoking operations on the API. A common use case is the "process owner" - the guy who started the process but also for reasons of audit and traceability: who performed which action on the engine. I don't what kind of support is existent in jBPM 3.2. > > There was mentioned that jBPM 5 will have WSHT - does it mean it > will provide extensive support for web services? Currently it is not > there and I think Riftsaw is dedicated for Web Service orchestration > (BPEL). How jBPM will fit into that?! I understand this in the following way: a BPEL engine should fit in the overall architecture - kind of pluggable - but jBPM should not execute BPEL processes itself. However from the PVM's point of view this is possible. Since it will be a BPMN-2.0 there will be webservice support regarding service tasks since webservice calls are the only service calls standarized by the BPMN 2.0 specification. Regards Sebastian -- Sebastian Schneider e-mail: Sebastian.Schneider(a)alumni.fh-aachen.de _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

Hello Mauricio, Am 17.04.2010 15:40, schrieb Mauricio Salatino: > All the authorization part in my opinion should be left outside of the > framework scope. Because it always depends on business needs. > The way that it's handled in Drools Flow and in jBPM 3.2.x it's a good > approach. I fully agree. It's done this way in jBPM 4.x, too. > About BPMN2, if the PVM supports different languages, JPDL can be > supported as well, but for interoperability reasons would be nice to > have BPMN2 as priority. jBPM 4.x also has that approach right? it was > trying to support BPMN2 as far as I know. You're right. Development was focusing on this and it is already possible to execute BPMN-2.0 processes. So they weren't trying but they already showed that it worked. The most important elements like exclusive gateways, forks etc. are already supported but there is still a lot of fine tuning necessary. To clarify: If the concept talks about the PVM it talks about the PVM of jBPM 4.x? -- Sebastian Schneider e-mail: Sebastian.Schneider(a)alumni.fh-aachen.de _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

Hello Mauricio, Am 17.04.2010 18:20, schrieb Mauricio Salatino: > Hi Sebastian, > Not sure about PVM, I think there are some differences with jBPM that > need to be addressed. > In drools flow there is already an advanced support for BPMN2, so it > think we need to dig a little bit to find out big differences and > missing points. Does Drools Flow use a version of the PVM? Anyway, I never understood completely what was the point of Drools Flow since in the first place Drools is a business rules engine for me - and a good one - but not a solution for the execution of complete processes. I know that there are cases where a busines rule represents a kind of flow and this is where Drools Flow fits in for me but I would never consider task management part of it for example. Just my 2 cents Sebastian -- Sebastian Schneider e-mail: Sebastian.Schneider(a)alumni.fh-aachen.de _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

Hello Mauricio, Am 17.04.2010 19:01, schrieb Mauricio Salatino: > Sebastian, good to know that. > Drools right now it's a full Business Logic integration Platform and it > includes a complete business process engine called Drools Flow. > The idea of the Drools platform is to be completely integrated to be > able to use both: rules and processes to model business situations. The > big difference in my opinion are the API and a less process centric > vision in Drools Flow. Because the idea is to have an API focused in > business knowledge (rules, processes, and every other business asset > that helps us to implement business solutions). > > That's my two cents. I am getting the idea and there's nothing wrong about it from my point of view - for the right use cases. IMHO there should be separation of the APIs for processes and rules. Imagine use cases where you just want a process engine with a small footprint but you don't need Drools because your own application takes the place of it (to make business decisions) or in situations where you want or you have to use a different external rules engine and repository - maybe even an enterprise-wide repository. So I tend to a modular design with a strong integration of jBPM and Drools to get you you going fast if you want to use them both but to leave the choice to the user. Best regards Sebastian -- Sebastian Schneider e-mail: Sebastian.Schneider(a)alumni.fh-aachen.de _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

I am getting the idea and there's nothing wrong about it from my point of view - for the right use cases. IMHO there should be separation of the APIs for processes and rules. Imagine use cases where you just want a process engine with a small footprint but you don't need Drools because your own application takes the place of it (to make business decisions) or in situations where you want or you have to use a different external rules engine and repository - maybe even an enterprise-wide repository.

Hi guys, I agree with you if we are talking about jBPM as a framework as it is currently. But in my opinion presented concept is more like complete platform and not only framework. That's why I suggested that authorization should be included there as well. Obviously it should be plug-able but I think this will be done like that by default. BTW, it was described already in the article, I just simple missed it. In addition, it should be clearly shown what is the purpose of jBPM and Drools. At this point they overlap each other in some areas which makes it a bit confusing. As Sebastian pointed out, Drools is a good rules engine and jBPM is a good workflow engine so focus should be on integrating them in a easy way, that would bring a lot to both. Regards Maciej 2010/4/17 Sebastian Schneider <schneider(a)dvz.fh-aachen.de&gt; Hello Mauricio, > > Am 17.04.2010 18:20, schrieb Mauricio Salatino: > > Hi Sebastian, > > Not sure about PVM, I think there are some differences with jBPM that > > need to be addressed. > > In drools flow there is already an advanced support for BPMN2, so it > > think we need to dig a little bit to find out big differences and > > missing points. > > Does Drools Flow use a version of the PVM? Anyway, I never understood > completely what was the point of Drools Flow since in the first place > Drools is a business rules engine for me - and a good one - but not a > solution for the execution of complete processes. > > I know that there are cases where a busines rule represents a kind of > flow and this is where Drools Flow fits in for me but I would never > consider task management part of it for example. > > Just my 2 cents > Sebastian > > -- > Sebastian Schneider > e-mail: Sebastian.Schneider(a)alumni.fh-aachen.de > _______________________________________________ > jbpm-dev mailing list > jbpm-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbpm-dev > _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

I would like to suggest to put some focus as well on authorization that should provide at least some basic option to restrict access to selected processes to users with granted roles, etc.

There was mentioned that jBPM 5 will have WSHT - does it mean it will provide extensive support for web services? Currently it is not there and I think Riftsaw is dedicated for Web Service orchestration (BPEL). How jBPM will fit into that?!