6.4.1 Overview
According to the research question described in section6.2, it is the aim to evaluate if and how the OrViA framework can be used successfully as a guiding principle for a model- driven SOA implementation based on the ARIS modelling language. The case study im- plements the electronic access to the register of residents service as described in the previous section. This section describes the case study and is structured according to the three main building blocks of the OrViA framework, namely:
• structured requirements analysis (including the service discovery application)
• validation
• transformation (including the EPC to BPEL transformation application)
6.4.2 Structured Requirements Analysis
The previous manual implementation of the EARR service was directly modelled in BPEL by DVZ M-V. This modelling resulted in a very complex model, because business details as well as technical details were mixed in one model. This model was platform specific (PSM) not allowing exchanging the underlying technology. The OrViA framework instead recommends to first do structured requirements analysis on a platform independent level (PIM) and to derive the platform specific level through model transformation and stepwise refinement. This allows separating business and technical details.
To elicit the requirements, the domain experts of DVZ M-V were interviewed and the relevant laws and regulations were studied. After, a first version of the process model was created and reworked together with the domain experts of DVZ M-V in several workshops. Also, the lead developer, who created the previous implementation of EARR, was inter- viewed and the BPEL model he created was studied. The existing implementation gave additional insights so that doing the same mistakes again could be prevented. For exam- ple, in the manually created version the handling for different XMeld versions was directly included in the BPEL process.
Request Arrived Answer sent Request (600) Responsible System Answer (601) SYS Validate Request Access granted Invalid Request SYS Identify Responsible System SYS Create Answer ZIR is responsible Intermediary is responsible SYS Query ZIR SYS Forward Request to Intermediary Request (600) Validation Results Request (600) Request (600) Request (600) Answer (601) Answer (601) Answer (601) Lookup Service Answer Service
ZIR Service Intermediary
Service F O S Encryption LMG §3a F O S Encryption LMG §3a T S Encryption of Answer LMG §34a F T S
Reasons to deny Request LMG
§9 F
T S
Reasons to deny Request LMG §9 Validation Results Request Answered Validation Service SYS Log Request Answer (601) Request Documentati on Service
Temporal Operators
All Globally All Future
Figure 6.3: Example graphical validation rule for EARR process
To formally define the requirements, the ARIS modelling language was used. A ser- vice oriented business process model was created using the EPC notation. The ser- vice discovery application was used to assign a software service type to each function. The resulting model is shown in figure 6.2. The EPC notation was extended to also cover domain-specific details like annotations with the corresponding laws and regulations [SDH06,DHW08]. This helps domain experts to easily navigate from the business process model to the belonging laws or regulations. The laws and regulations describe each step in detail.
The resulting business process model is detailed enough to be transformed to BPEL using the EPC to BPEL transformation application. However, before the transformation was done, first the model was validated. The OrViA framework demands the usage of model validation to ensure that all informal requirements are correctly covered. The infor- mal and unstructured requirements are defined in the laws and regulations. The following subsection describes how validation was done.
6.4.3 Validation
The case study applied the model checking techniques introduced in subsection 2.3.4. First, the laws and regulations were analysed for possible rules. Afterwards, the rules were modelled using G-CTL. For example, it is defined that each access to the register of resi- dents must be documented. This rule is shown in figure6.3. In plain CTL, this rule is rep- resented by the follwoing expression: “AG(E_Access_granted -> AF(F_Log_Request))”. It means that on every process path (“AG”) beginning from the event “Access granted” the function “Log Request” has to exist on all paths in the future (“AF”).
The G-CTL rules as well as the EPC model were exported in the ARIS software tools’ proprietary AML format. To enable model checking, the content of the AML files was converted to the required format of the model checker SMV. The conversion was done using the operator hierarchy concept described in subsection 2.3.4. Computation of the
validation result by the model checker SMV took only a few microseconds. If a rule could not be validated, a counter example was given by the model checker.
To evaluate if G-CTL can be used by business experts, a modelling workshop with busi- ness experts was conducted. At the beginning, the G-CTL notation was introduced based on some examples. Afterwards, the business experts were asked to formalise rules given as textual description. In most cases, the business experts were able to create the correct G-CTL diagram.
6.4.4 Transformation and Execution
The validation showed that all requirements were formalised correctly. Also, the validation functionality of the EPC to BPEL transformation application issued no warnings or errors. Therefore, the EPC model was transformed into BPEL using the transformation application described in chapter5.
It was not possible to deploy directly the generated BPEL model, but instead some manual refinements were needed like fixing the variable definitions and adding additional namespaces to the BPEL header. Still, no significant reworks were needed. The BPEL process was deployed on the Oracle SOA Suite5. It was not possible to deploy the gen- erated model on Microsoft BizTalk, because BizTalk is not standard compliant. The web services were not hosted on the Oracle server, because in reality they are not hosted on the same machine either. The web services were deployed on the Java servlet container Apache Tomcat6. It was not possible to directly use the web services provided by DVZ M-
V, because of data protection reasons. Therefore, a dummy implementation was created for the web services as well as for the end user portal7. This implementation followed the implementation done by DVZ M-V.