-
30. Re: meeting context
making it useful for any process language is an exercise best suited for research
+1
We should do one thing and do it right. But if that's true, why the PVM in the first place? -
31. Re: meeting context
However, a generic API to cover the common subset of all process languages is certainly desirable and in fact already exists in the PVM.
I think the meeting should be about the specific API to cover the features of our preferred process language.
This is my opinion too! I think that’s what it was all about, define a common runtime and basic API, common for all languages. And every language adds on top obviously own behavior and API’s.
And I think this was a good approach and somehow proved to work, or not? -
32. Re: meeting context
Being a little provocative here. But I think that questions like this will lead to the nuts and bolts of the API and add meat to the discussion.
I think the meeting should be about the specific API to cover the features of our preferred process language.
OK, but that means the fact that JBPM4 does leverage the PVM should be transparent to the API, right? I mean it's an implementation detail then, or is it not?
So what do we got? A generic API that tries to be PDL agnostic (PVM) and the suggestion that we focus on one specific PDL and it's API?
Is this right? Can you elaborate on how these are distinguished? -
33. Re: meeting context
I also get the feeling that we get slowly to the right questions for the discussion... Let's see :-)
-
34. Re: meeting context
Yes, it seems that we all have a different understanding of "the API".
As I said earlier, I think there's actually several API's with different scope.
It will be beneficial for the discussion to get these scopes identified. -
35. Re: meeting context
[O/T]First beer, now nuts and meat... lol... The only thing missing are music (Tom, show us your drumming skills) and women.... Besides that we've had 'in Koen we trust' and now Mozes makes an appearance....people should not get a wrong impression of this meeting. [/O/T]
OK, but that means the fact that JBPM4 does leverage the PVM should be transparent to the API, right?
Transparant meaning you do not see anything in e.g. the client-api that points to the PVM? Yep, that is my impression toI mean it's an implementation detail then, or is it not?
Yep, albeit marketing wise an important one ;-)As I said earlier, I think there's actually several API's with different scope.
Was my impression to, and it was also my impression that this was Tom's idea as well, but he seems to disagree now:I think it is possible to have 1 API for all PDLs. Which would be a real achievement, given the diversity of languages that we try to cover. Let's discuss the tradeoffs in the meeting.
Well, maybe we should ask him to elaborate upfront ;-) -
36. Re: meeting context
"kukeltje" wrote:
As I said earlier, I think there's actually several API's with different scope.
Was my impression to, and it was also my impression that this was Tom's idea as well, but he seems to disagree now:I think it is possible to have 1 API for all PDLs. Which would be a real achievement, given the diversity of languages that we try to cover. Let's discuss the tradeoffs in the meeting.
Well, maybe we should ask him to elaborate upfront ;-)
I see 4 API's
1) Service API : these are the session facades that expose methods that are to be used in a persistent environment. There are 3 services in the PVM:
* ProcessService: Manages the repository of deployed process definitions
* ExecutionService: Manages the runtime process executions
* ManagementService: All operational management actions like looking at failed jobs, clean shutdown,...
In the task management component, there will be a
* TaskService: Managing task lists
All the methods of these services are surrounded with an environment block. These are similar to service operations that could be exposed as a web service or a stateless session ejb.
2) the client API : direct object access. The interface of the POJO's representing process definitions and process executions. This is used inside of the service method implementations or in case direct object access is used outside of a persistent context
3) Activity API: the Activity interface to implement the runtime activity behaviour. And the ActivityExecution that also exposes the methods on the execution to propagate the execution.
4) Event Listener API: (aka Actions) that provides access to an EventListenerExecution.
For more information see the PVM beta 1 release:
http://sourceforge.net/project/showfiles.php?group_id=70542&package_id=268068&release_id=627413"heiko.braun@jboss.com" wrote:
So what do we got? A generic API that tries to be PDL agnostic (PVM) and the suggestion that we focus on one specific PDL and it's API?
Is this right? Can you elaborate on how these are distinguished?
I have been in doubt about whether this was possible as well. My current conclusion after doing the PVM API is that it will be possible for all the common aspects which will cover everything needed for more then 80% of the projects using it:
* starting new process executions
* feeding in external signals/triggers/events
* managing process variables -
37. Re: meeting context
"heiko.braun@jboss.com" wrote:
So what do we got? A generic API that tries to be PDL agnostic (PVM) and the suggestion that we focus on one specific PDL and it's API?
Is this right? Can you elaborate on how these are distinguished?
PVM focusses on state management in a Java environment (as a java library).
Different PDLs run in a different environments. These are build on top of the PVM state management and add typically a number of build-in features. In case of BPEL that is e.g. (web) service consumption and (web) service publication. For pageflow that is specifying the next page in a JSF request.
jPDL is the language that only adds XML parsing on top of the java component technology. It's like the thinnest possible peal around the PVM. It binds the state management straight into a Java environment. That is the basics. For convenience, we'll be adding more functional node types, but that should not be confused with the core essence, which is state management in Java.
Because PVM and jPDL both target Java environments, they are close and benefit from having one single API.
Only when clients would need access to e.g. swimlanes or BPEL correlation sets. In that case you would need a process language specific API. But I believe that those are edge cases. Mostly, people only need to be able to start process instances, feed in external signals/triggers/events and manage process variables and tasks. I believe all those functionalities can easily be developed in a PDL-neutral way and that they still remain easy to use, easy to understand and convenient. -
38. Re: meeting context
1) Service API
This brings to a question I already had in mind: will Commands play a role in future? That could be one form of the API, currently this is the one if you need Remote or Async communication. Some discussions in the past gave me the expressions that a typed API is more preferred from some corners...
On the other hand I like the Commands very much for especially RichClients, and it is a crucial information if Commands will survive or not (for maintainability of existing informations). So this should maybe also thrown in the pot of discussion points around the API?
Or is there already an oppinion we can agree on upfront?
My idea would go in this direction: The Service API's are there as typed interfaces (especially for WebServices). In the implementation for every Method a Command is used, which could be also sent directly without using the API... -
39. Re: meeting context
One additional point: Is there time to discuss maybe about jPDL 4? There I remembered Tom's idea to somehow specifiy input variables in start-states or states, so interfaces to call back a process can be "automatically" exposed (like the Web-Service receive in BPEL), this would be interessting...
But maybe this is a sub-topic of variable management in jPDL at all... -
40. Re: meeting context
"camunda" wrote:
1) Service API
This brings to a question I already had in mind: will Commands play a role in future? That could be one form of the API, currently this is the one if you need Remote or Async communication. Some discussions in the past gave me the expressions that a typed API is more preferred from some corners...
On the other hand I like the Commands very much for especially RichClients, and it is a crucial information if Commands will survive or not (for maintainability of existing informations). So this should maybe also thrown in the pot of discussion points around the API?
Or is there already an oppinion we can agree on upfront?
My idea would go in this direction: The Service API's are there as typed interfaces (especially for WebServices). In the implementation for every Method a Command is used, which could be also sent directly without using the API...
The services method implementations is based on commands. In other words, the Services are just typed methods that translate into commands.
Commands are then executed by a CommandService. A chain of command services can put interceptors around the command execution. Take a look at the environment.cfg.xml in jbpm4.
So it is an extension of what we were building towards in jBPM 3. -
41. Re: meeting context
"camunda" wrote:
One additional point: Is there time to discuss maybe about jPDL 4? There I remembered Tom's idea to somehow specifiy input variables in start-states or states, so interfaces to call back a process can be "automatically" exposed (like the Web-Service receive in BPEL), this would be interessting...
But maybe this is a sub-topic of variable management in jPDL at all...
Variable management in general is a great proposal for a topic.
On the one hand, we should explore all options that we have in mind for jBPM 4, but on the other hand, we should decide on the (limited) scope for jBPM 4.0.0 and the next release in particular.
Deciding on the crucial features that we target in the next release and that should go in the scope of jBPM 4.0.0 is most important. We (mostly I) should refrain from spending a lot of time in the meeting on nice and cool ideas that are not inside of that initial scope. Let's try to find a good balance. -
42. Re: meeting context
i written an article for dzone. i think it is very relevant background for our meeting as well. it shows the 7 types of BPM as individual targets for jPDL.
https://www.jboss.org/community/servlet/JiveServlet/download/12802-4-5866/seven.forms.of.bpm.pdf -
43. Re: meeting context
Some topics I'd like to discuss:
# Start process instances at predefined time (related to Quartz and BPMN)
# Enterprise Application Integration
* eMail: send and receive - e.g. task completion via email in red hat oracle apps
* JMS: transfer data back and forth between process variables and message properties/body
* ESB: jboss and other providers - position jBPM as the de facto "scripting" language for ESBs
* Web services: borrow and improve concepts from BPEL
* Databases: facilities for accessing external databases
* Flat files: just mentioned for completeness
# Pluggable transaction management
* Internal
* CMT
* Seam/Spring
# Rules
* Rules in event actions: have rules evaluated as process events fire, or variables change
* Rule-based decision node
* Rule-based task assignment
I already added these topics to the team meeting page.