Student eXchange Process Modelling and Implementation by Using an Integrated BMP-SOA Approach

One of the key processes of an open University Information System concerns managing the student exchange activities. In this paper we will try to address the challenges regarding modelling and implementation when integrating such a process by crossing different information systems. Our approach will leverage SOA architecture by using BPM in order to structure and build the service orchestration level


BMP-SOA Integrated Approach
In a previous paper [1] we proposed an integrating methodology, briefly exposed in figure 1, starting from some specific methodologies that aim to bring in the same context the SOA architecture and BMP methodologies (or reverse BMP methodologies in the context of the SOA architectures) like SOAML [2], SOMF [2] or SOMA [3].

Fig. 1. BPM-SOA Proposal workflow
According to [4], [5], there are many ways to integrate different systems.Our approach tries to gradually transform BPM specifications in RESTfull specifications in order to be implemented using some common SOA frameworks like Java's JAX-RS, going through a set of distinct stages: 1.

Setting the Business Process (BP) Model
where each BP Action should be described using design specifications that will cover: the action identifier, action type (UIX, Atomic Processing, Synchronous, Timing), action data inputs and action data output.

Setting the HTTP API from BP Action
Specifications where each BP Action will where each RESTFull Service has to be deployed and "to live" into an autonomous executable context/runtime that will allow its validation by some modular and unit tests.

BPM Service Integration and Testing
where service components will be integrated and orchestrated within a BP Platform Runtime (like jBPM, Bonita or Activity platforms) from where the initial Business Process could be executed and validated by integration tests.

Context of Student eXchange Process
In the following pages we will try to validate our BMP-to-SOA approach by implementing the above mapping guidelines into the practical context of the specific business process, targeting the integration of university information systems to support student exchange programs.This business process we have previously investigated in the larger context of University Information Systems [6].We also take in consideration that according to [7], the educational offers must face the new challenges that require flexibility, rapidity, complexity and provide students both with specific habits and efficient work tools.In order to define a concrete context for our business process, we will describe the BMP entities or actors responsible for the BP actions to be mapped by using HTTP services.• DOCX refers to Students, professors, secretary, documents and announcements.

BPM Activities
Our simplified BP model proposed for student exchange programs is described in figure 2.

Fig. 2. BP Model and actions [1]
One could easily see that the BP model for student exchange programs tries to cover those activities related not only to student registration to another university information system, but also with importing student scholar data back to original university.This cross information cycle involves in fact a challenge regarding information integration.This challenge proved to be a complex issue for any university that accesses student-exchange academic programs.

Modelling Student eXchange Process with BMP and implementation in SOA context
Starting from the ideas described by the specialized literature [8], [9], [10], [11], in the following sections we propose a set of referential specifications that anyone could use as a reusable template easily adaptable in order to produce a fully operational service architecture in the domain of student exchange program management.

BPM Action Specification
We start by formalizing those specific business process action features that will determine the actual service boundaries and parameters.
First actions concern basic READ operations to get necessary information about study programs and course details from the partner university to establish equivalences.

HTTP Action Specifications [HTTP API]
By mapping business actions from initial BP model to HTTP predicates will result a new set of specific HTTP Actions.
Table 7. Action HTTP 7: < The grades must be published to be accessed from inside and outside >, Action HTTP 8: < After the student is evaluated the grades from Partner University will be accessed>, Action HTTP 9: < After the student is evaluated the grades will be converted in different grading systems and updated into equalization system >, Action HTTP

Implementation approach of Student Exchange REST model
The structure of our business data model is designed in a way to conform to the BPM requirements of the project.To accomplish this, we needed: • a model of entity classes which are the equivalent of the tables from a database; • a repository class to manage data queries from the database using model classes; • service classes use data from database and apply specific methods for lists of data, to implement specific operations for REST resources; • resource classes which contain instances of services and the REST infrastructure.The implementation context used refers to JEE platform with JPA-ORM framework (Hibernate), JAX-RS using Jersey implementation and JAXB-OXM (Object to XML/JSON mapping) with Jackson Provider.

