BPRI (Business Process Runtime Interface)
I’m actively participating in defining business process related standards at OMG. One of those standards is the BPRI (Business Process Runtime Interface). The goal is to define a common interface for the execution engines produced by different vendors. Having such interface will drive more value for the users of such execution engines as it will reduce the long term cost. Further it will allow creating a new market for environments that will use those execution engines to provide further value to customers.
I think that there are several parts of such engine runtime interface:
Engine Interface
This part allows the following functionality
There are a lot of languages that can be used here - OCL, SQL, EJB QL, Hibernate QL, etc. Every language has some advantages and some disadvantages.
Standard Runtime Model
I think that this is very important information. The runtime model is not part of BPDM e.g. it is not design time data. It is equivalent in the DB World to have a standard set of tables describing runtime data. The standard should have the ability to define new tables and new columns on those entities.
For example:
Assuming that the standards defines a model class "Task" with the following properties
• TaskId: String
• Subject: String
• State: Enum {"Open", "Closed"}
• UserId: String
Here are several uses cases:
Using SQL, someone should be able to do the following:
Selecting all tasks of a specific user:
select TaskId, Subject
from Task
where UserId = 'John'
Selecting all opened tasks
select TaskId, Subject
from Task
where State = 'Open'
The same queries could be expressed in OCL.
However in order to express those queries we need standard set of classes, attributes and relationships between those classes. Without this BPRI customers don't know what to query on.
I’m actively participating in defining business process related standards at OMG. One of those standards is the BPRI (Business Process Runtime Interface). The goal is to define a common interface for the execution engines produced by different vendors. Having such interface will drive more value for the users of such execution engines as it will reduce the long term cost. Further it will allow creating a new market for environments that will use those execution engines to provide further value to customers.
I think that there are several parts of such engine runtime interface:
Engine Interface
This part allows the following functionality
- Start / Stop / Terminate Process. Someone could consider that the same functionality could be achieved using "Start Message Event" or "Terminate Event" in BPMN. However to use this functionality the process must be designed with this knowledge.
- A standard interface to execute queries and to get some results back. This is the equivalent of JDBC/ODBC in the DB world.
- Listener interfaces. For example: Every time a process or activity is started I would like an additional functionality to be invoked
- Other important engine interfaces
There are a lot of languages that can be used here - OCL, SQL, EJB QL, Hibernate QL, etc. Every language has some advantages and some disadvantages.
Standard Runtime Model
I think that this is very important information. The runtime model is not part of BPDM e.g. it is not design time data. It is equivalent in the DB World to have a standard set of tables describing runtime data. The standard should have the ability to define new tables and new columns on those entities.
For example:
Assuming that the standards defines a model class "Task" with the following properties
• TaskId: String
• Subject: String
• State: Enum {"Open", "Closed"}
• UserId: String
Here are several uses cases:
Using SQL, someone should be able to do the following:
Selecting all tasks of a specific user:
select TaskId, Subject
from Task
where UserId = 'John'
Selecting all opened tasks
select TaskId, Subject
from Task
where State = 'Open'
The same queries could be expressed in OCL.
However in order to express those queries we need standard set of classes, attributes and relationships between those classes. Without this BPRI customers don't know what to query on.

0 Comments:
Post a Comment
<< Home