[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181638#4181638
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181638
17 years, 1 month
[Design of JBoss jBPM] - Re: meeting context
by tom.baeyens＠jboss.com
"camunda" wrote : anonymous 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181637#4181637
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181637
17 years, 1 month
Current jBPMCodeStyle.xml
by Ronald van Kuijk
Guys,
I can only find 10's of deleted ones (due to moving projects in cvs
continuously), one in a brache and one in a tag.. none in trunk. Where
is it?
Ronald
17 years, 1 month
[Design of JBoss jBPM] - Re: meeting context
by camunda
anonymous 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...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181633#4181633
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181633
17 years, 1 month
[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
17 years, 1 month
[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
17 years, 1 month