Specifications of REST Resource Model
The hierarchic implementation of classes is as it may be seen in figure 3 below:  According to the specialized literature [12], the resource classes will be the ones that contain our REST architecture.The REST implementation of this model means that each method will have a @GET, @POST, @PUT, @DELETE (and @Path if it's the case) annotation attached, each class will have a @Path annotation attached, and the return type of the http request using @Produces and @Consumes annotations.The specific REST annotations are included in Jersey Library, in javax.ws.rs package.The annotation @PathParam is used to get data from the URL while @QueryParam is used to get data from URL parameters.The resource classes are: • CourseResource with /courses default path sets paths and specific actions over Course objects: /courses will give the list of all courses available /courses/mainfiled will give the list of courses filtered by mainfield, and it can return results using an url parameter to filter results by semester /courses/mainfield/coursefield will return a list of courses filtered by mainfield and coursefield, and it can return results using an URL parameter to filter results by semester (see figure 5)./courses/specialty/specname/courselis t will return the list of courses for the specialty specname, and it can return results using an url parameter to filter results by semester (see figure 5)./courses with POST,PUT,DELETE actions will add, update or delete a Course object (in JSON format).• StudentResource: with /students as default path, sets paths and specific actions over Student objects: /students will return a list of all students /students/studentId will return the information about student with id studentId /students/studentId/grades will return the list of all grades for the student having id studentId (see figure 6)./students/studentId/courses will return the list of all courses for the student having id studentId and it can receive and url parameter to filter results by semester./students/studentId/equalizations will return the list of all equalizations for the student having id studentId (see figure 6)./students with POST, PUT will update or add a Student object./students/studentId with DELETE action will delete the student with id studentId.
Fig. 6.Grades for student 3 (left) and equalizations for student 2 (right) • GradeResource with /grades as the default path, sets paths and specific HTTP actions over Grade objects: /grades will return a list of all grades /grades/courses/courseName will return a list of grades for the course with name courseName (see Figure 7) /grades/studentId will return the grades for the student with id studentId (see Figure 7) /grades/studentId/equalizations will return the grades from equalization system for the student with id studentId /grades with POST, PUT and DELETE actions will add, update or delete a Student object (in JSON format).• EqualizationResource with /equalizations as the default path, sets paths and specific HTTP actions over Equalization objects: /equalizations will return a list of all equalizations with the possibility to add URL parameters to filter results by year and semester (see figure 8)./equalizations/studentId will return a list of equalizations for the student with id studentId (see figure 8).
/equalizations with POST and DELETE methods will delete the given equalization (in JSON format)./equalizations with PUT and URL parameters will update the equalization given by year, semester, studentId and equivalentCourseName with the given values for score and convertedScore.

Conclusions
In this paper we have tried to achieve two goals.On the one hand, we made an extensive effort to build a complex of services that could automate the Student eXchange activities in a process that could be useful for those universities having students involved in international programs which are searching for a way to make these management processes more effective and transparent.On the other side, we have tried to make an experimental validation of our BPM-to-SOA modelling and to develop an approach in a relevant context inspired from a real (academic) problem encountered within actual University Information Systems.
Throughout our project we have tried to follow an end-to-end approach in order to cover the most relevant and critical aspects specific to SOA architectures.Our intentions were not to build a new SOA methodology, but to show a practical way on how to complement existing SOA approaches with the advantages of BPM methodologies, tools and platforms.
Although SOA and BMP methodologies emerged and evolved in parallel, we found that they could be fully compatible to build a mix between the very declarative approach of existing BPM platforms (meaning no code … just model, at one extreme) and the very customizable approach of SOA implementing DOI: 10.12948/issn14531305/22.1.2018.04platforms (assuming complex and proprietary integration and orchestration protocols, at the other extreme).We prove that declarative (even visually) orchestration is possible for service-based actions built in a customized and extensible manner.

Fig. 3 .Fig. 4 . 1 .
Fig. 3. Hierarchic implementation of model specs The (data) model classes (located in model package within the project) are: Course, Student, Grade, Equalization Each instance of these classes represents a record into the corresponding database table.Using another class (DatabaseClass) we extract the data from the database using lists of each model class.These classes are simple implementations of Java-Beans conventions as shown in figure 4.

Listing 4 .Fig. 5 .
Fig. 5. Courses by specialty and semester (left) and by main field and course field (right)

Fig. 7 .
Fig. 7. Grades by student id (left) and by course name (right)

Fig. 8 .
Fig. 8. Equalizations by year and semester (left) and for student1 (right) 4. Business Process Integration Model Starting from the HTTP specification and implementation of Student Exchange REST model we made [1] the BPM.REST Action Model, which is based on a number of variables: Name, Request Body and Response Body.Following the specifications we create a project on jBMP platform (6.2.0 version) and we obtained the process diagram illustrated in figure 9.

Fig. 9 .Fig. 10 .Fig. 11 .Fig. 12 .Fig. 15 .
Fig. 9. BPM.REST Action Model (according to [1]) Each BPM.REST action have some parameters and parameters assignment.The common parameters are the URL of the action endpoint and for each HTTP method of request we have parameter named Method.Below we have illustrated the Action Parameters and Action Parameters Assignment under each Action.BPM.REST Action 1 [Check study program for student(SRMP)] Specifications • Action REST Resource Target (from REST Resource Model) -StudentResource • Action Parameters and Parameters Assignment

Table 1 .
Main actors from integrated systems

Table 2 .
Action 1: <With an identification number of the student, identify the courses list for the student>, Action 2: <Identify details about the courses that the student attends>, Action 3: <Get details about the courses from the partner university>, Action 4: <Compare courses details to identify the courses the student will have to attend at the partner university>

Table 3 .
Action 5:<Decide which classes a student will have to attend to have a match in the SRMP>, Action 6: <Student evaluation which will take place in the partner university>

Table 4 .
Action 7:<The grades must be published to be accessed from inside and outside>, Action 8: <After the student is evaluated the grades from Partner University will be accessed>, Action 9:<After the student is evaluated the grades will be converted in different grading systems>, Action 10: <Final Grades are inserted in parent university database >

Table 5 .
Action HTTP 1: < Identify the courses list for the student>, Action HTTP 2: < Identify details about the courses that the student attends >, Action HTTP 3: < Get details about the courses from the partner university>>, Action HTTP 4: < Compare courses details to identify the courses the student will have to attend at the partner university > DOI: 10.12948/issn14531305/22.1.2018.04

Table 6 .
Action HTTP 5: < Decide which classes a student will have to attend to have a match in the SRMP >, Action HTTP 6: < Student evaluation which will take place in the partner university >