The third functionality concerns the specific collaborative knowledge extraction and visualization functionality. We remind ourselves again here of the four actions in this functionality:
1) Extraction of knowledge by using SPARQL queries already discussed in Section 2.2.1.
2) Representation of the queried knowledge in form of collaborative process with the CPE tool, already presented in Section 2.2.2.2/b.
3) Verification of the collaborative process generated from the previous action with the involved partners.
4) Generation of a new complete collaborative process composed only of relevant objects, events, and gateways.
The two last actions have not been presented yet. Thus, the following sections are dedicated to these two last actions. We start with the third action then the generation of gateways and events of the fourth action will be presented separately.
2.2.3.1. Verification of collaborative process
The verification is to be applied to the very first collaborative process generated and visualized with the CPE (result of the second action). We defined two levels of verification:
The first level concerns the deletion of services including business services, abstract services, and MIS services. This deletion causes the automatic removal of associated flows and resources. Up to now, this level has been done manually. The CPE’s users have to work with the network participants in order to delete the relevant elements and keep only the required ones in the process. In the future, we intend to develop a graphical user interface, like a checkbox, that will allow users to make multiple selections from a list of services.
The second level concerns the sequencing of services. Here we have to take into account the meaning of flows between services in the collaborative process. We defined an algorithm to verify and bind the resources transferred between services with chain. The result of this algorithm is a suggestion of service sequencing. The CPE’s users can use this suggestion to organize services. At the current stage, this level has not been fully implemented.
2.2.3.2. Generation of gateways
The generation of gateways should be done in the last action. Why is this generation needed? The collaborative process models we visualize with the CPE come from the knowledge extracted from the KB by SPARQL query. Because we do not take into account the concept of gateway when defining the CNO of the KB, the extracted knowledge does not concern this concept.
The concept we use for generating gateway is based on dependency. Dependencies are referred to the flows of resources that are transferred between services of the enterprises. Gateway is an important modelling element of BPMN. It is used to control how flows interact as they converge and diverge within a Process [BPMN, 2004]. The extraction from the KB by SPARQL query offers the knowledge about the dependencies. Fig. IV. 35 illustrates the correspondence between dependencies and gateways:
Fig. IV. 35 Relations between dependencies and gateways
Note that the rectangle figure can represent a service, or even a gateway. The polygon figure (right side) represents only a gateway that controls multiple flows in or out. Thus, the two
patterns of dependencies (left side) concern dependencies between services, gateways, or combinations of them.
We define some transformation rules with XSLT based on these two patterns. Once the patterns match, the gateways are automatically generated. However, we can only generate the figure of gateway, not its type. We are interested in these four types of gateway:
Parallel gateway: every incoming flow is active when this gateway is used as a separator. In the case of merging, this gateway provides a token to each outgoing flow. Data-based exclusive gateway: the outgoing flows from this gateway are alternative
and conditioned. The condition test is done in order (top down) and once one of them is valid, the token is passed on. In the case of merging, this gateway lets every token pass successively.
Event-based exclusive gateway: the principle functionality of this gateway is mainly the same as the previous one, but the condition is based on an event attached to the gateway.
Data-based inclusive gateway: the outgoing flows from this gateway are conditioned. The difference from the data-based exclusive gateway is that it is possible to have more than one valid outgoing flow from the inclusive gateway, which is not the case with the exclusive gateway. In the case of merging, this type of gateway synchronizes the incoming flows and fuses the tokens simultaneously.
The type and conditions of the gateway will be manually specified by the CPE’s user because it needs to take into account the meanings of the resources containing in each flow.
2.2.3.3. Generation of events
The generation of events should be done in the last action the same as with gateways. For the same reason as gateways, the generation of events is needed.
Up to now we have only taken into account the generation of start and end events. Such generation is based on the dependency concept. We list the rules applied to this generation as follows:
If MIS service has no outgoing sequence flow (flow in the MIS), then generate a new sequence flow out from this MIS service to the end event. The figure below illustrates this rule:
Fig. IV. 36 Generation of end event
If business service of partners has no incoming message flow (flow between MIS and partners), then generate a new message flow out from this business service to the start
MIS service 1 MIS service 2 MIS service 1 MIS service 2
event and generate a new sequence flow out from the start event to the initial MIS service. The figure below illustrates this rule:
Fig. IV. 37 Generation of start event
These transformations are automatically done with XSLT. The start and end events can be empty, message, time, etc. Their types will be specified manually by the CPE’s users. However, it is possible to have intermediate event in the BPMN process. At the current stage, intermediate events needed in the process are also added manually.
3.
Conclusion of the chapter
In this chapter, we presented the prototype of our knowledge-based system to automate the specification of collaborative processes. According to Fig.IV.1, the system is composed of three main parts: knowledge gathering (left), knowledge representation and reasoning (middle), and collaborative process modelling (right).
Knowledge gathering concerns the acquisition of implicit knowledge expressed by business partners on the basis of their experiences and perspectives. We developed the Network Editor (NE) to facilitate the acquisition of knowledge and formalize this knowledge.
Knowledge representation and reasoning is the most important part of the system because it deals with the morphing of knowledge on collaboration into a collaborative process. We use the ontology-based approach (presented in theory in Chapter 3) as a means of accomplishing this second part. The Knowledge Base (KB) has been developed on the basis of such an approach and allows the deduction of collaboration patterns.
Collaborative process modelling concerns the extraction of collaborative process knowledge, and the construction of BPMN collaborative process model from the extracted knowledge. To accomplish this part, we implemented several technologies and tools. We extract the knowledge on collaborative process from the KB by SPARQL queries. This extracted knowledge is organized in the form of a collaborative process model and visualized with the Collaborative Process Editor (CPE). The complementary concepts (verification and generations of gateways and events) are also needed in this functionality. Even though the gateways and events are automatically generated, we need to re-verify the result of the generations in order to ensure that the collaborative process model is correct. This collaborative process model is BPMN-oriented, but does not yet conform to the BPMN specification. The ATL transformation is introduced to deal with this issue. The real BPMN
MIS service 1 MIS service Business service 2 Business service 1 Business service 2 Business service 1
process is visualized with the STP BPMN Modeller. This tool is provided under the Eclipse Public License (EPL).
Many technologies were integrated to build up the prototype for example, GMF, Protégé, SWRL Editor, Jess, SPARQL, Jena, Pellet, XSLT, and ATL. They were all implemented on the Eclipse platform based on Java. Java APIs have been applied to reference the programming interfaces.
The prototype was developed under the hypotheses discussed in Chapter 1. Our prototype provides the necessary knowledge (collaborative process model) to be used as the input for the works of Touzi (MISE project) and for the runtime collaborative platform of EBM WebSourcing. The main constraints for our work originated from the works of Touzi which requires the collaborative process model to be written in BPMN and to conform to the meta- model of the collaborative process (Fig.II.6). We ensure the conformity of the collaborative process model at the CPE by taking into account this meta-model when specifying the CPE’s domain model.
The prototype will be tested and validated in the next chapter with a collaborative process example.