[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"heiko.braun(a)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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181494#4181494
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181494
16 years, 3 months
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"kukeltje" wrote : anonymous 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:
| anonymous wrote : 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=26...
"heiko.braun(a)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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181488#4181488
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181488
16 years, 3 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
[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]
anonymous wrote : 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 to
anonymous wrote : I mean it's an implementation detail then, or is it not?
Yep, albeit marketing wise an important one ;-)
anonymous 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:
anonymous wrote : 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 ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181449#4181449
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181449
16 years, 3 months