Eindhoven University of Technology MASTER. Student SOA lab. Leijten, P.J.M. Award date: 2008

Transcription

1 Eindhoven University of Technology MASTER Student SOA lab Leijten, P.J.M. Award date: 2008 Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Download date: 15. Dec. 2017

2 Student SOA Lab P.J.M. Leijten, TU/e, Eindhoven November 10, 2008

3 ABSTRACT This thesis describes the requirements for the Student SOA Lab. It describes the concept developed from these requirements. It also contains all documentation concerning the implementation of the Student SOA Lab. Moreover it contains a manual for IBM WebSphere.

4 CONTENTS 1. Abbreviations Introduction Context of Student Labs Project Goals Project Plan Outline of the Thesis Related Projects Student SOA Lab Concept Usage/User Requirements Architecture Exercise-independent part of the Student SOA Lab Exercise-dependent part of the Student SOA Lab Case Studies Supply Chain Management System Description Requirements Required Interface Context-Components Open University System Description Requirements Required Interface Context-Components Realization of the Student SOA Lab Realization of the exercise-independent part COTS Data Model Generator/Collector Component Student-System I/O Logger Component Execution Trace Logger Component Realization of the exercise-dependent part Context-Components

5 Contents 4 7. Case Studies Implemented in Student SOA Lab Supply Chain Management System Architecture Data Model Derived Business Processes Process Descriptions per Component Test-Cases and Student SOA Lab results Open University System Architecture Data Model Derived Business Processes Process Descriptions Test-Cases and Student SOA Lab results Comparison and Future Work Appendix 91 A. SOA Development in IBM WebSphere A.1 Concepts in IBM WebSphere A.1.1 Component Hierarchy in IBM WebSphere A.1.2 SCA A.1.3 CEI A.1.4 WebSphere Integration Developer A.2 Assembly Diagram A.2.1 Components A.2.2 Interfaces A.2.3 References A.2.4 Implementations A.2.5 Data types/business Objects A.2.6 Business Object Maps A.2.7 Correlation A.2.8 Human Tasks A.3 Component Implementation Types A.3.1 Java A.3.2 WS-BPEL A.3.3 State Machine A.3.4 Human Task A.3.5 Interface Map A.3.6 Selector A.3.7 Business Rules A.4 WS-BPEL Processes A.4.1 Partnerlink/Reference Partner A.4.2 Basic Activities A.4.3 Structures

6 Contents 5 A.4.4 Error/Event Handling A.4.5 Conditions and Expressions using Java/XPath A.5 Adapters B. Detailed Description of Central Register s Operations B.1 RetrieveAllStudents Operation B.2 RetrieveAllUniversities Operation B.3 RetrieveAllCourses Operation B.4 RetrievePriorKnowledge Operation B.5 RetrieveCourseOffers Operation B.6 RetrieveStudentRegistration Operation B.7 LogExternalRegistration Operation B.8 LogPayment Operation B.9 RetrieveStudentName Operation B.10 RetrieveUniversityName Operation B.11 RetrieveCourseName Operation C. Detailed Description of the TestCaseGeneration operation D. Detailed Descriptions of Scopes used in the University Component D.1 Scopes used in Operation CourseRegistrationRequest D.1.1 CheckCourseAvailability-scope D.1.2 CheckStudentRegistration-scope D.1.3 CheckStudentsPriorKnowledge-scope D.1.4 ExaminationsCommitteeCheck-scope D.1.5 RequestPayment-scope D.1.6 CreateExternalRegistration-scope D.2 Scopes used in Operation RequestExamination D.2.1 CheckRegistrationKind-scope D.2.2 CheckPayment-scope D.2.3 CheckRegistration-scope D.2.4 CheckStudentsPriorKnowledge-scope D.2.5 CheckCourseAvailability-scope D.2.6 TeacherEvaluatesDeliverable-scope D.2.7 RegisterResult-scope E. Java Code of the Generator/Collector-Component F. Java Code of the ExecutionTraceLogger-Component G. Java Code of the GetCurrentTimeStamp-Component H. Java Code of the InputUIDRetriever-Component

7 1. ABBREVIATIONS Term BO BPEL COTS EDE IDE JDBC JMS MQ MSC QoS SCA SDO SOA UID URI WID WS-BPEL (BPEL4WS) WSDL XML XSD XSL XSLT Definition Business Object Business Process Execution Language Components Off-The-Shelf Educational Development Environment Integrated Development Environment Java Database Connectivity Java Message Service Message Queue Message Sequence Chart Quality of Service Service Component Architecture Service Data Object Service Oriented Architecture Unique Identifier Universal Resource Identifier WebSphere Integration Developer BPEL for Web Services Web Service Definition Language Extensible Markup Language XML Schema Definition Extensible Stylesheet Language XSL Transformation

8 2. INTRODUCTION 2.1 Context of Student Labs Modern information systems are constructed out of components from which ca. 80% is already available (Components Off-The-Shelf (COTS)). Computer Science students have to learn to build these systems using state of the art technology. Such projects start with requirements from which an architecture, i.e. a set of related components, is defined. Then components are selected, configured and integrated. Students need to learn the concepts behind component-based development, SOA, ESB, Web Services, etc and have to learn to construct a software system using COTS. A workflow engine, rule engine, database engine, orchestration engine, document manager are examples of generic COTS. The technologies, standards and protocols that are used for integration like SCA, SDO, XML, XSLT, WSDL, JMS, SOAP, etc. should be known by students, but students should not get stuck on technical problems caused by these technologies. Obviously the complexity that students are confronted with, when they are implementing their system, has also its effect on the task of the instructor. An instructor wants to know whether the system is correct (preferably by automatic checking and testing) and the instructor wants to be able to estimate the elegance of the solution. At this moment the instructor has no means and is dependent on the documentation and the presentation that is given by the students. Often there is no time available for an instructor to actually understand the systems of students in detail. 2.2 Project Goals In the ideal situation there would exist an educational development environment (EDE) which is easy to understand, easy-to-use and which abstracts from implementation and integration details. COTS like a workflow engine, rule engine, database engine, data warehouse, etc. should be available. This means that students would be able to design an architecture, select the components they need, configure and integrate them. Optionally students could design and implement their own components and integrate these into their system. The EDE will enable instructors, who create assignments, to set up the context of the assignment. The context will be made up from stubs and drivers. These stubs and drivers are components which will be designed and implemented

9 2. Introduction 8 by instructors. A stub is a component that is used by a student-made system and a driver is a component that uses a student-made system. The EDE should also provide means for an instructor to validate the systems of students and provide insight in these systems by showing (real-time) execution traces and data transformations. An instructor should be able to follow the actions that happen inside software components and the interactions between software components. Software development frameworks exist which provide means to develop and integrate software components, but they lack the functionality required. A suited software development framework will be selected on which the EDE will be based. This EDE implements the goals set in this project. IBM WebSphere has been selected as base development framework, because IBM WebSphere implements the concept of Service Oriented Architecture (SOA) and provides a number of generic COTS out-of-the-box. Moreover integration with other systems is supported in IBM WebSphere. The EDE will be given the name Student SOA Lab. SOA is an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcome of services.[2] A service requires input which is a request and produces output which is the response. Components that are build with the SOA-principles in mind, will act as services. The Student SOA Lab will enable students to build a (business) information system made up from components that act like services. Furthermore the Student SOA Lab will enable instructors to evaluate and simulate the systems designed by students. 2.3 Project Plan The project has been performed according to the following plan. First IBM WebSphere is tested to see whether it is suited to use in combination with the Student SOA Lab and to gain experience with IBM WebSphere; Research is required to invest whether there exist systems which resemble the Student SOA Lab. Knowledge about existing educational systems can help in the development; Elicitation of Requirements for the Student SOA Lab; The concept for the Student SOA Lab is developed. This concept must meet the requirements; Two exercises will be developed which will be used as show-cases for the Student SOA Lab; The Student SOA Lab is implemented in IBM WebSphere;

10 2. Introduction 9 The Student SOA Lab is used in the realization of the two exercises to show its capabilities; A manual for IBM WebSphere is created to give insight in the architecture, implementation process and capabilities of IBM WebSphere. The outline of the thesis will resemble the process of this project. 2.4 Outline of the Thesis In this project a prototype of the Student SOA Lab is built and the prototype is documented in this thesis. The Student SOA Lab is tested on two student exercises. Both the description of these exercises as the implementation of these exercises are documented in this thesis. In section 3 projects/systems are discussed which are comparable to the Student SOA Lab. These systems are developed for educational purposes. Then the concepts and requirements (Section 4) for the Student SOA Lab are described and explained. In section 5 two exercises for which the Student SOA Lab will be applied are described. These use cases are used to show how the Student SOA Lab can help students and instructors. In section 6 the realization of the Student SOA Lab will be described in detail. In section 7 the specific application of the Student SOA Lab on the two exercises (section 5) will be described. The implementation of the two exercises will be completely documented and results from the Student SOA Lab are presented. In section 8 the Student SOA Lab will be compared to existing educational laboratories and potential future research and opportunities will be presented. The first appendix of this document contains a manual for IBM WebSphere. This manual describes concepts used in IBM WebSphere and how it is possible to develop systems using Web- Sphere Integration Developer (WID). WID is the development environment for IBM WebSphere. It is recommended to read the IBM WebSphere manual (appendix A) before proceeding to the chapters that describe the implementation of systems. The other appendices contain the source code of components.

11 3. RELATED PROJECTS In this chapter, projects will be discussed that develop or developed systems which are comparable to the Student SOA Lab. There are multiple systems available which have an educational purpose. Two of these systems will be reviewed: Peach [3] and TALER Lab [4]. Peach (Programming Education And Contest Hosting verification system) was originally focused on programming assignments for education and contests. Later on it could be used for any kind of assignment that requires the submission of work in one or more files. Peach enables teachers to collect, store, evaluate and compare submitted work and results. There are three different users defined in Peach: students, graders and teachers. A teacher sets up an assignment in the Peach system. A teacher does this by preparing a Peach package and deploying it to the Peach system. Graders are able to view submissions, provide feedback and determine results. Students are able to join courses and/or groups, submit work and view feedback and results. There are two types of evaluation possible in Peach: automatic and manual. Automatic evaluation is meant for programming assignments. The Peach system is able to do some preprocessing on a file, compile the file and check it by executing it and compare the outputs with the inputs. Manual evaluation is an option when automatic evaluation is not. The evaluation is then left to the graders. [7] Another project with an educational purpose is the TALER (Teaching And LEarning Research) Lab. The goal of the Teaching And LEarning Research Lab (TALER) in the School of Information Sciences, University of Pittsburgh is to design, develop, and evaluate tools that can support students in learning and professors in teaching Information Science courses [4]. Technologies that are involved in some of the tool of the TALER Lab are the languages C, C++, Java and SQL. Moreover there is a tool which provides adaptive access to lecture slides, examples, quizzes and dissections (KnowledgeTree). QuickPACK (Quizzes for Parameterized Assessment of C Knowledge) is one of tools in the TALER Lab. It enables students to do web-based dynamic parameterized quizzes for programming-related courses. The idea of QuizPACK is simple. A teacher provides the core content of a question: a parameterized fragment of code to be evaluated and an expression that has to be evaluated by the student at the end of the fragment execution. The system does the rest: randomly generates a question parameter, creates a presentation of the parameterized question in a Web-based quiz, gets the student s input, compares the student s answer with the result of running the parameterized code behind the

12 3. Related Projects 11 stage, and records the results into a server-side database [5].

13 4. STUDENT SOA LAB CONCEPT The Student SOA Lab is an EDE based on existing SOA middleware, i.e. IBM WebSphere. The Student SOA Lab will be used in an educational setting to teach students to develop business information systems using SOA principles in a simplified way. Moreover, the Student SOA Lab provides means for instructors to easily understand, simulate and evaluate the system that is designed by the student. The Student SOA Lab will be defined by means of requirements. 4.1 Usage/User Requirements The Student SOA Lab has two main user groups: instructors and students. The functionality required for both groups will be described in this section. Instructors will use the Student SOA Lab for preparing a student exercise and for evaluation of student-made systems. Students will use the Student SOA Lab to build a (business) information system according to the requirements defined in an exercise, in such a way that instructors are able to evaluate the system by means of test-cases. Furthermore the Student SOA Lab enables students to use COTS and use predefined components which simulate services in the context of the exercise, provided by the instructor. Requirement 1. The Student SOA Lab must provide means for an instructor to construct exercise-dependent components (from now on referred to as contextcomponents). Some exercises require components that represent services that make up the context of an exercise. The Student SOA Lab must provide tools, which an instructor can use to construct context-components, or documentation, which gives guidelines on how to construct context-components. Requirement 2. An instructor should be able to provide input by means of test-cases for a system that is designed by students within the Student SOA Lab. The Student SOA Lab must enable instructors to manually provide test-cases or have the Student SOA Lab automatically generate test-cases. Testing is a very important part of software development. It starts with defining requirements in the form of use cases. Use cases describe processes which are executed by the users. Later in the software development process

14 4. Student SOA Lab Concept 13 test-cases can be derived from these use cases with test-cases containing inputs for the system and the expected outputs of the system for each input. Test-cases enable instructors to check whether the system behaves as intended. Students will also be able to use the test facilities provided by the Student SOA Lab. The Student SOA Lab should have an interface where the instructor can choose among different ways of providing input for evaluation and testing purposes. With input is meant the input that is delivered to a student-made system for test-case execution. The simplest way is manual input. This means that the Student SOA Lab lets the instructor provide the data that makes up the test-case input. It should be possible to provide a list of test-case inputs which are executed on a studentmade system sequentially. The other way is automatic generation of test-case input. The test-case input will have a XML-format. This input will have one or more XML-elements with each element having a data-type (integer, string, boolean, etc.). Values for these elements have to be generated by the Student SOA Lab. For each element the instructor has to be able to provide a list from which a value for the element can be taken. This list can be implicit or explicit. An implicit list is a list which is defined by given bounds. An explicit list is an actual list with a number of elements. This explicit list can be made by the instructor, but it is also possible that this list comes from a database. Requirement 3. The execution traces of test-cases executed on a student-made system, are retrieved and stored in a usable data-format. With execution trace is meant the interactions among components and if possible the actions executed within components during execution of a testcase. A usable format is a format from which easily reports can be generated. Requirement 4. An instructor should be able to (re)view inputs, outputs and execution traces of test-cases. A user interface must be available which enables the instructor to (re)view the test-case inputs, test-case outputs and the execution traces of executed testcases. In this interface a list of inputs of executed test-cases, is available to the instructor. By clicking on an input all the related data will become available to the instructor. This related data contains detailed input data, a list of outputs and a report of the execution trace. Multiple kind of reports of the execution trace are available to the instructor. The instructor will choose which kind of report will be shown. Detailed output data will become available when clicking on the output. The detailed data for inputs and outputs contains the identifier, timestamp and the data of the input/output. The detailed output data contains on top of that an error message (if any) and the (context-)component where the output came from. Requirement 5. Students should be able to select, configure and integrate the following COTS into their system: rule engine, workflow engine and database

15 4. Student SOA Lab Concept 14 engine. Optionally the following COTS should be supported: orchestration engine, data warehouse, content management system and document management system. COTS are components that contain functionality that is used by business information systems. There are domain-dependent and domain-independent COTS. Here we focus on domain-independent COTS like described in the requirement. A selection of these COTS should be available in the Student SOA Lab. The Student SOA Lab should enable students to select, configure and integrate the COTS in their system without having to worry about the implementation of these components. IBM WebSphere implements this requirement. IBM WebSphere already provides a simple rule engine, state machine and BPEL-processes. BPEL-processes can be used for the implementation of business processes (workflow engine), but can also be used for orchestration purposes. State machines can also be used for orchestration. Furthermore IBM WebSphere provides for integration with other systems using adapters (appendix A.5). So it is possible to integrate with COTS, like a data warehouse. IBM WebSphere also incorporates a JDBC adapter which makes it possible to integrate with database engines using JDBC (Java Database Connectivity). Requirement 6. Students should be able to design and implement software components themselves. Not all functionality can be fulfilled by using COTS. Sometimes there is need to design and implement a custom component. IBM WebSphere implements this requirement. In IBM WebSphere are two available technologies for the implementation of components: BPEL and Java. 4.2 Architecture The architecture of the Student SOA Lab is visually presented in figure 4.1. At the bottom, the SOA middleware can be seen. The Student SOA Lab is based upon the functionality provided by the SOA middleware. This becomes clear from figure 4.1, because the Student SOA Lab is placed on top of the SOA middleware. The Student SOA Lab consists of two parts. One part is dependent on the exercise that is given to the students, the other part is exerciseindependent. The exercise-dependent part has to be developed and implemented per exercise. These parts are described in separate sections. Students will use the functionality provided by the Student SOA Lab to build their systems Exercise-independent part of the Student SOA Lab The exercise-independent part is the part of the Student SOA Lab that is the same for each exercise. It implements requirements 1, 2, 3, 5, 6 and is required for storing the data needed for the user interfaces described in requirement 4.

16 4. Student SOA Lab Concept 15 Fig. 4.1: Concept Architecture IBM WebSphere has been selected as SOA middleware. As described in section 4.1, IBM WebSphere implements requirements 5 and 6. This functionality of IBM WebSphere can be used by the Student SOA Lab to allow the integration of COTS as described in requirement 5, and the implementation of custom components described in requirement 6, available to students. The Student-System I/O Logger component is part of the exercise-independent part. This component enables other components in the Student SOA Lab to log data. This data consists of inputs and outputs related to test-cases. The data is logged in the database. This test-case data is later used for visualization of test-cases as described in requirement 4. The exercise-independent part also contains the Generator/Collector component. The Generator/Collector implements requirement 2. This is a component that can generate test-case inputs or manually takes test-case inputs as its input and executes the test-cases on a student-made system. The input generated by the Generator/Collector or provided by the instructor and the output that is returned by the student-made system, is send to the Student-System I/O Logger, to store it in the database that is part of the exercise-independent part of the Student SOA Lab. Furthermore the independent part also contains the Execution Trace Logger component. The Execution Trace Logger component implements requirement 3. It retrieves execution trace data from IBM WebSphere. The Execution Trace

17 4. Student SOA Lab Concept 16 Logger component converts this data into a format that is usable for reporting to the instructor. The Execution Trace Logger component should be able to report real-time and also store the execution trace data in a database where this data will be linked to the input of the corresponding test-case. This enables the instructor not only to follow the execution of a system real-time but also to review execution data of test-cases that have been executed in the past. As mentioned, this part of the Student SOA Lab also contains a database which contains input data and output data of test-cases that is logged by components of the Student SOA Lab. It also contains the execution traces of test-cases. The data in this database can be used for visualization described in requirement Exercise-dependent part of the Student SOA Lab The exercise-dependent part is meant to provide the functionality required by requirement 1. This part of the Student SOA Lab will only exist if the exercise has a need for context-components. These context-components are stubs for services that would have existed if the exercise was a real-life problem. This feature of the Student SOA Lab gives the exercise designers the ability to log vital information for evaluation purposes, but also to represent services which make the exercise more realistic and/or complex. Exercise designers are completely free in designing these services using COTS and building custom components. A context-component is able to deliver information to a student-made system on request or it is possible that the exercise requires that a student-made system sends data to a context-component for evaluation purposes. It is also possible to combine these two functionalities.

18 5. CASE STUDIES Two case exercises are described which can be handed out to students. These exercises oblige students to use the Student SOA Lab. Students will use IBM WebSphere to implement their solutions to these exercises. Each exercise will require from the student to design and implement a SOAsystem which is composed of software components. Each component has an interface which lets the component act as a web service. Students are encouraged to use generic COTS. Students should use IBM WebSphere for their implementation. IBM Web- Sphere supports SOA architectures and offers some standard components like a rule group component which is comparable to a rule engine. Moreover IBM WebSphere supports BPEL and Java for implementing components. IBM Web- Sphere also supports integration with other systems like JD Edwards, People- Soft, SAP and Siebel. The following general constraints need to be respected by students for the Student SOA Lab to give good results: The student-made system will receive its input from the Student SOA Lab and eventually an output will be returned to the Student SOA Lab via a predefined interface that is part of the exercise. The Student SOA Lab acts as a driver. During execution, the student-made system might use contextcomponents which log intermediate data. It is important that after the final output is returned to the Student SOA Lab, no more interactions happen with the context-components. The reason is that intermediate outputs might otherwise be logged for the wrong test-case. The reason for this, is best given by an example. Imagine a set of test-cases which are executed sequentially. A certain test-case is being executed and it sends a final output to the Student SOA Lab, but the student-made system keeps interacting with context-components. The Student SOA Lab assumes that the test-case execution ended, because it received the final output and starts execution of the next test-case. The student-made system did not end though. By keeping interacting with the context-components, intermediate outputs might still get logged, but because another test-case already started, these intermediate outputs are logged for the wrong test-case; Students should stick to one input and one output field per operation when they design interfaces for components. If this constraint is not respected, not all communication data can be logged by the Student SOA Lab. To

19 5. Case Studies 18 compensate for this constraint, it is possible to use complex-types for the input and output fields. Reason for this described in section 6.1.3; If a component has a BPEL-implementation, the component and the BPEL-process (which is the implementation of the component) are required to have the same name. The reason for this can be found in section 6.1.5); Students are required to enable the SCA-events on the interfaces of the components they have implemented and the BPEL-events in the BPELprocesses (explanation in appendix A.1.3). In this chapter, interfaces (appendix A.2.2) and complex data-types (or business objects) (appendix A.2.5) have to be described (for example in 5.1.3). Interfaces and complex data-types are specified in WSDL (appendix A.2.2) and XSD (appendix A.2.5). In WID (appendix A.1.4), design tools are available that abstract from the details in WSDL and XSD. In this document, interfaces and data-types need to be described, but as in WID, abstraction is applied. Tables are used to describe the operations of interfaces. An operation has three different types of fields: input, output and fault. The type-column distinguishes these three types. Each field has a name which is shown in the second column and each field has a data-type which is shown in the third column. Complex data-types are also described by using tables. As in appendix A.2.5 is explained, these complex data-types can be seen as records. In a table, the different fields with their data-types are described. The first column of the table is the name of the field and the second column is the data-type. A third column can be used to describe which data is meant to be in the field. 5.1 Supply Chain Management System Description In this exercise, students will build a supply chain management system. A supply chain management system is a system that manages the supply of products among suppliers in order to fulfill a customer s needs. In this case it will be a software system that manages the supply chain. A supply chain is a chain of suppliers that supply each other with products that are sold to customers or used in the production process. There are four different types of actors in this supply chain. First we have the customers that will place orders. Then there are two types of suppliers: factories and warehouses. As fourth actor there will be a service broker. On request it provides a list of possible suppliers for a given product. This service broker will be used by warehouses, factories and customers to retrieve the suppliers that can supply the products that are needed Requirements Students must strive to incorporate the following requirements:

20 5. Case Studies 19 An interface is predefined which should be used by the student-made system and is made available to the Student SOA Lab. The input of the SCM system is a customer order. The output of the SCM System has the same fields as the input plus some additional variables that will hold the information whether the order was successfully processed or failed. The interface and input and output data-types are described in section 5.1.3; The SCM system must support multiple suppliers. Two types of suppliers must be available: factories and warehouses; Each warehouses has an inventory which holds particular set of products. Each warehouse holds a particular set of products in stock. A warehouse does not produce any products. The delivery time of a warehouse depends on the time the ordered products are available plus a fixed delay. A warehouse must keep its inventory replenished at all time; Each factory produces a particular set of products. Factories do not have an inventory. Some products might require other products as parts in the production process. A factory needs to procure these parts from warehouses to be able to start the production process. The delivery time of a factory depends on the time that all parts are available plus the time it takes to set up the production process for the product type plus the time it takes to actually produce the products; Customers and factories can only place orders at warehouses; Warehouses can place orders at factories and other warehouses; The service broker must be designed and implemented by the students. Warehouses and factories must use this service broker to retrieve the suppliers for their own orders. The SCM system incorporates the context-components described in section Students are encouraged to incorporate a data warehouse in their system, either by integrating an existing data warehouse into IBM WebSphere or by designing a simple data warehouse themselves. This data warehouse would be able to give insight in the performance of the supply chain (KPIs). It could give insight in the following metrics: Average time between an accepted order and the delivery per product type, per supplier; The number of failed orders compared to the number of accepted ones; Students are free in giving insight in other metrics.

21 5. Case Studies Required Interface An interface is predefined that the students are required to support in their system. This interface will be used by the Student SOA Lab to test the studentmade system. This interface has one operation named Order: Type Name Data-type input input OrderInput output output OrderOutput fault fault string Data-type OrderInput: Field Data-type Description SupplierId string Variable that identifies the supplier where the order is placed CustomerId string Variable that identifies the customer who placed the order ProductId string Variable that identifies the product which is ordered Quantity integer How many products are ordered The output carries the data-type OrderOutput which is defined as follows: Field Data-type Description OrderId string Variable that identifies the order SupplierId string Variable that identifies the supplier where the order is placed CustomerId string Variable that identifies the customer who placed the order ProductId string Variable that identifies the product which is ordered Quantity integer How many products are ordered Price integer Price of the order OrderSuccessfull Boolean Whether the order was successfully processed Comments string Any comments The OrderOutput contains the fields that are in the OrderInput. This is done for verification and validation purposes. It would be nice if the Comments field is used to inform the customer of the reason why the order failed if it did. The fault property of the Order operation should be used by the studentmade system to report fatal errors that might happen or to report that the order contains contradictory data if that is the case Context-Components There are two context-components for this exercise. These context-components are used for logging information that will give the instructor more insight in the student-made system and whether test-cases are executed successfully. Students are required to integrate these context-components in their systems. The first context-component is named LogInternalOrders. The component will log any internal orders that might occur. With internal orders is meant the orders that factories place for parts (that are needed for the production process) and replenishment orders by warehouses. A students-made system will invoke LogInternalOrders to let the Student SOA Lab know which internal orders occurred. The interface of LogInternalOrders has one operation which also has the

22 5. Case Studies 21 name LogInternalOrders: Type Name Data-type input input OrderOutput output Dummy string The input has data-type OrderOutput which is described in section The input will contain the data of a completed order. The output is a dummy which forces synchronous communication. This is required for the reasons described for the constraints in the introduction of chapter 5. The second context-component is named LogInventoryChanges. This contextcomponent will log the changes in the inventories of warehouses during test-case execution. Once an inventory-change occurs, the student-made system will invoke the LogInventoryChanges component. The interface of LogInventoryChanges has one operation which also has the Type Name Data-type name LogInventoryChanges: input input InventoryChange output Dummy string The output of operation LogInventoryChanges is a dummy to force synchronous communication for the same reason as for LogInternalOrders. The input has data-type InventoryChange which is defined as follows: Field Data-type Description ProductId string id of the product in the inventory of which the quantity changed SupplierId string id of the warehouse of which the inventory changed OldQuantity integer the quantity before the change NewQuantity integer the quantity after the change 5.2 Open University System Description In this exercise, students will design a system which enables students to follow any course at a university of their choice. This exercise distinguishes the following actors: students, universities, the registration committee, correctors (teachers), the bank, the course register and the central register service. General requirements: Requirements An interface will be predefined that students must integrate in their system. This interface will make it possible for the Student SOA Lab to test the student-made system. The input and output data-types of this interface are also predefined and are described in section 5.2.3;

23 5. Case Studies 22 Students are registered at one particular university, called their homeuniversity. Students are able to attend courses that are given at other universities; A university offers courses to students registered there, but also to students registered at other universities; When a student requests a registration for a course at a university which is not his home-university (named external registration), two registration committees will have to approve the external registration. One registration committee is from the home-university. The other registration committee is from the university where the student wants to follow the course; A corrector is a person employed at a university who can execute student examinations. Whenever a student is tested for a course, a corrector will judge the student s work and decide whether the student completed the course successfully; Students pay a yearly lecture fee to their home-university. The payment for an external registration is handled by the home-university and the university where the external registration was requested. A bank handles these payments among universities; The course register is used by students to retrieve available courses, universities which offer a given course and prior-knowledge which is required for a given course; The central register provides universities with certain information (section 5.2.4). The central register is implemented as a context-component; An external registration can only be approved when the student has an active registration at a university, the needed prior-knowledge and the approval of the registration committees; Students can only attend courses and do an examination for those courses at a university (which is not their home-university) if they have a valid external registration for which the payment has been handled; A student can only successfully complete a course when s/he has successfully made a test for the course. The test made by a student is evaluated by a corrector. If the corrector thinks the outcome of the test is satisfactory, this will be registered at the external registration; If a student successfully completed a course at another university, this result will be transferred to the home-university of the student; The tasks of the registration committees and correctors need to be handled in BPEL by using the human task activities;

24 5. Case Studies 23 The student-made system must use the context-component (central register) described in section Students are free to integrate a data warehouse. This data warehouse would log certain actions in the system. From these actions, certain metrics (KPIs) could be extracted: The success rate for each course; The number of external registrations for each course; The average grades for each course; Students are free in giving insight in other metrics Required Interface An interface is defined which the students are required to integrate in their system. The interface is used by the Student SOA Lab to test the studentmade system. This interface is named Student and it has one operation (also named student): Type Name Data-type input input CourseRegistrationData output output Grade fault fault string The fault must be used to report any exceptions that might occur in the student-made system to the Student SOA Lab. Data-type CourseRegistrationData is defined as follows: Field Data-type Description StudentId integer id of a student CourseId integer id of a course UniversityId integer id of a university and data-type Grade: Field Data-type Description Grade integer the grade received for the course Context-Components There is one context-component that the student-made system is required to use. The context-component is named CentralRegister. The CentralRegister can be used to retrieve all the available courses, all the universities and all the students. Moreover it can be used to retrieve the relation between courses and universities (course-offers), the relation between students and universities (registrations) and the prior knowledge required for a course. CentralRegister also logs events such as: the request of data by the student-made system and logging registered and completed payments and the creation of external registrations. Students are

25 5. Case Studies 24 Fig. 5.1: Component diagram of the CentralRegister Fig. 5.2: BPEL-implementation of how events are logged in the context-component required to use these log functions at the moment an external registration was created and when a payment is completed. This context-component is dependent on two other components: OUSContextDB and Student-System I/O Logger (figure 5.1). OUSContextDB is the database-adapter which manages communication with the database that contains the data. Student-System I/O Logger is the Student SOA Lab-component which is able to log outputs (intermediate outputs in case of a context-component). The interface of CentralRegister is named CentralRegister and has the following operations: RetrieveAllStudents; RetrieveAllUniversities; RetrieveAllCourses; RetrievePriorKnowledge; RetrieveCourseOffers; RetrieveStudentRegistration; LogExternalRegistration; LogPayment.

26 5. Case Studies 25 Fig. 5.3: ER-diagram of the database of CentralRegister The logging of events is performed in the same way for each of the operations. It is done in a scope (appendix A.4.3.1). The opened scope is shown in figure 5.2. It contains three activities. The first is an assignment which initiates the variable that will contain the event-data and it assigns the source to the eventdata. The source is the component that logs the event and in this case that is CentralRegister. The second activity is a snippet (appendix A.4.2.6), which assigns a string to a field named Data. This string contains text that describes the event that occurred. Data is a field of the input of the Student-System I/O Logger. The third activity is the activity which invokes the Student-System I/O Logger. At that moment the intermediate output is actually logged. The detailed descriptions of the operations of CentralRegister are given in appendix B Data Model The central register has a database (figure 5.3) which contains the following tables: Student, Course, University, Registration, CourseOffer and PriorKnowledge. Student contains the students that are available in the system. The following fields are defined for this table: Id (Primary Key (PK)), Name. Id is the identifier of the student and Name contains the name of the student. Course contains the courses that are available in the system. The following fields are defined for this table: Id (PK), Name. Id is the identifier of the course and Name contains the name of the course. University contains the universities that are available in the system. The following fields are defined for this table: Id (PK), Name. Id is the identifier of the university and Name contains the name of the university. Registration contains the relation between students and universities. Every student is registered at one university. The following fields are defined for this table: StudentId (PK and Foreign Key (FK)), UniversityId (PK, FK). StudentId

27 5. Case Studies 26 refers to the student. UniversityId refers the university at which the student is registered. CourseOffer contains the relation between courses and universities. A university offers one or more courses to students at a certain cost. The following fields are defined for this table: UniversityId (PK, FK), CourseId (PK, FK) and Costs. UniversityId refers to a university. CourseId refers to the course that is offered by this university. A university can occur more than once in this table. Costs contains an integer which represents the costs of a course at a university. PriorKnowledge contains the relation between courses. It is possible that a course requires prior-knowledge. Prior-knowledge is a set of courses. The following fields are defined for this table: CourseId (PK, FK) and Prerequisite- CourseId (PK, FK). CourseId refers to a course. PrerequisiteCourseId refers to a course which is required as prior-knowledge for the courses referred to by CourseId. Courses that need more than one course as prior-knowledge will occur more than once in this table.

28 6. REALIZATION OF THE STUDENT SOA LAB Readers unfamiliar with IBM WebSphere, are advised to read sections A.1 and A.2 before reading the realization of the Student SOA Lab. For the notation of complex data-types and interface operations, readers are advised to read the introduction of section Realization of the exercise-independent part The Exercise-independent part of the Student SOA Lab holds six components. We will briefly describe the purpose of each component and the interaction among the components. Every component is described in greater detail in separate sections. The Generator/Collector (section 6.1.3) takes input from an instructor. This input is data from which test-case inputs can be retrieved or generated. The Generator/Collector will execute test-cases on a student-made system using these test-case inputs. The inputs and outputs produced by a student-made system are logged by using the Student-System I/O Logger-component (section 6.1.4). The Student-System I/O Logger is, as stated above, used by the Generator/Collector to log test-cases (test-case inputs and test-case outputs). The Student-System I/O Logger is also used by context-components in the exercisedependent part of the Student SOA Lab to log relevant intermediate outputs produced by the student-made system during execution of a test-case. The Student-System I/O Logger uses the JDBC adapter component named StudentSOALabDB to get access to the database to store test-case inputs and outputs. The Student-System I/O Logger uses the Java implemented component named InputUIDRetriever to retrieve the unique identifier of the last stored test-case input to be able to relate outputs produced by the student-made system to the test-case input. The Student-System I/O Logger needs the GetCurrentTimeStamp component to get a timestamp of the current time and data in a desirable format. The Execution Trace Logger-component (section 6.1.5) is invoked by the Student-System I/O Logger to retrieve, parse and store the execution trace of a test-case. The RegisterStudentGroup component is a very simple component implemented by a BPEL process (figure 6.3) with an interface with one one-way operation that takes as input a string which should be the unique name of a student group. The RegisterStudentGroup component stores the name of the

29 6. Realization of the Student SOA Lab 28 Fig. 6.1: Architecture of the exercise-independent part of the Student SOA Lab Fig. 6.2: Components that make up the Student SOA Lab Fig. 6.3: BPEL Implementation of RegisterStudentGroup Component

30 6. Realization of the Student SOA Lab 29 Fig. 6.4: ER Diagram of the exercise-independent part of the Student SOA Lab student group in the database which enables the instructors to relate test-cases executed on the system the student group developed to this particular student group COTS COTS (Components Off-The-Shelve) are software components that are ready to use and only have to be configured and integrated. The Student SOA Lab should enable students to use a certain selection of COTS. IBM WebSphere has been chosen as a platform for the Student SOA Lab. IBM WebSphere has COTS prepacked. For example a simple rule engine, state machine and software components that can have a BPEL-implementation or Java-implementation are available in IBM WebSphere. Moreover IBM Web- Sphere provides means to integrate third party COTS using adapters (appendix A.5).

31 6. Realization of the Student SOA Lab Data Model The Student SOA Lab uses a database of which an ER-diagram is shown in figure 6.4. The Student SOA Lab database contains all the data related to test-cases. In the case of the Student SOA Lab the data that is related to a test-case, is one input, one or more outputs and the execution trace data of the test-case. The execution trace data contains the names of the components that were involved in the execution trace, the instances of those components and the different events that were emitted by these instances. Events are logged at two levels. The BPEL events which are emitted by the BPEL runtime and SCA events which are emitted by the SCA environment. The database belongs to the exercise-independent part and consists of six tables (figure 6.4): StudentGroup, Input, Output, Component, Instance, BPELEvent and SCAEvent. The table named StudentGroup contains the names of the student groups of which the system has been or must be tested by the Student SOA Lab. The StudentGroup table contains the following data field: Name (Primary Key). The Name points to the name of the group of students. The table named Input contains all the inputs that were provided manually by the instructor or generated by the Generator/Collector component. The Input table contains the following data fields: Id (Primary Key), Data, TimeStamp and StudentGroupName (Foreign Key). The Id is automatically generated and is used to identify each input. The Data field contains the input data (in a SDO-representation (section A.1)) as it was given to the student-made system. The TimeStamp field contains the date and time of when that test-case was initiated. The StudentGroupName points to the group of students whose system this input has been tested on. The Output table contains all the outputs that were retrieved from test-case execution. The Output table contains the following data fields: Id (Primary Key), Data, TimeStamp, Source and InputId (Foreign Key). The Id is automatically generated and is used to identify each output. The Data field contains the output data (in a SDO representation (section A.1)) as it was received from the student-made system. The TimeStamp field contains the date and time of when this output was received from the student-made system. The Source field contains the name of the component in the exercise-dependent part of the Student SOA Lab that was the source for the output. It could be Generator/- Collector if it is the final output of the system. It could also be the name of a component that represents a context-component and wants to log certain data for evaluation purposes. The InputId links the output to the corresponding input. The Component table contains all the components that were invoked during test-case execution. Components can occur more than once in this table, because components are stored per test-case (thus per input). This is done to be able to show which components were instantiated during test-case execution and to be able to trace the test-cases related to instances and events. The Component table contains the following data fields: Id (Primary Key), Name and InputId (Foreign Key). The Id is automatically generated and is used to identify each

32 6. Realization of the Student SOA Lab 31 component per input. The Name field contains the name of the component and the InputId links the component to the corresponding input. The Instance table contains all the instances of components during test-case execution. The Instance table contains the following data fields: Id (Primary Key), Name and ComponentId (Foreign Key). The Id is automatically generated and is used to identity each instance. The Name field contains the name of the instance and the ComponentId links the instance to the corresponding component. Two different events are logged by the Execution Trace Logger-component: BPEL and SCA events. See for more information on events and logging these events. The Execution Trace Logger-component saves the relevant event data in two tables in the database: BPELEvent and SCAEvent. The BPELEvent table contains all the events that were generated during execution of BPEL processes. The BPELEvent table contains the following data fields: Id (Primary Key), GlobalInstanceId, ExtensionName, SequenceNumber, CreationTime, ApplicationData, ActivityKind, ActivityName, Operation, FailureMessage and InstanceId (Foreign Key). The Id is automatically generated and is used to identify each BPEL-event. The GlobalInstanceId is the identifier that is given to the event by IBM WebSphere. The ExtensionName holds the name of the kind of event that was emitted. The SequenceNumber is a number which states the position of the event in the order in which events were generated. The CreationTime contains the date and time of the moment that the event was generated. The ApplicationData holds the data that was processed by the activity that emitted the event. Case application data does not exist for every BPEL-event. The ActivityKind holds the kind of activity that emitted the event and ActivityName holds the name of the activity given by the user. Operation holds the name of the operation in case the event was emitted by a receive activity. FailureMessage holds the message that describes the error in case an BPEL-activity failed. The InstanceId links the event to the corresponding instance. Not every field is used by each kind of event. Only those fields actually used by an event will have a value in the database for that particular event. The SCAEvent table contains all the events that were generated by the SCA environment during interaction of components. The SCAEvent table contains the following data fields: Id (Primary Key), GlobalInstanceId, ExtensionName, SequenceNumber, CreationTime, SourceComponent, SourceInterface, SourceOperation, SourceModule, TargetComponent, TargetInterface, TargetOperation, TargetModule, ApplicationData and InstanceId (Foreign Key). The Id is automatically generated and is used to identify each SCA-event. The GlobalInstance, ExtensionName, SequenceNumber and CreationTime have the same meaning as they do for BPEL-events. An SCA-event is an event that describes the event that one component invokes another component. The invoking component is the source and the invoked component is the target. For each component the module (SourceModule/TargetModule), name (SourceComponent/TargetComponent), interface (SourceInterface/TargetInterface), operation (SourceOperation/TargetOperation) are stored in the database. If there

33 6. Realization of the Student SOA Lab 32 is data communicated from the source component to the target component, this data is stored in the ApplicationData field. The InstanceId identifies the instance to which the SCA-event belongs. This is the instance to which the source component belongs Generator/Collector Component The Generator/Collector is a java component (Source code in appendix E) and its purpose is to test the student-made system by executing test-cases. With executing test-cases is meant: invoking the component which initiates the student-made system, and logging the input, output and execution trace of the test-case by invoking the Student-System I/O Logger. The initiationcomponent is part of the student-made system and is made available to the Generator/Collector by the export and import mechanisms which are described in section A.1.1. The Generator/Collector can be used in two ways. The first way is providing test-case inputs manually. These test-cases will be executed sequentially. This is done by using the interface operation named TestCaseManual. The second way is providing data from which test-case inputs are generated by the Generator/Collector. This is done by using the interface operation named Test- CaseGeneration. There are constraints for the interface of the student-made systems: the operation of the student-made system s interface, which is used for executing the test-cases, is allowed to have one input field and one output field. The input field and output field must have complex data-types (A.2.5), because the Generator/Collector is implemented to expect the input and output to have a complex data-type. The Generator/Collector would be even more complex if both simple and complex data-types were allowed for inputs and outputs. Another constraint is that the interface of the student-made system s component that handles the incoming test-case input, needs to be set to synchronous communication, because the Generator/Collector is not able to handle responses from asynchronous communication. The TestCaseManual and TestCaseGeneration operations rely on other functions to be able to log the inputs and outputs, these functions are described in section Furthermore the Generator/Collector depends on SDO (appendix A.2.5.1) to be able to handle the data in variables which have a complex data-type TestCaseManual Operation TestCaseManual is the operation of choice when the instructor wants to test the student-made system with pre-made test-cases. TestCaseManual is a one-way operation and therefore has no output. Operation TestCaseManual is defined as follows: Type Name Data-type input input TestCaseManualData

34 6. Realization of the Student SOA Lab 33 Data-type TestCaseManualData has the following fields: Field Data-type StudentGroupName string StudentSystemPartner string OperationName string TestCasesListName string OutputName string TestCases anytype StudentGroupName is a field that contains the name of the student group which designed the system which is tested. This variable is used to group all the test-cases that belong to one system. The StudentSystemPartner and OperationName are fields needed to be able to invoke the student-made system. The StudentSystemPartner is the name of the reference on the Generator/Collector-component, to the student-made system. The OperationName identifies the operation that is used to invoke the student-made system. The field TestCases contains the test-case input data and is a field which is of type anytype. This means that a value of any type could be assigned to this field. TestCases should be assigned a list of which the elements are test-case inputs. The elements of this list can be of any type. Because TestCases is of any type, the system does not know what the name of the list with test-case inputs is. Therefore TestCasesListName should be assigned the name of the list of test-case inputs. In this way the Generator/Collector has all the information to be able to retrieve the test-case inputs from the TestCases variable and execute them. The OutputName field should contain the name of the output field of the student-made system s operation that is invoked when executing a test-case. This is needed to retrieve the output-data produced by the student-made system. This output-data is logged by using the StudentSystemIOLogger. TestCaseManual s implementation has the following steps: First an java-object is created which represents the student-made system. This is needed to be able to invoke the student-made system. Then for each element in the list of test-case inputs the following is done: The element is retrieved from the list. Remember that this element is a test-case input. The test-case input is logged by using the LogInput function. After that the student-made system is invoked with the input and the output produced is logged by using the LogOutput function. LogInput and LogOutput are described in section TestCaseGeneration Operation TestCaseGeneration is the operation of choice when the instructor wants to have the Generator/Collector generate test-cases. TestCaseGeneration is a one-way operation and therefore has no output. The instructor has to provide data out of which the Generator/Collector can generate test-case inputs. Operation TestCaseGeneration is defined as follows:

35 6. Realization of the Student SOA Lab 34 Type Name Data-type input input TestCaseGenerationData Data-type TestCaseGenerationData has the following fields: Field Data-type StudentGroupName string StudentSystemPartner string OperationName string NameType string NamespaceType string TestCaseAmount integer OutputName string TestCaseData FieldDataList StudentGroupName is a field that contains the name of the student group which designed the system which is tested. This variable is used to group all the test-cases that belong to one system. The StudentSystemPartner and OperationName are fields needed to be able to invoke the student-made system. The StudentSystemPartner is the name of the reference to the student-made system. The OperationName identifies the operation that is used to invoke the student-made system. Because the input of the student-made system is generated, the Generator/- Collector needs to know which type the input of the student-made system is. To be able to instantiate a variable of the data-type that is required by the input of the student-made system, the name and the namespace of this data-type have to be given. The fields NameType and NamespaceType exist for this purpose. The TestCaseAmount is required by the Generator/Collector to know how many test-cases have to be generated. The OutputName field should contain the name of the output field of the student-made system s operation that is invoked when executing a test-case. This is needed to retrieve the output produced by the student-made system to be able to log the output. TestCaseData contains the data that is necessary to generate test-case inputs. The Generator/Collector does not know what the input of the studentmade system s input looks like, nor does it know what the actual data is. The TestCaseData must contain the data from which the Generator/Collector can construct test-case inputs. To be able to generate inputs for the student-made system, it is required that the input has a certain format. The Generator/- Collector can generate inputs for which the input data-type has the following specifics: A student-made system s input data-type can have one or more fields. These variables can be simple data-types, complex data-types, simple data-type lists and complex data-type lists. Complex data-types can be nested. FieldDataList has the following field: Field Data-type FieldDataList list of FieldData

36 6. Realization of the Student SOA Lab 35 FieldData is a type that is meant to hold all the information to enable the Generator/Collector to assign a value to each field of the student-made system s input. This means that FieldDataList has an element for each field that the data-type of the test-case input has. FieldData has the following fields: Field Data-type Name string Type integer ListSize integer StringList StringList StringLists list of StringList IntegerList IntegerList IntegerLists list of IntegerList LowerBound integer UpperBound integer BooleanLists list of BooleanList ComplexTypeList ComplexTypeList ComplexTypeLists list of ComplexTypeList Data-type StringList: Field Data-type StringList list of string Data-type IntegerList: Field Data-type IntegerList list of integer Data-type BooleanList: Field Data-type BooleanList list of boolean StringList, IntegerList and BooleanList might look superfluous, but this has to do with SDO and DataObjects (appendix A.2.5.1). SDO does not easily handle lists. SDO handles DataObjects which can contain a list. For that reason these lists are contained in a DataObject. The Name field in the FieldData data-type will contain the name of the test-case input s field that a value has to be assigned to. Type determines the type of the field and also how the field will be constructed to have an appropriate value. The following types are available: 0: The type of the field is string. The string value is randomly selected from the StringList field. 1: The type of the field is integer. The integer value is randomly selected from the IntegerList field. 2: The type of the field is integer. The integer value is randomly selected from the integer domain specified by the fields LowerBound and Upperbound.

37 6. Realization of the Student SOA Lab 36 3: The type of the field is boolean. The boolean value is randomly selected. 4: The type of the field is complex. The complex typed value is randomly selected from the ComplexTypeList field. 5: The type of the field is a list of strings. The list is randomly selected from the StringLists field. 6: The type of the field is a list of integers. The list is randomly selected from the IntegerLists field. 7: The type of the field is a list of booleans. The list is randomly selected from the BooleanLists field. 8: The type of the field is a list of complex typed elements. The list is randomly selected and constructed from the ComplexTypeLists field. 9: The type of the field is a list of strings. The list is randomly composed from elements in the StringList field. The list will have the size specified in the field ListSize. 10: The type of the field is a list of integers. The list is randomly composed from elements in the IntegerList field. The list will have the size specified in the field ListSize. 11: The type of the field is a list of integers. The list is randomly composed from the integer domain specified by the field LowerBound and Upperbound. The list will have the size specified in the field ListSize. 12: The type of the field is a list of booleans. The list is randomly composed. The list will have the size specified in the field ListSize. 13: The type of the field is a list of complex typed elements. The list is randomly composed from elements in the ComplexTypeList field. The list will have the size specified in the field ListSize. As becomes clear from the type description, depending on which type the field is, certain fields in FieldData are used to assign a value to the field of the test-case input. It is possible to nest complex data-types and because these also have to be composed randomly, additional data-types are required to be able to construct these nested complex data-types. ComplexTypeList is made for generating complex-typed values and used in the FieldData data-type for this purpose. ComplexTypeList is a data-type which is made to contain data that is used to construct complex-typed values for nested fields (in the test-case input). ComplexTypeList has one field with also the name ComplexTypeList: Field Data-type ComplexTypeList list of ComplexType Generation

38 6. Realization of the Student SOA Lab 37 ComplexType Generation is a data-type which is made to contain the data to generate one complex-typed value. ComplexType Generation: Field Data-type FieldList List of FieldData NameComplexType string NamespaceComplexType string The recursive nature of constructing values for fields becomes clear from the table describing ComplexType Generation. FieldList is a list of FieldData. So again it is possible to generate values for fields nested in a complex-typed field. The NameComplexType and NamespaceComplexType are fields needed to initialize a DataObject (appendix A.2.5.1) of the required data-type. The implementation of TestCaseGeneration is described in greater detail in appendix C Java logging functions The Generator/Collector contains in its implementation four functions which are needed to be able to log the inputs and outputs of test-cases. These are four functions of which two functions have the same name. This function name is overloaded. An overloaded function (name) is a set of functions with the same name. Different input parameters are required to identify the functions. The names of these functions are LogInput, LogOutput and ParseDataObject. LogInput is the function which is used to log test-case inputs. LogInput requires as its input parameters a DataObject, named InputData, and a string, named StudentGroupName. The DataObject represents the test-case input which needs to be logged. The string is required to be the name of the student group. So it is known to which student group s system this test-case relates. The LogInput operation of the Student-System I/O Logger component is invoked to log the input. LogOutput is used to log the outputs which are produced by the studentmade system. LogOutput is overloaded and has two different implementations. The first one requires as its input parameter a DataObject, named OutputData. The DataObject represents the test-case output which needs to be logged. The second implementation requires as its input parameter a string, also named OutputData. The first and second implementation are very similar. The first implementation is used when a student-made system executes the test-case and returns an output which is a DataObject. In the second implementation the data to be logged, is a string. A student-made system does not return a DataObject when it fails to execute the test-case. In that case the exception message (which is a string) is logged. In both implementations the LogOutput operation of the Student-System I/O Logger component is invoked to log the output. The ParseDataObject function returns a string representation of DataObjects. The input parameter is a DataObject, named DO and the return type

39 6. Realization of the Student SOA Lab 38 of ParseDataObject is a string. ParseDataObject is used by the LogInput and LogOutput functions to be able to get a complete string representation of the inputs and outputs which have to be logged. ParseDataObject is required, because of the possibility that inputs and outputs of student-made systems have nested complex-typed fields. A DataObject has a function which returns a string representation of the DataObject. The problem here is that if the DataObject has complex-typed fields, the actual data of these complex-typed fields is not shown. ParseDataObject is a recursive function and reaches into the DataObject to also retrieve a string representation of nested complex-typed fields Student-System I/O Logger Component The Student-System I/O Logger (named StudentSystemIOLogger in the implementation) is a component that has a BPEL-implementation. The Student- System I/O Logger is used by the Generator/Collector to log test-case inputs and test-case outputs. The Student-System I/O Logger is also used by contextcomponents to log outputs which are produced by the student-made system during execution of a test-case. The Student-System I/O Logger also logs the execution traces of test-cases. As shown in figure 6.2 the Student-System I/O Logger depends on four other components: The StudentSOALabDB-component is a JDBC adapter which makes it possible for a component to invoke a database system. This particular adapter makes it possible for the Input/Output Logger to actually store input and output in the database. This database is described in section 6.1.2; The InputUIDRetriever-component (source-code in appendix H) is a Javacomponent (component with a Java implementation) that retrieves the unique identifier (UID) of the last test-case input that was stored in the database. The UID is needed to link outputs and execution flow data to test-case inputs. It was decided to let the database generate unique identifiers for test-case inputs, because databases have mechanisms included for this purpose. This means that it is not necessary to include a generator of identifiers in the Student SOA Lab; The Execution Trace Logger (section 6.1.5) is a Java component that retrieves the execution trace data and converts this into a usable format before storing this data in the database; The GetCurrentTimeStamp-component (source-code in appendix G) which constructs a timestamp of the current time and data in the format: dd- MM-yyyy HH:mm:ss. This timestamp is returned to the invoking component which is the Student-System I/O Logger. The Student-System I/O Logger component has an interface with two operations: LogInput and LogOutput.

40 6. Realization of the Student SOA Lab 39 Fig. 6.5: BPEL Implementation of the Input/Output Logger

41 6. Realization of the Student SOA Lab 40 Operation LogInput: Type Name Data-type Input input LogInputDataType Output dummy string LogInput has one input with data-type LogInputDatatype: Field Type Data string StudentGroupName string The LogInput operation should only be invoked by the Generator/Collectorcomponent. Every test-case has one input. This means that the UID of an input also uniquely identifies the corresponding test-case. The LogInput operation requires as input, the input data that corresponds to the data that was used to initiate the student-made system and a StudentGroup- Name which identifies a student-group. The StudentGroupName is needed to group all the test-cases that were run on the system of this particular studentgroup. After the LogInput has been invoked the branch in the BPEL-implementation that corresponds to this operation will be executed. The GetCurrentTimeStamp-component will be invoked to retrieve a timestamp of the current time and date. The input-data will then be stored in the database together with the timestamp and StudentGroupName by using the StudentSOALAbDB-adapter. Also the ClearCEIEvents operation of the Execution Trace Logger is invoked to make sure that the CEI (Common Event Infrastructure) data-source is empty and only events of the current test-case will be in the CEI data-source when the test-case execution ends. Operation LogOutput: Type Name Data-type Input input LogOutputDataType Output dummy string LogOutput has one input with data-type LogOutputDatatype: Field Type Data string SourceComponent string LogOutput is an operation that is invoked by the Generator/Collector and by the context-components in the exercise-dependent part of the Student SOA Lab. The Generator/Collector invokes this operation when the final output of the student-made system is received. The LogOutput operation can also be used by context-components defined in the exercise-dependent part of the Student SOA Lab to store output from intermediate results. After the final output has been received by the Generator/Collector, the student-made system should have no more instances of components running that possibly have context-components log intermediate outputs. Otherwise it is possible that output data is stored linking to the wrong test-case, because

42 6. Realization of the Student SOA Lab 41 another test-case has already been started. (A new UID has already been generated in that case.) If the identifier of a test-case input was part of the input of the Student-System I/O Logger, this constraint would not be necessary. The advantage of the current design is that components that use the Student-System I/O Logger are not concerned with linking test-case outputs to the right testcase input. If the constraint, stated above, is respected, all test-case outputs are related to the right test-case input automatically. The fields of LogOutputDataType are described: the variable named Data represents the output data produced by a student-made system. The Source- Component is the name of the component that wants to store the output. This can be the Generator/Collector or the name of a context-component defined in the exercise-dependent part of the Student SOA Lab. After the LogOutput operation has been invoked, the corresponding branch of the BPEL-process is executed. The first action in this branch is retrieving the UID of the last-logged input by invoking the InputUIDRetriever-component. The UID is required to relate the output-data to the right test-case (which is identified by the UID of the last-logged input). Then a timestamp is requested from the GetCurrentTimeStamp-component. Then the SourceComponent, output-data, timestamp and UID are stored in the database using the StudentSOALabDB-adapter. If the source-component is the Generator/Collector component it means that the execution of the current test-case has ended and the execution flow of the last test-case needs to be logged, parsed and stored in the database. So the Execution Trace Logger-component is invoked with the UID of the last test-case as input Execution Trace Logger Component The requirements for the Student SOA Lab mention the ability to retrieve traces of the test-case executions (requirement 3). Multiple options were investigated for this purpose. One of the options was to build a component which would process all the communication among the different student-build components and pass on the requests and responses from these student-build components. This component would act as a proxy for all communication. The advantage of this solution is that it is independent of SOA middleware, but it has setbacks. The component would have a very complex implementation to be able to process all communication. It would be a strain on the students, because they would have to integrate this component in all the interactions of the components in their system. It is difficult for students to start designing and implementing an information system in an environment (i.e. IBM WebSphere) which is completely new to them. On top of that having students integrate a component which would parse all communication, is not helping. Especially because IBM WebSphere provides a built-in service (CEI) which can be easily used for exactly this purpose without burdening students. The only setback is that the Student SOA Lab is dependent on IBM WebSphere for this service. The Execution Trace Logger retrieves event-information from the CEI that

43 6. Realization of the Student SOA Lab 42 is supported by IBM WebSphere. More information on the CEI is in appendix A.1.3. The Execution Trace Logger-component has a Java implementation and has two operations available. (Source code in appendix F.) The first operation of the Execution Trace Logger is named ClearCEIDatasource and is used to clear the CEI data-source to make sure no events of other executions exist. This first operation has one input and one output. This operation is only used to trigger the Execution Trace Logger. There is no relevant data communicated from and to the Execution Trace Logger. The second operation is named RetrieveEvents. This operation has one input and one output. The input has the name UID which contains the unique identifier of the test-case input to which the execution trace belongs. RetrieveEvents retrieves all the events from the CEI data-source. The events are parsed and stored in the database related to the input with identifier UID (section 6.1.2). The RetrieveEvents operation has a more complex implementation. RetrieveEvents can be split into four parts: 1. A connection to the CEI data-source is established; 2. The events are parsed. Every event (BPEL or SCA-event) is emitted by an instance of a certain component. A tree-like structure is constructed where instances are related to components and events are related to instances; 3. Relevant properties of events are retrieved from the XML document by using the JDOM 1.1 for Java library. Which properties are retrieved for BPEL and SCA-events is described in 6.1.2; 4. All the gathered information about events is stored in the database. So all the components which were invoked are stored. The instances of these components are stored and the events emitted during execution of these instances are stored. Using foreign keys the relations among components, instances and events are stored. This makes it possible to report on testcases. There are two constraints on student-made systems to make sure that the events are logged in the right way: BPEL-processes and the components they belong to, should have the same name. This is needed, because BPEL-events are generated by the BPELprocess, while SCA-events are generated by the component. If a component and its BPEL-process have different names, it is impossible to relate the SCA-events and BPEL-events. Interfaces of the components in the student-made system are required to have one input and in case it has output, one output. If this constraint is not respected, the application data of SCA-events does not contain all data. It is assumed that the CEI is dedicated to the student-made system that is being tested by the Student SOA Lab, because at the end of a test-case

44 6. Realization of the Student SOA Lab 43 Fig. 6.6: Architecture of the exercise-dependent part of the Student SOA Lab execution the events that are retrieved from the CEI data-source are assumed to be only from the student-made system that is tested by the Student SOA Lab. Another constraint is that only one instance of the Execution Trace Logger can run at one time. If this is not respected, the CEI data-source could be emptied at a moment the execution of a test-case would still be going on and not all events for a test-case would be retrieved at the end of the execution. Actually the Execution Trace Logger component should only be invoked by the Student-System I/O Logger, because then the Execution Trace Logger is invoked with the right operations at the right moments of a test-case execution. 6.2 Realization of the exercise-dependent part The exercise-dependent part of the Student SOA Lab contains one or more context-components Context-Components Context-components are components which are designed to represent third party services in an exercise and/or are needed to log intermediate results using the Input/Output Logger component. Instructors are not restricted by the Student SOA Lab in developing contextcomponents. The Student SOA Lab provides the possibility to log intermediate results (outputs) by using the Student-System I/O Logger. At this moment there are no tools for instructors to help them with the specific task of designing and implementing context-components.

45 7. CASE STUDIES IMPLEMENTED IN STUDENT SOA LAB In this chapter the implementations of the two exercises described in chapter 5 are described. There are minor discrepancies between the implementations and exercise descriptions, because both exercises have been improved after the implementations were completed. The figures of the system architectures have the following meaning. The blocks represent components and the cylinders represent databases. An arrow between a component A and a component B means that component A can invoke component B. Human interactions are represented by human-shaped figures. 7.1 Supply Chain Management System This implementation of a supply chain management system is an implementation of the exercise described in section 5.1. The system described here, does not implement all the requirements of the exercise exactly as they were described in the exercise. Instead of the OrderInput and OrderOutput data-types that are defined for the system s interface (section 5.1.3), the data-type Order is used which has the same specification as OrderOutput. Another difference is that warehouses only order at factories instead of both warehouses and factories. The service broker described in the exercise is here named UDDI Architecture The SCM system has four types of actors: customers, warehouses, factories and the UDDI. The system has components that represent the factories, warehouses and the UDDI. The customers will be triggering this system by putting orders into the system. The architecture of the SCM system is shown in figure 7.1. The system will have multiple factories and multiple warehouses. The various suppliers (factories and warehouses) can invoke each other. All the suppliers can invoke the UDDI. Factories produce products. Factories do not have an inventory where they store products. For the production of a process, a factory might need parts, which are other products. The factory can order the parts only at warehouses. A factory uses the UDDI to find the warehouse which supplies the products it needs. The production process can begin when all parts are delivered. When the production process is successfully completed, the order is delivered. Warehouses cannot produce products. A warehouse has an inventory in which products are stored. Warehouses need to check their inventories regularly

46 7. Case Studies Implemented in Student SOA Lab 45 Fig. 7.1: Architecture of the SCM system

47 7. Case Studies Implemented in Student SOA Lab 46 Fig. 7.2: ER-diagram of the SCM system and make sure that the inventory has a certain amount of each product at all times. Warehouses can place orders at factories. A Warehouse finds the factory which produces the products it needs by using the UDDI. The UDDI is able to return a list of suppliers of a certain kind (warehouse or factory) that can supply a certain product. The system supports quotations, which means that a customer can check how much an order is going to cost before the order is actually placed. Both the warehouses and factories have the functionality to handle quotations Data Model The ER Diagram in figure 7.2 shows the database tables that have been designed for this system. The architecture of the SCM system suggests that each warehouse, each factory and the UDDI have their own databases. In the implementation it is decided that one database is used by all the components to reduce the workload. The database contains five tables: Supplier, Product, Produces, Inventory and Dependency. One view was created named ProducesRelationOverview. The Supplier table contains all the suppliers which are available in the system. The following fields are defined for this table: Id (Primary Key (PK)), Name, Type, Address, Phone, City and Country. Id is an identifier which is unique for each supplier. The Name field contains the name of the Supplier. The Type field says which type of supplier the supplier is. The available types are Factory and Warehouse. The rest of the fields is not used in the implementation. The Product table contains all the products that are available in the SCM system. The following fields are defined for this table: Id (PK), Name and Description. Every product has a unique identifier which is stored in the Id field. The Name field contains the name of the product. The Description field contains a description of the product. In the implementation this field is ignored.

48 7. Case Studies Implemented in Student SOA Lab 47 The Produces table defines the relation between suppliers and products. The following fields are defined for this table: SupplierId (PK and Foreign Key (FK)), ProductId (PK, FK) and Price. SupplierId refers to a supplier. ProductId refers to a product. The price field says how many the product costs at this supplier. The Inventory table contains for every warehouse which products it contains and the quantities of those products. The following fields are defined for this table: SupplierId (PK, FK), ProductId (PK, FK), Quantity and Economic- Quantity. SupplierId refers to the warehouse. ProductId refers to the product. The Quantity field says how many of the product referred to by ProductId, are contained in the inventory of the warehouse that is referred to by SupplierId. The EconomicQuantity says how many of the products referred to by ProductId, are ordered but not yet delivered. The Dependency table holds the recipe information. Some products require other products as parts in the production process. The following fields are defined for this table: ProductId (PK, FK), DependencyId (PK, FK) and Quantity. The ProductId refers to a product. The DependencyId refers to a product which is needed in the production of the product that is referred to by ProductId. The Quantity says how many of the product referred to by DependencyId, are needed in the production process. It is possible that multiple types of products are needed in the production process of a product Derived Business Processes Figure 7.3 shows what has become of the architecture shown in figure 7.1 when it is implemented in IBM WebSphere. There are four BPEL implemented components: Factory, UDDI, Warehouse and WarehouseReplenishment. The Factory component contains the functionality of the Factory component in the architecture. The UDDI component also holds all the functionality as it was intended for the UDDI component in the architecture. The Warehouse and WarehouseReplenishment components together are the Warehouse component in the architecture. Although there is only one Factory component, one Warehouse component and one WarehouseReplenishment component, the system does support multiple warehouses and factories. To lower the workload the decision was made to let the components dynamically act as the supplier the order was sent to. So if an order was sent to a factory named factory1, the Factory component will act as factory1. Factory DB, UDDI DB and Warehouse DB are JDBC adapters (adapters that make communication possible with a database via JDBC). All these adapter components are adapters for the same database. Multiple adapters were made to resemble the architecture which shows a separate database for each supplier and UDDI. The OrderQuotationRouter component is a component which routes the quotations and orders to the right component. For example if an order is meant for a factory (any factory), the OrderQuotationRouter will be able to route the order to the Factory component.

49 7. Case Studies Implemented in Student SOA Lab 48 Fig. 7.3: Component-diagram of the SCM system

50 7. Case Studies Implemented in Student SOA Lab 49 Fig. 7.4: BPEL-implementation of the UDDI component The StudentSystem component is an SCA export component (appendix A.1) which makes it possible for the Student SOA Lab to test this SCM system. LogInternalOrders and LogInventoryChanges are BPEL-implemented components that are described in the exercise-description (section 5.1). These context-components are integrated in the system to log vital information for the Student SOA Lab. The StudentSystemIOLogger is the import of the Student- System I/O Logger component that is part of the Student SOA Lab This component is used by the context-components for logging purposes. InventoryReplenishmentConstants and UDDISupplierType are components that contain business rules for this system. InventoryReplenismentConstants is used by the WarehouseReplenishment component to know when a product needs to be replenished and what the quantity of the replenishment order will be. UDDISupplierType is used by the Factory component and the Warehouse- Replenishment component. This component contains the rules which say at which supplier type a supplier can order. For example if a factory invokes this component, it will get as response that it is allowed to order only at warehouses Process Descriptions per Component UDDI UDDI (BPEL-implementation in figure 7.4) has an interface with one operation named Inquiry that is defined as follows: Type Name Data-type input input Inquiry Input output output Inquiry Output fault fault string Data-type Inquiry Input:

51 7. Case Studies Implemented in Student SOA Lab 50 Field Product Id Supplier Id Data-type string string Data-type Inquiry Output: Field Data-type Suppliers list of Supplier Data-type Supplier: Field Data-type Id string Name string Type string Address string Phone string City string country string The UDDI receives a product identifier and a supplier type as input. The UDDI DB adapter is used to retrieve all the suppliers that supply that product and match the supplier type. A list of suppliers is retrieved from the database. This list is in a format that is different from the output type of the UDDI. A mapping is created which maps the output from the database adapter to the output of the UDDI Factory Factory (BPEL-implementation in figure 7.5 and contents of scope 1 in figure 7.6) has the interface named Supplier which has two operations: Order and Quotation. Order (operation): Type Name Data-type input input Order output output Order fault fault string Data-type Order: Field Data-type OrderId string SupplierId string CustomerId string ProductId string Quantity string Price string Comments string Operation Quotation:

52 7. Case Studies Implemented in Student SOA Lab 51 Fig. 7.5: BPEL-implementation of the Factory component

53 7. Case Studies Implemented in Student SOA Lab 52 Fig. 7.6: Contents of Scope1 in the Factory process

54 7. Case Studies Implemented in Student SOA Lab 53 Type Name Data-type input input Quotation output output Quotation fault fault string Data-type Quotation: Field Data-type OrderId string SupplierId string CustomerId string ProductId string Quantity string Price string Comments string First is described what happens when the Quotation operation is invoked. The product is retrieved together with the price it costs. The total price of the order is calculated and assigned to the price field in the Quotation. If the factory does not supply the product that was in the Quotation a fault is generated and the process terminates. The Order operation of the Factory component is more complex. When an Order is received by the Factory component, first is checked if the product is actually produced by this factory. If not, a fault is generated and the process terminates. If so, the process continues to checking parts for the production process. The dependencies are retrieved for the ordered product. Dependencies are the products that are needed in the production of the ordered product. The next step is to order the dependencies. The following steps are repeated for each dependency: Retrieve the warehouses that can supply the dependency using the UDDI ; Send a quotation to each warehouse that can supply the dependency; Then, as long as the list of warehouses is not empty and the dependency is not delivered, an order is sent to the warehouse with the lowest quotation. If the order fails, the next warehouse with the lowest quotation is tried. If the list with warehouses is empty, the entire process fails. If the order succeeds, the dependency will be delivered and this order will be logged using the LogInternalOrders component. If all the dependencies are received by the factory, it is ready to start production of the ordered products. If the production process ends, the order is completed and a confirmation is returned to whoever placed the order Warehouse Warehouse (BPEL-implementation in figure 7.7) also has the Supplier interface which has been described in the last section.

55 7. Case Studies Implemented in Student SOA Lab 54 Fig. 7.7: BPEL-implementation of the Warehouse component

56 7. Case Studies Implemented in Student SOA Lab 55 The Warehouse component handles the Quotation operation the same as the Factory component. If the Order operation of the Warehouse component is invoked, first is checked whether the warehouse can supply the product in the Order. If not, an error is generated and the process terminates. If so, the inventory is checked to see if it is sufficient for the order. If not, again an error is generated and the process terminates. If the inventory has sufficient stock, the inventory will be updated, because the products ordered will be removed from the inventory and the order will be completed. A inventory change will be logged using the LogInventoryChanges component. A confirmation of a successful order is returned to whoever placed the order. This is done after replenishment, because the Student SOA Lab requires that a student-made system does not continue execution after sending the final output (section 5) WarehouseReplenishment WarehouseReplenishment s BPEL-implementation is visible in figure 7.8 with the contents of Scope1, Scope2 and Scope3 in figure 7.9, figure 7.10 and figure 7.11 respectively. WarehouseReplenishment has the interface named Replenish with one operation (also named Replenish): Type Name Data-type input input string output output string The input in the Replenish operation is required to be the identifier of the warehouse which requires replenishment. The WarehouseReplenishment component will replenish the products that need it. The WarehouseReplenishment component will for each product of the warehouse, perform the following steps: Check whether the product needs replenishment, by checking the quantity of the product with the order rule. If the product quantity is sufficient, these steps are executed for the next product. If not, the next steps will be performed; Update the economic quantity of the product, because at this moment the component will be trying to make an order and replenish the product; Find factories that produce the product using the UDDI ; To each factory that can produce the product a quotation is sent; Then, as long as the list of factories is not empty and the product is not delivered, an order is sent to the factory with the lowest quotation. If the order fails, the next factory with the lowest quotation is tried. If the list with factories is empty, the replenishment of the product fails and the next product in the inventory will be checked. If the order succeeds, the product will be delivered and this order will be logged using the LogInternalOrders

57 7. Case Studies Implemented in Student SOA Lab 56 Fig. 7.8: BPEL-implementation of the WarehouseReplenishment component

58 7. Case Studies Implemented in Student SOA Lab 57 Fig. 7.9: Contents of Scope1 in the WarehouseReplenishment process component. Also the inventory will be updated. This will be logged by invoking the LogInventoryChanges component Test-Cases and Student SOA Lab results In this section, results from executing test-cases with the Student SOA Lab are presented. A number of test-cases were executed using the manual test operation and the automated test operation of the Student SOA Lab. The inputs of these test cases are presented in this section together with (a part of) the results that were collected by the Student SOA Lab. Not all results might be shown, because it might be overwhelming. For example for a test-case can exist over 70 SCA-events Manual Test-Case A test-case, using the manual test operation of the Student SOA Lab, is presented in this section. The input given to the Generator/Collector using operation TestCaseManual (section ): StudentGroupName ( s t r i n g ) : SCM S t u d e n t S y s t e m P a r t n e r ( s t r i n g ) : S u p p l i e r P a r t n e r OperationName ( s t r i n g ) : Order TestCasesListName ( s t r i n g ) : O r d e r L i s t OutputName ( s t r i n g ) : o u t p u t TestCases ( anytype ) : O r d e r L i s t ( Order [ ] ) : O r d e r L i s t [ 0 ] ( Order ) :

59 7. Case Studies Implemented in Student SOA Lab 58 Fig. 7.10: Contents of Scope2 in the WarehouseReplenishment process

60 7. Case Studies Implemented in Student SOA Lab 59 Fig. 7.11: Contents of Scope3 in the WarehouseReplenishment process OrderId ( s t r i n g ) : Order1 S u p p l i e r I d ( s t r i n g ) : W002 CustomerId ( s t r i n g ) : P i e t P r o d u c t I d ( s t r i n g ) : P005 Quantity ( i n t e g e r ) : 10 P r i c e ( i n t e g e r ) : Comments ( s t r i n g ) : The notation represents the data that is the input for the Generator/Collector. This input has fields and nested fields for the complex-typed fields. The field names are presented on the left side of the colon. Between brackets is stated the data-type of the field. Indents are used to show nested fields of complex data-types like Order. Order[] means that the data-type of OrderList is a list of elements which have data-type Order. OrderList[0] means that it is the element on the 0th place of the list. On the right side of the colon is given the actual data. Fields which are empty after the colon, have no data (null). The test-case input that was logged to the database by the Generator/Collector using the Student-System I/O Logger: Id Data TimeStamp StudentGroupName 201 BusinessObject: Order@51c051c (OrderId=Order1, SupplierId=W002, CustomerId=Piet, ProductId=P005, Quantity=10, Price=0, Comments=) :24:50 SCM The following outputs (intermediate and final) were logged by the Student- System I/O Logger:

61 7. Case Studies Implemented in Student SOA Lab 60 Id Data TimeStamp Source 611 BusinessObject: :24:51 LogInventoryChanges (ProductId=P005, SupplierId=W002, OldQuantity=302, NewQuantity=292) 612 BusinessObject: :24:51 LogInternalOrder (OrderId=W002 ReplenishmentOrder, SupplierId=F003, CustomerId=W002, ProductId=P003, Quantity=100, Price=300, Comments=Order Successful) 613 BusinessObject: :24:52 LogInventoryChanges (ProductId=P003, SupplierId=W002, OldQuantity=264, NewQuantity=364) 614 BusinessObject: :24:53 LogInventoryChanges (ProductId=P004, SupplierId=W002, OldQuantity=371, NewQuantity=271) 615 BusinessObject: :24:55 LogInventoryChanges (ProductId=P003, SupplierId=W002, OldQuantity=364, NewQuantity=164) 616 BusinessObject: (OrderId=W002 ReplenishmentOrder, SupplierId=F003, CustomerId=W002, ProductId=P003, Quantity=100, Price=300, Comments=Order Successful) :24:55 LogInternalOrder

62 7. Case Studies Implemented in Student SOA Lab 61 Continued: Id Data TimeStamp Source 617 BusinessObject: :24:55 LogInventoryChanges (ProductId=P003, SupplierId=W002, OldQuantity=164, NewQuantity=264) 618 BusinessObject: :24:56 LogInternalOrder (OrderId=NewOrder, SupplierId=W002, CustomerId=F001, ProductId=P003, Quantity=200, Price=1000, Comments=Order Successful) 619 BusinessObject: :24:56 LogInternalOrder (OrderId=W002 ReplenishmentOrder, SupplierId=F001, CustomerId=W002, ProductId=P004, Quantity=100, Price=1800, Comments=Order Successful) 620 BusinessObject: (ProductId=P004, SupplierId=W002, OldQuantity=271, NewQuantity=371) :24:56 LogInventoryChanges

63 7. Case Studies Implemented in Student SOA Lab 62 Continued: Id Data TimeStamp Source 621 BusinessObject: :24:56 LogInternalOrder (OrderId=NewOrder, SupplierId=W002, CustomerId=F003, ProductId=P004, Quantity=100, Price=2000, Comments=Order Successful) 622 BusinessObject: :24:57 LogInternalOrder (OrderId=W002 ReplenishmentOrder, SupplierId=F003, CustomerId=W002, ProductId=P005, Quantity=100, Price=2100, Comments=Order Successful) 623 BusinessObject: :24:57 LogInventoryChanges (ProductId=P005, SupplierId=W002, OldQuantity=292, NewQuantity=392) 624 BusinessObject: (OrderId=Order1, SupplierId=W002, CustomerId=Piet, ProductId=P005, Quantity=10, Price=230, Comments=Order Successful) :24:57 GeneratorCollector These outputs are intermediate outputs logged by the context components which were defined for the SCM-exercise and the final output which was logged by the Generator/Collector. By which component the output was logged can be seen in the Source column. For this test-case there were also 70 SCA-events retrieved from the CEI,

64 7. Case Studies Implemented in Student SOA Lab 63 Fig. 7.12: Part of the MSC of the test-case with input identifier 201

65 7. Case Studies Implemented in Student SOA Lab 64 and parsed by the Execution Trace Logger component. Listing 70 events is overwhelming, but from these events it is possible to draw a Message Sequence Chart (MSC). In figure 7.12 the first part of this MSC is visible. The MSC in figure 7.12 is made by hand from a list of SCA-events, but it is possible to generate these charts automatically. The components involved in the test-case execution are shown in the blocks on top. The vertical lines below the blocks represent time-lines. Going down along a line is going forward in time. An arrow pointing from component A to component B means that component A invoked component B at that moment in the time. A striped arrow from component B to component A is a response from component B on an invocation by component A. A red response-arrow means that a fault was returned. The text on an arrow is the name of the operation that was used. For reasons of readability, abstraction has been applied to the MSC: instances of components are ignored. In the MSC only components are visible. On the IBM WebSphere Process Server, multiple instances of a component can exist. In figure 7.12 the interactions of various instances of the same component are connected to the same time-line Automated Test-Case Generation In this section it is presented how the Generator/Collector can be used to generate test-case inputs for the SCM-system. The input given to the Generator/Collector using operation TestCaseGeneration (section ): StudentGroupName ( s t r i n g ) : SCM S t u d e n t S y s t e m P a r t n e r ( s t r i n g ) : S u p p l i e r P a r t n e r OperationName ( s t r i n g ) : Order NameType ( s t r i n g ) : Order NamespaceType ( s t r i n g ) : h t t p : / / SCMLib TestCaseAmount ( s t r i n g ) : 1 OutputName ( s t r i n g ) : o u t p u t TestCaseData ( F i e l d D a t a L i s t ) : FieldDataList ( FieldData [ ] ) : F i e l d D a t a [ 0 ] : Name ( s t r i n g ) : S u p p l i e r I d Type ( i n t e g e r ) : 0 L i s t S i z e ( i n t e g e r ) : S t r i n g L i s t ( S t r i n g L i s t ) : S t r i n g l i s t ( s t r i n g [ ] ) : S t r i n g L i s t [ 0 ] ( s t r i n g ) : F001 S t r i n g L i s t [ 1 ] ( s t r i n g ) : W001 S t r i n g L i s t [ 2 ] ( s t r i n g ) : W002 S t r i n g L i s t s ( S t r i n g L i s t [ ] ) : I n t e g e r L i s t ( I n t e g e r L i s t ) : I n t e g e r L i s t s ( I n t e g e r L i s t [ ] ) : LowerBound ( i n t e g e r ) : UpperBound ( i n t e g e r ) : BooleanLists ( BooleanList [ ] ) : ComplexTypeList ( ComplexTypeList ) : ComplexTypeLists ( ComplexTypeList [ ] ) : F i e l d D a t a [ 1 ] : Name ( s t r i n g ) : P r o d u c t I d Type ( i n t e g e r ) : 0 L i s t S i z e ( i n t e g e r ) : S t r i n g L i s t ( S t r i n g L i s t ) : S t r i n g l i s t ( s t r i n g [ ] ) : S t r i n g L i s t [ 0 ] ( s t r i n g ) : P001 S t r i n g L i s t [ 1 ] ( s t r i n g ) : P004 S t r i n g L i s t [ 2 ] ( s t r i n g ) : P003 S t r i n g L i s t s ( S t r i n g L i s t [ ] ) : I n t e g e r L i s t ( I n t e g e r L i s t ) : I n t e g e r L i s t s ( I n t e g e r L i s t [ ] ) : LowerBound ( i n t e g e r ) : UpperBound ( i n t e g e r ) : BooleanLists ( BooleanList [ ] ) : ComplexTypeList ( ComplexTypeList ) : ComplexTypeLists ( ComplexTypeList [ ] ) :

66 7. Case Studies Implemented in Student SOA Lab 65 F i e l d D a t a [ 2 ] : Name ( s t r i n g ) : Quantity Type ( i n t e g e r ) : 2 L i s t S i z e ( i n t e g e r ) : S t r i n g L i s t ( S t r i n g L i s t ) : S t r i n g L i s t s ( S t r i n g L i s t [ ] ) : I n t e g e r L i s t ( I n t e g e r L i s t ) : I n t e g e r L i s t s ( I n t e g e r L i s t [ ] ) : LowerBound ( i n t e g e r ) : 30 UpperBound ( i n t e g e r ) : 41 BooleanLists ( BooleanList [ ] ) : ComplexTypeList ( ComplexTypeList ) : ComplexTypeLists ( ComplexTypeList [ ] ) : One test-case input was generated by the Generator/Collector and logged using the Student-System I/O Logger: Id Data TimeStamp StudentGroupName 197 BusinessObject: Order@2bb62bb6 (SupplierId=F001, ProductId=P001, Quantity=35) :44:07 SCM For this test-case also exist intermediate outputs and a final output similar to those listed in section For this test-case were also the events in the CEI retrieved and parsed by the Execution Trace Logger and stored in the database.

67 7. Case Studies Implemented in Student SOA Lab 66 Fig. 7.13: Architecture of the OUS system 7.2 Open University System This implementation of an open university system is an implementation of the exercise described in section 5.2. The system described here does not implement all the requirements exactly as stated in section 5.2. There is only one registration committee that needs to approve an external registration instead of two registration committees. This is the registration committee of the university at which the student requested to follow a course. Another difference is that payments for external registrations involve the student. In the exercise these payments are settled between universities Architecture The system (architecture in figure 7.13) has seven actors: student, course register, university, teacher, examinations-committee, bank and the central register. The system supports multiple students and universities. The Central Register is a context-component which means that it is predefined as part of the exercise (section 5.2.4). This system makes it possible for students to follow courses on universities different from their home-university. A university must make it possible for students from other universities to request a registration for a course (external registration). Students that have an external registration or have a normal registration should be able to do

68 7. Case Studies Implemented in Student SOA Lab 67 Fig. 7.14: ER-diagram of the OUS system examinations for courses. A university must be able to transfer a result which has been achieved by a student on a different university. At last, a university must be able to receive payments from the bank that are done by students to be able to follow courses for which an external registration exists. The bank has two tasks. First it must be possible for universities to request payments. This is needed to enable students to pay for an external registration. Then it must be possible for students to pay for an external registration at the bank. The course register provides students with course-information. Students can find all the courses that are available, at which universities these courses are taught and which prior-knowledge is required to be able to start a course. The teacher is a person which evaluates examinations of students for a certain set of courses. In the system the teacher s task is implemented as a human-task. A human-task is a BPEL-activity (chapter A.4.2.8). The examinations-committee is a committee which handles requests for external registrations. This is also implemented as a human-task Data Model More than one university is supported by the system. Every university would have its own database in a realistic setting. In this implementation it was decided that there exists one database that is used by all the universities. This reduces the workload, but does not reduce the functionality of the system. The database (figure 7.14) that is used by the OUS system contains three tables: Result, ExternalRegistration and Payment. The Result table contains all the results from students. The following fields are defined for this table: CourseId (Primary Key(PK)), UniversityId (PK), StudentId (PK), Successful, Grade. CourseId refers to the course which the student followed. UniversityId refers to the university where the student followed the course. StudentId refers to the student who followed the course. Successful is a boolean which is set to true when the student successfully completed the course and Grade is the grade that the student got for his examination of the course. The Payment table contains the payments of courses. Payment is only accessible by the bank. The bank registers and completes payments. A payment is completed when the payment is received by the bank. The following fields are defined for this table: Id (PK), ClientId, Amount and Fulfilled. Id identifies a

69 7. Case Studies Implemented in Student SOA Lab 68 Fig. 7.15: Component-diagram of the OUS system payment and is automatically generated when a payment is registered. ClientId refers to the university which requested the registration of payment. Amount is the amount that has to be payed and Fulfilled is set to true when a payment is received. The ExternalRegistration table contains the external registrations. An external registration is created when a student successfully registers for a course on a university different from his home-university. The following fields are defined for this table: CourseId (PK), UniversityId (PK), StudentId (PK), PaymentId (FK), PaymentFulfilled, Successful and Grade. CourseId refers to the course the student follows. UniversityId refers to the university where the course is followed. StudentId refers to the student that follows the course. PaymentId refers to the payment that needs to be payed to enable the student to actually complete the course. PaymentFulfilled is set to true when the bank lets the university know that the payment was completed. Successful is set to true when the student successfully completes the course and Grade is the grade that the student got for his examination Derived Business Processes Figure 7.15 shows the component-diagram of the OUS system in IBM Web- Sphere. The components Student, University, Bank, Course Register, Teacher, Examinations Committee implement the functionality as described for the components in figure These components are described in greater detail in separate sections. Central Register is the context-component which depends on the components StudentSystemIOLogger and OUSContextDB. Central Register is predefined as context-component and described in section There are several other components visible in the component-diagram: StudentExport, RetrieveLastPaymentId and OUSDB. StudentExport is an SCA export component (appendix A.1) of the Student component. This makes it possible for the Student SOA Lab to invoke the OUS system. RetrieveLastPaymentId is used by the Bank component to retrieve the iden-

70 7. Case Studies Implemented in Student SOA Lab 69 tifier of a payment. The identifier (saved in the Id-field in the Payment table in section 7.2.2) is automatically generated by the database at the moment a payment is stored in the database. The only way to retrieve this identifier is by using a separate component with a Java-implementation. The OUSDB is the database-adapter that makes it possible for components to use the database Process Descriptions Student The Student component has an interface which is also named Student. This interface contains one operation (named student) and this operation is defined as follows: Type Name Data-type input input CourseRegistrationData output output Grade fault fault string Data-type CourseRegistrationData: Name Data-type StudentId integer CourseId integer UniversityId integer Data-type Grade: Name Data-type Grade integer The Student component represents a student and executes the steps a student would execute if he wants to follow a course at a certain university. The first step is to request an external registration at the university where the student wants to follow the course. This is done by invoking the CourseRegistrationRequest-operation of the University component. This activity has three possible outcomes. The first possibility is the request fails. This can happen if the prior-knowledge of the student is insufficient or the university does not teach that particular course. In this case the Student component generates a fault with the same message as it received from the university and the process terminates. Another possibility is that the student is requesting an external registration at his home-university. In this case a different fault is generated by the University component, because an external registration is unnecessary at a home-university. A boolean-variable is set to represent that the student is trying to follow a course at his own university. A payment is unnecessary, because courses can be followed freely at a home-university. The third possible outcome is that the external registration is successfully registered. The boolean-variable remains set to representing that the student wants to follow the course at a university different from his home-university. This boolean-variable was initialized in the assignment-activity named Initialization.

71 7. Case Studies Implemented in Student SOA Lab 70 Fig. 7.16: BPEL-implementation of Student

72 7. Case Studies Implemented in Student SOA Lab 71 The next step is paying for the external registration. This is done in a choicestructure, because the payment is only necessary if an external registration was successfully registered. If the student is following the course at his homeuniversity, this is unnecessary. In the choice-structure are two activities: a assignment which assigns the input for the invocation of the Bank and the invocation of the Bank itself. This invocation represents the student paying for his external registration. Then there is a assignment named Assign DeliverableRequest. Here a booleanvariable named Successful is initialized to false. This variable represents the fact that the student successfully completed the course. A while-structure is placed after the assignment. The body of the while-structure is being executed until Successful is set to true. The boolean-variable can be set to true in the body of the while-structure. The first activity in the body of the while-structure is a human-task (appendix A.4.2.8). The human-task has the following interface (one operation): Type Name Data-type input input string output Deliverable string An user-interface is generated for this human-task where the user will see the input and must provide the Deliverable. The input is initialized with the text Please send in deliverable!. The generated user-interface lets the user fill in a string which will be saved in Deliverable. Then an examination is requested at the university by invoking the RequestExamination-operation of the University component s interface. The input for this invocation is assigned in an assignment-activity before the invocation. The input is the deliverable retrieved by the human-task together with the input of the Student component. The output of RequestExamination is the grade of the deliverable given by the corrector. Next is a choice-structure. The choice has a case with a condition that evaluates to true if the grade given by the corrector is six or higher. In that case an assignment-activity is executed and the variable Successful is set to true. Otherwise the variable remains false and the student will have to send in a new deliverable until the deliverable is evaluated with a grade that is six or higher. The last assignment-activity assigns the grade to the output of the Student component. The reply-activity sends the output out and ends the process Course Register Course Register has an interface named Course Register. The interface has three operations: RetrieveCourses, RetrieveUniversities and RetrieveNeeded- PriorKnowledge. RetrieveCourses: Type Name Data-type input Dummy string output CourseList CourseList Data-type CourseList:

73 7. Case Studies Implemented in Student SOA Lab 72 Fig. 7.17: BPEL-implementation of Course-Register

74 7. Case Studies Implemented in Student SOA Lab 73 Field CourseList Data-type list of Course Data-type Course: Field Data-type Id integer Name string RetrieveCourses retrieves a list of all the courses that are available. The operation RetrieveAllCourses from the context-component Central Register is used to retrieve all the courses. An invocation of RetrieveAllCourses is required for this. Before the invocation an assignment-activity is placed where the input of the invocation is initialized. The invocation of RetrieveAllCourses retrieves a list of courses which is immediately ready to be send out as the output of this operation. Operation RetrieveUniversities: Type Name Data-type input CourseId integer output UniversityList UniversityList Data-type UniversityList: Name Data-type UniversityList list of University Data-type University: Name Data-type Id integer Name string RetrieveUniversities retrieves a list of universities. Each university in that list offers the course from which the identifier is given as the input of the operation. The context-component Central Register can return a list of courses which are offered by a university (operation RetrieveCourseOffers). We have to use this operation to construct the list of universities requested. First a list of all universities is retrieved by invoking the RetrieveAllUniversities-operation of the Central Register component. Then in a foreach-structure is for each university checked whether the course is offered by that university. Before the body of the foreach-structure is entered, a variable of the data-type UniversityList is initialized. First the courses are retrieved which are offered by the university that is currently handled in the loop of the foreach-structure. This is done by invoking the RetrieveCourseOffers-operation of the central register after assigning the input of this operation. A list of courses is returned. A new foreach-structure loops through the course-list. For each course is checked whether the identifier of the course is equal to the identifier given as input to the RetrieveUniversities-operation. This is done in a choice-structure. If the identifiers of the courses are equal, it means that the university offers the course. This means that the university must be added to the list of universities

75 7. Case Studies Implemented in Student SOA Lab 74 Fig. 7.18: BPEL-implementation of the CourseRegistrationRequest-operation of the University component which is at the end of the process send out as output University The University component implements the functionality described for the university. It has an interface named University which contains four operations: CourseRegistrationRequest, CourseResultTransfer, RequestExamination and ReceivedPayment. Scopes (appendix A.4.3.1) are used in the implementation of the operations CourseRegistrationRequest and RequestExamination, because the processes would otherwise be too overwhelming. Scopes can be used to group activities and hide them. The operations are described in greater detail. The first operation is CourseRegistrationRequest (figure 7.18). Operation CourseRegistrationRequest is defined as follows:

76 7. Case Studies Implemented in Student SOA Lab 75 Type Name Data-type input input CourseRegistrationRequest Input output output CourseRegistrationRequest Output fault fault string fault OwnUniversityFault string Data-type CourseRegistrationRequest Input: Field Data-type CourseRegistrationData CourseRegistrationData Data-type CourseRegistrationData: Field Data-type StudentId integer CourseId integer UniversityId integer Data-type CourseRegistrationRequest Output: Field Data-type PaymentId integer Costs integer CourseRegistrationRequest is used by students, if they want to follow a course at a university which is different from their home-university, to request an external registration. There are a number of checks which have to be executed and passed for a student to get an external registration. The checks are (in the order that they are executed): The course which the student wants to follow must be offered by the university at which the student wants to get an external registration. The external registrations of the student are checked. In the cases that the student is not registered at all, an exact same external registration already exists or the student requests an external registration at his homeuniversity, the process returns a fault and terminates. Otherwise the request passes the check. The prior-knowledge of the student is checked. If the prior-knowledge is insufficient, a fault is returned and the process terminates. The last check is the examinations committee which examine the previous results of the student and decide whether the external registration is accepted. In case all the checks are passed, a payment is requested by the university at the bank. Then the external registration is registered in the database. The identifier of the payment and the costs of the course are returned to the student as output. The BPEL-implementation of CourseRegistrationRequest (figure 7.18) has six closed scopes of which the first four scopes correspond to the checks described

77 7. Case Studies Implemented in Student SOA Lab 76 Fig. 7.19: BPEL-implementation of the CourseResultTransfer-operation of University before: CheckCourseAvailability, CheckStudentRegistration, CheckStudentsPriorKnowledge, ExaminationsCommitteeCheck, RequestPayment and CreateExternalRegistration. The opened scopes are visible in figures D.1, D.2, D.3, D.4, D.5 and D.6 in appendix D.1. Detailed descriptions of the scopes implementations are also available in this appendix. CourseResultTransfer (figure 7.19) is the next operation of the university which will be described in detail: Type Name Data-type input input CourseResultTransfer Input output Dummy string fault fault string Data-type CourseResultTransfer Input: Name Data-type CourseRegistrationData CourseRegistrationData Grade integer Data-type CourseRegistrationData is described in section CourseResultTransfer is used between universities to transfer a result when a student has successfully finished a course at a different university than his/her home-university. This operation is used by the university where the course was finished. The university that executes this operation is the university which is the home-university of the student. First there is an assign-activity which will assign the input that is required later for the invocation of the database-adapter that stores the result in the database. This input contains the course-registration-data, the grade and a boolean variable named successful that says whether the course was successfully completed. The second activity is a snippet-activity which contains one statement that is a choice-statement. If the grade is six or higher, successful will be assigned true. Otherwise successful will be assigned false. Now the input for the invocation is ready and the database-adapter OUSDB is invoked to store the result in the database. This completes the description of the CourseResultTransfer-operation. The

78 7. Case Studies Implemented in Student SOA Lab 77 Fig. 7.20: BPEL-implementation of the RequestExamination-operation of University next operation that will be described in detail, is RequestExamination (figure 7.20). Operation RequestExamination is defined as follows: Type Name Data-type input input RequestExamination Input output Grade integer fault fault string Data-type RequestExamination Input: Field Data-type Deliverable string CourseRegistrationData CourseRegistrationData Data-type CourseRegistrationData is described in section RequestExamination is like CourseRegistrationRequest quite overwhelming when seen in its whole. Therefore again scopes are used to group activities and improve understandability. RequestExamination is used by students when they want to send in their examination for a course. It can be used by students which have an external registration or by students who just want to do an examination for a course at their home-university. In the CheckRegistrationKind-scope is decided whether there exists an external registration for the examination. After the scope there is a choice-structure with a case and a otherwise. The case has a condition which tests whether there was an external registration present. In this case there has to be checked whether

79 7. Case Studies Implemented in Student SOA Lab 78 Fig. 7.21: BPEL-implementation of the ReceivedPayment-operation of University the payment has been done, because a payment is required to be able to finish a course. Other checks are not necessary, because there exists an external registration and all checks have been done before an external registration is created. If there was not an external registration present, the otherwise branch in the choice-structure will be taken. This means that there is no external registration for the examination, but it is possible that the student wants do an examination for a course at his home-university. This is checked in the CheckRegistrationscope. If this check is successful, it is checked whether the prior-knowledge of the student is sufficient in the CheckStudentsPriorKnowledge-scope and whether the course is actually offered at the university in the CheckCourseAvailabilityscope. If these checks are successful, a teacher will evaluate the deliverable that was send in by the student in the TeacherEvaluatesDeliverable-scope. Then the result is stored. This is done in the RegisterResult-scope. For detailed descriptions of the scopes implementations, see appendix D.2. This concludes the description of RequestExamination. There is one operation of the University component left to describe. This last operation is ReceivedPayment and is defined as follows:

80 7. Case Studies Implemented in Student SOA Lab 79 Fig. 7.22: BPEL-implementation of the Teacher component Type Name Data-type input input ReceivedPayment Input output Dummy string fault fault string Data-type ReceivedPayment Input: Field Data-type PaymentId integer UniversityId integer The ReceivedPayment-operation (figure 7.21) is used by the Bank component to let a university know that a payment for an external registration has been received. First the external registration that carries the same payment-identifier as the payment-identifier in the input, is retrieved by invoking the adaptercomponent OUSDB. The input for this invocation is assigned in an assignment. The input for the OUSDB is the payment-identifier and the university-identifier. It is possible that the invocation of the OUSDB returns a fault. This is if there are no external registration or more than one external registrations retrieved in the database. In that case a fault is returned by the university and the process terminates. If one external registration is returned by the database, the process continues to the next invocation of the OUSDB which is an update of the external registration. This update sets the paymentfulfilled-variable of the external registration to true. This means that the payment for the external registration has been received. The last step of the implementation of ReceivedPayment, is logging the received payment by invoking the LogPayment-operation of the central register. The input for the central register is assigned in an assignment and contains only the payment-identifier. This concludes the description of the ReceivedPayment-operation and the University component in its whole Teacher The Teacher component (figure 7.22) is invoked by the university if an examination of a deliverable is required. Teacher has an interface that is also named Teacher. This interface contains one operation named RequestEvaluation. Re-

81 7. Case Studies Implemented in Student SOA Lab 80 Fig. 7.23: BPEL-implementation of the Examinations-Committee component questevaluation is defined as follows: Type Name Data-type input Deliverable string input CourseName string output Grade integer fault fault string The BPEL-implementation of Teacher is very simple. There are three activities. The first is the receive-activity which receives the deliverable which needs to be evaluated and the name of the course. The second activity is a humantask (appendix A.4.2.8). This human-task has the same interface as the Teacher component. The reply-activity is the last activity and returns the grade that was given by the teacher, to the invoking university Examinations-Committee The ExaminationsCommittee component (figure 7.23) is invoked by the university if a request for an external registration is received, to request the evaluation of the external registration by the examinations-committee. This component has an interface that also carries the name ExaminationsCommittee. This interface has one operation named RequestExaminationCommitteeEvaluation: Type Name Data-type input input1 StudentFile input input2 Course output Grade integer fault fault string Data-type StudentFile is described for operation CourseRegistrationRequest in section Data-type Course is described in section The BPEL-implementation of the ExaminationsCommittee component is similar to the implementation of the Teacher component. It contains three activities: the first activity receives the student-file which contains the name of the student and the student s result-history, and the name of the course for which the student wants an external registration. The second activity is a human-task which requests the approval for the external registration from the

82 7. Case Studies Implemented in Student SOA Lab 81 Fig. 7.24: BPEL-implementation of the Bank component examinations-committee based on the student-file. A boolean-variable which contains the response from the examinations-committee, is returned to the invoking university Bank The Bank component (figure 7.24) implements the functionality that is required for the bank in the OUS system. This includes two tasks: registering payments which means that if an external registration is created for a student, this student needs to pay for this external registration. In that case the university requests a payment-registration at the bank. The student must complete this payment before he can do an examination for the course. The second task of the bank is

83 7. Case Studies Implemented in Student SOA Lab 82 receiving payment from students for external registrations. The Bank component has an interface named Bank. The Bank-interface has two operations: RegisterPayment and MakePayment. The RegisterPaymentoperation implements the first task of the bank. RegisterPayment is defined as follows: Type Name Data-type input input RegisterPayment Input output PaymentId integer fault fault string Data-type RegisterPayment Input: Field Data-type Amount integer ClientId integer The operation receives as input an amount which is the height of the payment and identifier of the client which is the identifier of the invoking university. There are two steps in the implementation of RegisterPayment. The first step is storing the payment in the database. This is done by two activities: The first activity is an assignment which assigns the input for the invocation of the database-adapter OUSDB. This input consists of the height of the payment (amount), the identifier of the client and a boolean-variable named fulfilled which is initialized to false. Fulfilled represents whether the payment has been completed. The second activity is actually invoking OUSDB to store the payment. The second step is obtaining the payment identifier which has been generated by the database. This is done by invoking the RetrieveLastPaymentId component which retrieves the last-generated identifier and returns it. This payment-identifier is returned to the invoking university by a reply-activity. The MakePayment-operation implements the second task of the bank and is defined as follows: Type Name Data-type input PaymentId integer output Dummy string fault fault string The operation receives as input a payment-identifier which is the identifier of the payment that has been payed. The implementation of MakePayment consists of two steps: The first step updates the database that a payment was completed. This step contains two activities. The first activity is an assignment which assigns the input for the invocation of OUSDB. This input is the identifier of the payment and true to the boolean-variable fulfilled which means that the payment was completed. The second activity is the actual invocation of OUSDB which updates the database. It is possible that the payment-identifier does not exist in the database. In that case the update will fail, a fault is generated and the process will terminate. The second step is informing the university which registered the payment, that the payment is completed. First an assignment assigns the input of an invocation of OUSDB. This input is

84 7. Case Studies Implemented in Student SOA Lab 83 the payment-identifier. Then the invocation is executed which will return the identifier of the university. The last part is informing the university. This consists of two activities. An invocation of the ReceivedPayment-operation of the university after an assign-activity that assigns the input for the invocation. The input consists of the payment-identifier and the university-identifier. This concludes the description of the description of the Bank component Test-Cases and Student SOA Lab results In this section, results from executing test-cases with the Student SOA Lab are presented. A number of test-cases were executed using the manual test operation and the automated test operation of the Student SOA Lab. The inputs of these test cases are presented in this section together with (a part of) the results that were collected by the Student SOA Lab. Not all results might be shown, because it might be overwhelming. For example for a test-case can exist over 70 SCA-events Manual Test-Case Two test-cases, using the manual test operation of the Student SOA Lab, are presented in this section. The input given to the Generator/Collector using operation TestCaseManual (section ): StudentGroupName ( s t r i n g ) : OUS S t u d e n t S y s t e m P a r t n e r ( s t r i n g ) : S t u d e n t P a r t n e r OperationName ( s t r i n g ) : s t u d e n t TestCasesListName ( s t r i n g ) : CourseRegistrationDataList OutputName ( s t r i n g ) : o u t p u t TestCases ( anytype ) : CourseRegistrationDataList ( CourseRegistrationData [ ] ) : CourseRegistrationDataList [ 0 ] ( CourseRegistrationData ) : StudentId ( i n t e g e r ) : 1 CourseId ( i n t e g e r ) : 10 U n i v e r s i t y I d ( I n t e g e r ) : 3 CourseRegistrationDataList [ 1 ] ( CourseRegistrationData ) : StudentId ( i n t e g e r ) : 7 CourseId ( i n t e g e r ) : 15 U n i v e r s i t y I d ( I n t e g e r ) : 5 For an explanation on the notation, see section The test-case inputs that were logged to the database by the Generator/- Collector using the Student-System I/O Logger:

85 7. Case Studies Implemented in Student SOA Lab 84 Id Data TimeStamp StudentGroupName 221 BusinessObject: :30:55 OUS (StudentId=1, CourseId=10, UniversityId=3) 222 BusinessObject: (StudentId=5, CourseId=15, UniversityId=5) :33:11 OUS The following outputs (intermediate and final) were logged by the Student- System I/O Logger for the test-case with input identifier 221:

86 7. Case Studies Implemented in Student SOA Lab 85 Id Data TimeStamp Source 701 Event: Courses that are :31:04 CentralRegister offered by university with id 3 are retrieved. 702 Event: Id of the :31:07 CentralRegister home-university of student with id 1 is retrieved 703 Event: Prior Knowledge :31:10 CentralRegister of course with id 10 is retrieved. 704 Event: Name of the :31:11 CentralRegister student with id 1 is retrieved 705 Event: Name of the :31:11 CentralRegister course with id 10 is retrieved 706 Event: External :32:23 CentralRegister registration was created: StudentId: 1, UniversityId: 3, CourseId: 10, PaymentId: Event: Payment with id :32:24 CentralRegister 30 is fulfilled. 708 Event: Name of the :32:43 CentralRegister course with id 10 is retrieved 709 BusinessObject: Grade@731c731c (Grade=7) :33:07 GeneratorCollector These outputs are intermediate outputs logged by the context-components which were defined for the OUS-exercise (CentralRegister) and the final output which was logged by the Generator/Collector. For this test-case there were also 40 events retrieved from the CEI, and parsed by the Execution Trace Logger component. Listing 40 events is overwhelming, but from these events it is possible to draw a Message Sequence Chart (MSC). In figure 7.25 this MSC is visible. For the explanation of the notation of the MSC, see section Automated Test-Case Generation In this section it is presented how the Generator/Collector can be used to generate test-case inputs for the OUS system. The input given to the Generator/Collector using operation TestCaseGeneration (section ):

87 7. Case Studies Implemented in Student SOA Lab 86 Fig. 7.25: MSC of the test-case with input identifier 221

88 7. Case Studies Implemented in Student SOA Lab 87 StudentGroupName ( s t r i n g ) : OUS S t u d e n t S y s t e m P a r t n e r ( s t r i n g ) : S t u d e n t P a r t n e r OperationName ( s t r i n g ) : s t u d e n t NameType ( s t r i n g ) : C o u r s e R e g i s t r a t i o n D a t a NamespaceType ( s t r i n g ) : h t t p : / / OUSLib TestCaseAmount ( i n t e g e r ) : 5 OutputName ( s t r i n g ) : o u t p u t TestCaseData ( F i e l d D a t a L i s t ) : FieldDataList ( FieldData [ ] ) : F i e l d D a t a L i s t [ 0 ] ( F i e l d D a t a ) : Name ( s t r i n g ) : S t u d e n t I d Type ( i n t e g e r ) : 2 L i s t S i z e ( i n t e g e r ) : S t r i n g L i s t ( S t r i n g L i s t ) : S t r i n g L i s t s ( S t r i n g L i s t [ ] ) : I n t e g e r L i s t ( I n t e g e r L i s t ) : I n t e g e r L i s t s ( I n t e g e r L i s t [ ] ) : LowerBound ( i n t e g e r ) : 1 UpperBound ( i n t e g e r ) : 11 BooleanLists ( BooleanList [ ] ) : ComplexTypeList ( ComplexTypeList ) : ComplexTypeLists ( ComplexTypeList [ ] ) : F i e l d D a t a L i s t [ 1 ] ( F i e l d D a t a ) : Name ( s t r i n g ) : C o u r s e I d Type ( i n t e g e r ) : 2 L i s t S i z e ( i n t e g e r ) : S t r i n g L i s t ( S t r i n g L i s t ) : S t r i n g L i s t s ( S t r i n g L i s t [ ] ) : I n t e g e r L i s t ( I n t e g e r L i s t ) : I n t e g e r L i s t s ( I n t e g e r L i s t [ ] ) : LowerBound ( i n t e g e r ) : 1 UpperBound ( i n t e g e r ) : 21 BooleanLists ( BooleanList [ ] ) : ComplexTypeList ( ComplexTypeList ) : ComplexTypeLists ( ComplexTypeList [ ] ) : F i e l d D a t a L i s t [ 2 ] ( F i e l d D a t a ) : Name ( s t r i n g ) : U n i v e r s i t y I d Type ( i n t e g e r ) : 2 L i s t S i z e ( i n t e g e r ) : S t r i n g L i s t ( S t r i n g L i s t ) : S t r i n g L i s t s ( S t r i n g L i s t [ ] ) : I n t e g e r L i s t ( I n t e g e r L i s t ) : I n t e g e r L i s t s ( I n t e g e r L i s t [ ] ) : LowerBound ( i n t e g e r ) : 1 UpperBound ( i n t e g e r ) : 6 BooleanLists ( BooleanList [ ] ) : ComplexTypeList ( ComplexTypeList ) : ComplexTypeLists ( ComplexTypeList [ ] ) : Five test-case inputs was generated by the Generator/Collector and logged using the Student-System I/O Logger:

89 7. Case Studies Implemented in Student SOA Lab 88 Id Data TimeStamp StudentGroupName 223 BusinessObject: :51:51 OUS (StudentId=10, CourseId=2, UniversityId=1) 224 BusinessObject: :51:55 OUS (StudentId=9, CourseId=12, UniversityId=3) 225 BusinessObject: :51:58 OUS (StudentId=6, CourseId=20, UniversityId=2) 226 BusinessObject: :52:02 OUS (StudentId=1, CourseId=2, UniversityId=2) 227 BusinessObject: (StudentId=7, CourseId=2, UniversityId=4) :52:06 OUS For these test-cases also exist intermediate outputs and a final output similar to those listed in section For these test-cases the events in the CEI were retrieved and parsed by the Execution Trace Logger.

90 8. COMPARISON AND FUTURE WORK In this chapter a comparison will be made with existing systems and future work and opportunities are presented. The Student SOA Lab is innovative, because it combines actual development in an IDE, with education. The two other projects (Peach and TALER) that were described in chapter 3 are different in that they do not involve the development of systems by students. The Student SOA Lab provides some great advantages in that sense over other educational systems. Moreover the Student SOA Lab also enables students themselves to test and evaluate their own systems. Peach provides automatic evaluation (or validation) for some kind of assignments. Moreover peach completely manages courses and all the submitted work of students. The Student SOA Lab is able to group the test-cases for one student-made system, but it does not manage the student-made systems in any way (by storing these systems in some place). There is still work to be done on the Student SOA Lab. At this moment there do not exist graphical human interfaces (GUI) for the interactions with the Student SOA Lab which were described in requirement 4. The GUI would enable instructors to execute the test-cases on the student-made systems. Moreover it should be possible to review the executed test-cases (inputs, intermediate outputs and final outputs) and extract certain diagrams and reports, like message sequence charts (MSC), execution traces of BPEL-processes and verification based on intermediate outputs and final outputs. There should be research about metrics and diagrams that could possibly be extracted from the test-case data, i.e. inputs, intermediate outputs, final outputs, BPEL-events and SCA-events. MSCs can be constructed from SCAevents. The automatic construction of these MSCs should be designed and implemented. The BPEL-events could be used to construct execution traces within BPEL-processes. Maybe other metrics and/or diagrams could be constructed out of test-case data and presented to instructors in reports. The Student SOA Lab has currently two ways of setting up input for testcases: manual and automated. In the automated input generation, it is at the moment not possible to use a database which holds test-case inputs while it was a requirement for the Student SOA Lab. This is something that needs to be designed and implemented in the future. Validation is another future requirement for the Student SOA Lab. At this moment the validation is supported by the Student SOA Lab by means of logging events, i.e. intermediate outputs, and the test-case output. The validation itself

91 8. Comparison and Future Work 90 must be done manually by the instructor. Research should be done to automatic validation of student-made systems. An option could be another framework which uses the Student SOA Lab as it is now, to extract test-case data and compare it with an architecture of the student-made system. This architecture could be described as a set of Petri-nets or in any other modeling language. This framework could analyze the test-case data and hold it against the architecture to see whether the implementation violates the architecture. The Student SOA Lab is at the moment not able to visually show the realtime execution of a test-case. The CEI can emit Java-events on receiving SCAand BPEL-events. This can be used for the real-time representation of a testcase. This is something which should be looked at. Since the Student SOA Lab is dependent on the IBM WebSphere for the BPEL- and SCA-events, it is not possible to retrieve events for a system which is implemented on another platform, like Oracle SOA. An event concept should be developed. This concept should incorporate the definitions, emitting and retrieving of events on different levels, i.e. on SCA-level, BPEL-level, but maybe also BPEL-activity-level.

92 APPENDIX

93 A. SOA DEVELOPMENT IN IBM WEBSPHERE This appendix is a manual for IBM WebSphere. It gives information about concepts important for understanding IBM WebSphere. Moreover it explains the various implementations available for components in IBM WebSphere and a deeper look into the constructs available in BPEL. A.1 Concepts in IBM WebSphere In this section the concepts used in IBM WebSphere are described. This knowledge is needed to understand how IBM WebSphere is set up and will help understand other chapters in this thesis. A.1.1 Component Hierarchy in IBM WebSphere In this section will be explained how the various software units are organized in a hierarchy. In IBM WebSphere the following units are defined: SCA-modules (named just modules from now on) and components (appendix A.2.1). A module is a container of components. In a module exist one or more components that can interact with one another. The unit that is deployed to the IBM WebSphere Process Server is a module. This means that IBM Web- Sphere Process Server is the runtime environment for modules. IBM WebSphere Process Server is built on top of IBM WebSphere Application Server. It is possible to use a module as an abstraction mechanism for a service. A component is a service when it is invoked by another component by sending an input, and returns an output. A module contains multiple components, but a module can also act as a service by exporting one or more components. An example is given of how inter-module communication can be used. To invoke a component Y in a module B from a component X placed in a module A, an export component Q with a SCA-binding of component Y needs to be generated. This component Q is placed in module B. An import component P with a matching binding needs to be generated in module A. This import component P will be importing the export component Q. Now it is possible for component X to invoke component Y via import component P and export component Q. In figure A.1, a visual representation can be seen of this example. The arrow between component X and import component P means that X is able to invoke P. An export-component is a component which makes it possible for components running in environments outside of the module to invoke component X. It

94 A. SOA Development in IBM WebSphere 93 Fig. A.1: How component X can invoke component Y is possible to create export-components of every possible component except components which are adapters, because adapters are import-components. There are different bindings for the export-components depending on the protocol required. Different technologies use different protocols for communication. The binding-type determines which protocol-conversion is applied by the exportcomponent. For example it is possible to invoke a component in a module from a PHP-script. This would require a SOAP/HTTP-binding for the exportcomponent. The export-component will translate the invocation by the PHPscript which uses the SOAP/HTTP-protocol, to the protocol which is used for communication between the components contained in a module and deployed to the IBM WebSphere Process Server. The response from the component is converted from the protocol used internally in the module, to SOAP/HTTP. So the PHP-script can receive the response. There are bindings available for SCA, JMS, MQ and Web Services. For a PHP-script to be able to invoke an export-component, it requires the URI of the export-component. For intermodule communication (communication between SCA-modules, as described in the example), the component that wants to invoke an export-component does not require a URI of this export-component, but instead an import-component is generated which is placed in the module of the invoking component. By invoking the import-component, the request is passed on to the export-component in the other module. An import-component requires the same interface as the export-component it refers to. A good practise is to place the interface of the export-component (originally the interface of the component for which the export-component was generated) in a library. This library can then be imported in the project in which the module is being designed which contains the import-component. The interface can be attached to the import-component. A.1.2 SCA Software Component Architecture (SCA) is the name of the concept which is responsible for the description of a component. It is a component-model. SCA distinguishes three parts that make up a component: interface, references and

95 A. SOA Development in IBM WebSphere 94 the implementation. This means that in theory, components can have all kinds of implementations as long as they handle the operations that are described in the interface of the component. In practice IBM WebSphere provides six kinds of implementations for components (described in appendix A.2.4). A big advantage of SCA is loose coupling. Loose coupling is part of the SOA principles. Loose coupling means: making as few assumptions as possible about the systems that invoke a component and about the systems which a component invokes. The interface of a component (appendix A.2.2) contains no endpoint information of systems that invoke it. The references on a component (appendix A.2.3) have an interface-reference which is required to be set, but the actual component-reference (endpoint) is not required to be set. This means that a component can be implemented without needing the components it depends on. These can be set later (dynamically at runtime is a possibility) as long as the interfaces of these partner components are specified. The advantages of loose coupling are easy-change and independence of technology. Easy-change means that it is easy to replace a component as long as the same interface is used. Independence of technology means that various technologies can be used to implement a component, as was mentioned before. An endpoint of a system is the place where it can be found for interaction (for example a URI or connection-string). A.1.3 The CEI (Common Event Infrastructure) is what IBM WebSphere uses to emit, store and retrieve events. The Common Base Event is a default model that is used for describing events. IBM WebSphere has a set of standard events that can be emitted. IBM WebSphere has different runtimes that are used for executing business modules. The SCA-runtime is the environment in which different components run. This runtime does not care for what happens during the execution of a component. It only cares for the interfaces and references. So what goes in a component and what comes out. Then there are different runtimes for executing the implementations of components. One of these is the BPEL-runtime. This runtime is used to execute BPEL-processes. The SCA-runtime and BPEL-runtime are able to emit events. The BPEL-runtime is able to emit events when certain BPEL-activities are executed. The SCAruntime is able to emit events when a component is invoked, exits and/or fails. These events are stored in a data-source which is part of the CEI. The Common Base Event-model has certain default properties which do not hold interesting data. There is one property which can be used to hold data that does not fit other properties. This versatile property is used by IBM WebSphere. If an event is emitted this property will hold all the relevant data in the form of a XML-document. The XML-document seems not to be consistent. The XMLdocument s layout seems to be depending on the kind of event, but this does not hold in all cases. The XML-documents that are part of SCA-events have an acceptable consistency to be able to construct an message sequence chart of CEI

96 A. SOA Development in IBM WebSphere 95 executed test cases. BPEL-events will be logged to the database but are at the moment not used for analysis. The emitting of events has to be switched on manually. SCA-events can be switched on per operation of a component s interface. In WID (appendix A.1.4), this is part of the properties of a component s interface. The properties-view of an operation has an Event Monitor-tab. Here can be set whether all events, or no events or a selection of events has to be emitted. The types of events are: entry, exit and failure. An entry-event is emitted when a component is invoked with that particular operation. An exit-event is emitted when the component s execution ends. A failure-event is emitted when a component ends because of an error. The emitting of BPEL-events has to be switched on in the properties of a BPEL-process. The properties of a BPEL-process have an Event Monitor-tab. Here a number of events can be switched on. Moreover there is a Global Event Setting-tab where predefined events for a number of BPEL-activities can be switched on. Finally for each separate BPEL-activity there are a number of events available in the Event Monitor-tab of the properties of an activity. A.1.4 WebSphere Integration Developer WebSphere Integration Developer (WID) is the environment which is provided for development of websphere technology. It is based on the Eclipse-framework. Eclipse is a well-known extendable development environment. WID provides tools for the development of various technologies: J2EE, EJB, Web, SCAmodules, etc.. It is mainly directed on development for the IBM WebSphere Process Server. In WID the developer will create projects. In a project, software can be developed. The scope of this paper remains on SCA-modules. A module is developed in a project. A developer may define interfaces, data-types, datatransformations, implementations and components and the way components interact. WID also provides tools for testing components and testing components in isolation. In WID, a module can be deployed to the IBM WebSphere Process Server. It is also possible to develop libraries which may contain interfaces, datatypes and data-transformations. These libraries can be imported in projects. This makes it possible to use an interface in different modules. This is required if components from different modules invoke one another. A.2 Assembly Diagram The Assembly diagram is the architectural overview of the SCA-module you are developing in your project. It shows all the components that are included in your project and the way they refer to each other. It can be seen as the architecture of the system. IBM has separated the different parts that make up a component. Interfaces, references, data-types and implementations are independent of a component. This makes it possible to develop all these parts

97 A. SOA Development in IBM WebSphere 96 Fig. A.2: Assembly Diagram separately and to re-use them. Obviously when you want to use a component, it needs an interface, an implementation, possibly references to other components and probably variables. A.2.1 Components The components are the main building blocks in modules. Every component consists of three parts: the interface, the references and the implementation. The interface defines how a component can be used by others. These others can be components in other modules, but also a PHP-script or any other technology for which a binding exists (via generated export-components). The components have an implementation of a certain type. The possible implementations in IBM WebSphere are Java, BPEL, business rule, state machine, human-task and selector. Adapters can also be seen as components, but in this document they will be handled separately since adapters are generated and cannot be developed like components. The interface and implementation can be developed separately, but obviously it is required that the implementation handles the operations defined in the interface. When a component is invoked by another system, an instance of that component is created. Multiple instances of the same component can exist at the same time. Once a component instance reaches the end of the process, the instance will be destroyed by the server. A component is stateless by itself. This means that once a component instance is destroyed all the variables are destroyed as well. Once a component is invoked, the created instance doesn t know anything about what any other instances of that component did.

98 A. SOA Development in IBM WebSphere 97 An instance of a short-running component is created once the component is invoked. The instance is executed and destroyed after the response is given. This component can have only one receive-activity and that is the receive operation at the start of the process. This receive-activity also creates the instance. A short-running component can also have no human-tasks. It is possible to have receive-operations in the middle of a component s process and/or human-tasks in a process. These components are required to be long-running, because it can block on a receive activity or human-task. In both cases the process must wait on signals coming from outside of the component: in case of blocking on a receive-activity, the process must wait for a system to send a message. In case of blocking on a human-task, the process must wait for a human to complete a task. This also requires a mechanism to find the right instance of a component, because it must be possible to send a message to the right instance of a component. This is handled by correlation (see A.2.7). A.2.2 Interfaces Fig. A.3: Interface editor Interfaces describe how a component can be invoked. Interfaces are defined in the Web Service Definition Language (WSDL). WSDL is a language based on XML. Interfaces contain one or more operations. Operations can be of type: oneway or request-response. A one-way operation has one or more inputs and no outputs. A request-response operation contains one or more inputs and one or more outputs. The input is given by the invoking component. The output is the response of the invoked component. Every input and every output has a name and a data-type. These data-types can be simple-types like string, integer or

99 A. SOA Development in IBM WebSphere 98 boolean. It is also possible to use complex-types or business objects (appendix A.2.5). Interfaces have certain properties which can be set. One property is the preferred interaction style which is either asynchronous, synchronous or any. Any is used when the decision of synchronous or asynchronous-communication is left to the WebSphere Process Server. Interfaces also have Quality of Serviceproperties (QoS) which are for example security-properties or data-validation properties. On an interface it is also possible to enable the emitting of SCAevents. A.2.3 References References are used by components to interact with other components. A reference is part of a component and consists of an interface-reference and a component-reference (or wire to a component). The interface-reference sets the interfaces which the reference can refer to. So it can only refer to components with the same interface as the interface that is set on the reference. The component-reference is used to set the partner component. This is actually a wire to another component. This means that a certain reference can only be used for components with a certain interface. A component-reference does not have to be set, but a partner component can only be invoked if the endpoint is set using a wire to another component. References have, like interfaces, certain properties that can be set. A property is the multiplicity. By default this is set to 1..1, which means that a reference must have exactly one component wired to it. Another possibility is 0..n. This means that a reference can have zero or more components wired to it. Components that have references with a 0..n-multiplicity can only have a Java-implementation. References have QoS-properties that can be set. These properties are for example timeout- and reliability-properties. A.2.4 Implementations Every component needs to be assigned an implementation. Implementations can be developed independently of a component. The interface and component type need to match the component s interface and type though. Implementations can be in Java or BPEL. An implementation can also be a Rule Group (which is similar to a rule engine) or a state machine. More information on the possible implementations for components in appendix A.3. A.2.5 Data types/business Objects A data-type specifies the structure of data. There are simple-types like string, integer, boolean, etc. available, but also complex data-types which are referred to as Business Objects (BO) in the WebSphere Integration Developer (WID). This can be confusing because for some technologies, objects contain the data and classes describe the structure of the data.

100 A. SOA Development in IBM WebSphere 99 Fig. A.4: Data type editor The complex data-types are defined in the XML Schema Definition language (XSD). A developer in WID is not confronted with XSD. In WID there exist tools for designing data-types. These complex data-types are presented in WID like records or structs (as in popular programming languages). So a complex data-type has multiple typed fields. The type of a field in this record, can be a complex data-type or a simple data-type again. It is possible to present complex data-types like a tree-structure. A developer does not need knowledge of XSD to work with data in WID. Variables used in BPEL-processes are typed and can have simple data-types like integer, string and boolean. The variables can have type also have complex data-types. The variables can be used in expressions in BPEL. These expressions can be described in XPath or Java. The variables behave as objects in Java or as XML-documents if XPath is used. A SDO If a component has a Java-implementation and there are variables used in the component s interface that have complex data-types, the Service Data Object (SDO)-framework is used to interact with the variables. SDO provides a unified framework for access to data. SDO has a Java API which can be used to work with data from multiple kinds of data sources like relational databases, entity EJB components, XML pages, Web services, the Java Connector Architecture, JavaServer Pages pages ([1]). The SDO Java API provides a class that is named DataObject. The object of this class represents a certain data source. The functions defined in the DataObject class, provide ways of accessing and manipulating the data in this

101 A. SOA Development in IBM WebSphere 100 data source. For each data source an object of the DataObject class must be instantiated. Variables which are used in IBM WebSphere and have a complex data-type, can only be handled in a Java component by using SDO. These variables are, when used in a Java-implementation, DataObject objects. A.2.6 Business Object Maps Business object maps are a mechanism to map one complex-type to another. In this way it is possible to assign a variable of one data type to a variable of another data type. These mappings are implemented in XSL-transformations (XSLT) (XSL stands for Extensible Stylesheet Language). Developers are not confronted with the XSLT language. WID provides tools for designing these mappings. These mappings can be used in the BPEL-activity Business Object Map (appendix A.4.2.7) to map one variable to another, and in the interface map-component (appendix A.3.5). A.2.7 Correlation Correlation is a BPEL-construct that is used for referencing the right instance of a component. Correlation is required in components with a BPEL-implementation which contain receive-activities that do not instantiate the component and components that have a state machine as implementation. (Notice that a BPELprocess can be the implementation of a component. BPEL-process and BPELimplementation are definitions that can be interchanged.) What happens is that when a component wants to interact with a certain instance of a component, correlation is used to identify the right instance, if it exists, or initiate a new instance, if it does not exist. In practise it means that an instance is chosen based on data in the input field (or one of the input fields) of the operation that invokes a component that supports correlation. There are certain requirements for the BPEL-process and interface of a component to be able to use correlation. The Join Transaction qualifier of the component s interface needs to be set to false and the process that uses correlation needs to be marked as a long running BPEL-process. A.2.8 Human Tasks Human tasks are the name for the concept that involves human interaction in processes. There are three kinds of human tasks: to-do tasks, invocation tasks and collaboration tasks. The to-do task is a task that is scheduled for a human by an automated service. An invocation task is a human invoking an automated service. A collaboration task is a human scheduling tasks for other humans. A to-do task has an interface like a component. This interface can have only one operation. The input of this interface-operation is presented to the human and the output is returned by the human. The output holds the actions performed by the human. If a to-do task is scheduled by a service, it is inserted in a task queue. A human can claim a task if his role is assigned to the task.

102 A. SOA Development in IBM WebSphere 101 If the task is claimed, the task cannot be claimed by another person. Now the human that claimed the task can execute the task. By executing the task is meant, the human must do the actions required by the task. This can be manipulating the data that was given as input, or just checking the data for errors. The person has two options after executing the task, he/she can save the task and open it again later or actually completing the task. Completing a task means that the data (data that represents the actions performed by the human) is send back to the service that scheduled the task. A human that claimed a task, can also release it again. So it becomes available again for other humans. An invocation task has an interface with also only one operation, that is required to be the same as the interface from the service it invokes. The input given by the human is passed to the service and the output produced by the service passed back to the human. An invocation task can be done by a human with the right role at any moment. Collaboration tasks are tasks where humans schedule tasks for other humans. There are two kind of tasks that can be scheduled by humans for other humans: subtasks and follow-on tasks. A subtask is a human delegating work to other humans. These subtasks are completed by humans before the parent-task is completed. Follow-on tasks are tasks where a human completed a part of the task and creates a follow-on task where another human completes the rest of the task. WID does not provide visual tools for designing subtasks and follow-on tasks. The task API (Java API) is required for this purpose. Security is organized by assigning roles to human tasks. Only humans who have a role which is assigned to a task, can perform the task. Another important aspect of human tasks are escalations. Escalations are executed when certain events are triggered. There exist three kind of escalations: ready, claimed and subtask. The ready-escalation is triggered, if a task is longer in the task queue than a certain period of time. The claimed-escalation is triggered, if a task is claimed longer than a certain period of time without being completed or released. Finally the subtask-escalation is triggered, if a subtask exists for too long. If an escalation is triggered, notifications are sent to certain people. These notifications are kept being sent until the task reaches a certain state. For example if a task is claimed for too long, the person who claimed it, will receive s with an interval until the task is completed. The presentation layer is decoupled for the human task system. IBM Web- Sphere provides default presentation technologies for human tasks. It is possible to have the WID automatically generate Java Server Faces (JSF). Other technologies available by default are IBM Lotus Forms and Business Space. An out-of-the-box system for handling human tasks is Business Process Choreographer Explorer. This is a web interface which enables users to execute tasks, but also start any component designed in WID and get insight in running processes and finished processes.

103 A. SOA Development in IBM WebSphere 102 A.3 Component Implementation Types A.3.1 Java Fig. A.5: Example of a java component Java is one of the possible implementation types, a component in IBM Web- Sphere can have. A java implemented component has one interface and one or more references to other components. The interface operations of a java implemented component are handled by java functions. Each operation of the interface has one java function to handle the operation. Each input fields of an operation is represented as an argument of the java function. The name of the java function is the same as the name of the interface operation and the return type of the java function is the same as the data type of the operation s output field. Java as implementation requires an interface operation to only have one output field, since the operation will be handled by a Java-function and Javafunctions can have multiple parameters, but only one output. This limitation can be compensated by using a complex-type for the output field. A.3.2 WS-BPEL Fig. A.6: Example of a BPEL component WS-BPEL (or BPEL4WS, just BPEL will be used from now on) is another implementation type. BPEL is an XML-based language which is meant for describing processes and orchestration. The WS extension stands for Web Services and this means that the processes will act as services. A service handles a request from another component and gives a response back. A BPEL-implemented component requires one interface and can have one or more references to other components. In BPEL, these references are named Partner-Links. The references of the component it implements have to match the partner-links defined in the BPEL-process.

104 A. SOA Development in IBM WebSphere 103 BPEL describes a business process like a work-flow. There is a starting-point of the process and an end-point. In between there are all kinds of structures and activities. There are structures which influence the path of activities that is taken, but there also exist activities which assign a value to a variable. The constructs of WS-BPEL are handled in appendix A.4. A.3.3 State Machine Fig. A.7: Example of a State Machine component Fig. A.8: Example of the implementation of a State Machine in WebSphere The state machine is a component which can be used to hold a state. The state machine-component has one interface and one or more references to other components. A state machine-implementation consists of states and transitions. Transitions are the arrows between states. A transition is fired (a state-change will occur) if the state machine component is invoked with an interface operation

105 A. SOA Development in IBM WebSphere 104 that is linked to a transition that is an outgoing arrow of the current state of the state machine. States have options. When entering or exiting a state an action can be executed. These actions are implemented with java. It is also possible to let the action be an invocation of a partner component. Transitions have also options. A transition is required to have an interfaceoperation linked to it unless a time-out is set. In that case after a certain period the transition is fired automatically. It is also possible to give a transition a condition. This means that a transition will only be fired if the condition is true at the moment of invoking the appropriate interface-operation. The condition is implemented as a java snippet. The last option is the possibility to attach an action to a transition. This is the same as the entry and exit actions of places. A component which has a state machine-implementation is by default a longrunning component. Correlation is used to identify instances. State machineimplementations are not used by the IBM WebSphere Process Server. Instead a BPEL-process is generated from the State machine-implementation at the moment a state machine is deployed. A.3.4 Human Task The human task-component is a component that can be dropped on the assembly diagram. This component has an interface or a reference (impossible to have both). If the component has a reference, it implements an invocation task. The interface of the task is the same as the interface of the component it references. A human can use the task to invoke the component that is referenced. If the component has an interface, it implements a to-do task. The interface of the component is the same as the interface of the task. This component is invoked by other components to schedule to-do tasks for humans. For more information on human tasks, see appendix A.2.8. A.3.5 Interface Map Interface maps are similar to business object maps A This component can be used when component x needs to invoke component y which has interface A, but the reference on component x expects interface B. The interface map component can be used to map the inputs and outputs of interface operations. The interface map component would in this example have interface B and a reference which refers to interface A of component y. The implementation of the interface map component would map the inputs of the operations of interface B to the inputs of the operations of interface A and map the outputs of the operations of interface A to the outputs of the operations of interface B. Component x can invoke the interface map component as if it was component y with interface B. The interface map component uses business object maps for the mappings between the various fields of the operations.

106 A. SOA Development in IBM WebSphere 105 A.3.6 Selector Fig. A.9: Example of a Selector component The selector component is a component that is used to dynamically relay the invocation of components. This means that based on certain conditions a component is invoked. The conditions on which the decision is based to which component the invocation is relayed, is based on a date and time. So if a component invokes the selector-component, the input is relayed to component x based on whether the current time and date fall in a period of time which is set for component x. The periods set for various components may not overlap. The selector has the same interface as the components it can relay an invocation to. A default component can be set in the selector to which an invocation will be routed in case there is no component for which a period of time is set in which the current time and date falls. By default an invocation is relayed to a component based on the current time and date. The current time and date can be changed in Java. This means that the selector thinks it is a certain time while it is not. This can be used to dynamically route invocations based on other conditions than the current time and date. The selector does not show the components to which it can relay invocations in the assembly diagram. This can be confusing, because it is not immediately clear that the selector depends on components that are defined in the same module. A.3.7 Business Rules Fig. A.10: Example of a Business Rules component The business rules component represents a simple rule engine. The business rules component can be invoked by a service. Based on the existing business rules and the input, a output is returned. There can be different business rules defined depending on which operation of the business rules interface is invoked. It is also possible to have different rules depending on the current time and date. This uses the same mechanism as described for the selector component (appendix A.3.6).

107 A. SOA Development in IBM WebSphere 106 Fig. A.11: Example of a rule set There are two types of business rules available for the business rules-component. rule sets and decision tables. A rule set is a sequence of rules and actions. A rule set can also contain variables. These rules and actions may use the variables. An action just executes a statement. This statement may contain variables defined in the rule set or the input and output variables of the operation that was used to invoke the business rules-component. A rule consists of a condition and an action. The action is executed if the condition is true. This condition can depend on the input that was given to the business rules-component and/or on variables defined in the rule set itself which cannot be null. These variables can be assigned values by actions or rules which are executed before the current rule. The action of a rule can assign values to the output of the operation or to a variable defined in the rule set. The actions and rules are executed from top to bottom. If conditions of different rules overlap and the same variable is assigned a value in the actions of these rules, then the variable will have the value of the last rule (lowest in WID). There are templates available for the rules in a rule set. These templates may contain parameters which are used in the actual rule definition. A textual representation of the rule should be inserted. This textual representation describes the rule in natural language and may contain the names of the parameters used

108 A. SOA Development in IBM WebSphere 107 Fig. A.12: Example of a decision table in the template. A business rule can be defined out of a template. The parameters should be instantiated by actual values to be able to use the rule. A web interface is available which makes it possible to add, remove and edit business rules which use a template, on runtime. Only the textual representation of the rule is available in the web interface. In figure A.11 is an example visible of a rule set. It contains one variable, one action, two rules and one template. The execution order is Action1, Rule1 and then Rule2. Rule2 is an instance of Template1. Template1 has two parameters which are used in the condition and the action. A decision table has condition rows and action rows. Depending on the values of the variables in the condition rows, values in the action rows are assigned to variables. This is best explained using an example. In figure A.12 an example of a decision table is given. If field1 and field2 of input1 have value 1 and input3 has value x then output1 is assigned a and field2 of output2 is assigned the calculated value of the expression input1.field The business rules component supports the execution of simple business rules. For more sophisticated business rules, there exists an ILOG-adapter for IBM WebSphere. ILOG is an advanced rule engine. A.4.1 A.4 WS-BPEL Processes Partnerlink/Reference Partner A partnerlink or reference partner as IBM calls it represents a link with another component to interact with. In WID these partnerlinks are generated from the references of the particular component. The generation of partnerlinks is done at the moment the implementation of that component is generated. Adding partnerlinks when an implementation already exists is not trivial. The easiest way of doing this is by right clicking on the component in the assembly diagram and clicking on to implementation from the Synchronize Interfaces and References -menu and then from implementation from the same menu. The implementation s interface and reference partners and component s references and interfaces are synced. Partnerlinks are used by a number of BPEL activities. Invoke is an activity used to invoke another component. Receive and Receive Choice are activities which handle the invocation of other components and store the input in a variable. Reply is the activity which replies the output back to the invoking component (if it is two way communication). Reply only

109 A. SOA Development in IBM WebSphere 108 Fig. A.13: Reference and partnerlink follows after a Receive or Receive Choice activity, because there has to exist an invoking partner. A.4.2 Basic Activities Basic actions are actions which do not encapsulate other activities or change control flow. To add an activity to the process, click on the activity you want to add to select it. Then click on the place in the process view where you want to add the process. A Assign The Assign-activity is the standard activity for assigning values to variables. Variables can be used in different ways. In an Assign-activity variables are seen as XML elements. Therefore XPath is used to do more complicated expressions. Still the Assign-activity is quite limited in its use in WID. The Snippet-activity must be used for cases where the assignment lacks the functionality. The Assignactivity can have one or more sub-assignments. (These sub-assignments are of the type Copy. Copy is the only type supported by WID at this moment.) Each assignment has a from and to part. The to part of the assignment is a variable or a sub-element of a variable. The from part of the assignment can be a variable, sub-element of a variable, a constant value or an XPath-expression. The (calculated) value of the from part is assigned to the variable in the to part. The types have to match. There are extensions available for the Assignactivity (not supported by WID at this moment). IBM only supports copy for

110 A. SOA Development in IBM WebSphere 109 Fig. A.14: Assign activity assignments in an Assign-activity. Extensions make it possible to use Insert or Append instead of Copy which make it easier to use element arrays/lists. In WID, snippets have to be used for manipulating arrays/lists. A Invoke The Invoke activity is the activity that is used to invoke other components. To be able to have an invoke activity invoke another component, this component has to be added as partnerlink. The Invoke activity needs a partnerlink, the partnerlink s interface and the operation that needs to be invoked. Furthermore variables need to be linked to the parameters of the interface operation. It is important that the variables that are used as input are initialized using an Assign activity or snippet before the Invoke is executed. A Receive Receive is the activity for receiving a request message. In a short-running component with BPEL-implementation, the Receive activity is what initiates the process. This means that an instance of the component which is invoked, is created. The connection between the instance of the component that invokes and the instance of the component that is invoked is created automatically. The Reply that might follow (depending on whether the invoked operation has output fields), calls back to the right instance of the invoking component automatically. It is possible to have a Receive activity as not being the initiator of a component (the component is long-running). In this case correlation needs to

111 A. SOA Development in IBM WebSphere 110 Fig. A.15: Invoke activity be used. A Receive needs a partnerlink, its interface, interface operation and variable(s) linked to the operation s input parameter(s). The variable(s) will get the value(s) of the parameter(s) when the receive activity is executed. A Receive Choice The Receive Choice is comparable to Receive. The only difference is that this activity is used when the interface of the process has more than one operation. The Receive Choice manipulates control flow based on which operation is triggered. This means that the part of the process that handles the initiated operation is executed and parts of the process which are meant to handle different operations are ignored. The rest is the same as Receive. A Reply The reply-activity follows after a receive or receive-choice-activity if it is expected by the partner component (two way communication, which means that the operation has output fields). A reply needs a reference partner, the right interface, operation and an output variable. It is possible to have multiple Reply activities. In this case correlation is used to know the partner to reply to. The Reply-activity is also used to return business faults if these are defined in the interface.

112 A. SOA Development in IBM WebSphere 111 Fig. A.16: Example of a visual snippet A Snippet The Snippet-activity is not a standard BPEL activity. It is invented by IBM to compromise for shortcomings in the WS-BPEL standard. It has a wide range of functionality, because it allows developers to use Java. A snippet can be used in two ways. It is possible to just write Java code. Another possibility is the visual Java. visual Java is a visual representation of Java code. It allows developers to make Java statements using blocks, simple expressions and standard constructs like if-then-else, while-loop, for each-loop, repeat-loop. This The blocks represent Java functions. A block has zero or more inputconnectors and zero or one output-connectors. The input-connectors are the parameters of the function and the output-connector (if it exists) is the output returned by the function. In Java it is possible to have functions that return void, which means there is no output returned. So it is possible to have blocks without output-connectors. Developers are able to design blocks in WID. A lot of standard blocks are available by default. For example there are blocks available for array/list manipulation, date/time, type converters, business object manipulation, business object mapping, math, logic, text manipulation, etc. In figure A.16 an example of visual snippet is given. It has two statements which can be seen from the two vertical lines with a curl at the bottom on the left side. The first statement is the execution of a Java function. This function removes an item at a certain index from a list. This function is represented by the block. It has two parameters: the list and the index of an item. This is represented by the two connectors on the left side of the block. The first connector is the list and the second connector is the index. These are connected to expressions which provide the values of the parameters. It is allowed to use operators in expression-boxes. These are the same operators as available for expressions in the Java language. The connector on the right side of the block is the output of the Java function it represents. In the figure the connector is not used, which means that the output is not used in any way. The second statement represents an assignment. The calculated value of the left expression is assigned to the variable in the right expression. The left expression is allowed to contain operators. The right expression needs to be a variable.

113 A. SOA Development in IBM WebSphere 112 Fig. A.17: Closed scope A Business Object Map A business object map-activity is a generated visual Java snippet. In this snippet a business object mapping is executed. This mapping takes as parameter an input variable and an output variable. The data in the input variable is transformed so it fits the output variable. A Human task The human task-activity is a way of involving human interaction in processes. This activity implements the to-do task. The inputs and outputs of the interface of the to-do task have variables in the BPEL-process. The variable that is assigned to the input of the task needs to be assigned in the BPEL-process. For more information on human tasks, see appendix A.2.8. A Wait The Wait activity is what the name suggests. It is possible to have a simple timeout. The process won t continue until the timeout has occurred. It is possible to set a date and time. The process will not continue until that data and time has been reached. A.4.3 A Structures Scope A scope is used to group activities and give them a name. A scope can be configured to be isolated. This means that the activities within the scope cannot use variables declared outside the scope. It is allowed to nest scopes. It is possible to add certain handlers to a scope like compensation handlers, event handlers and fault handlers (appendix A.4.4).

114 A. SOA Development in IBM WebSphere 113 Fig. A.18: Opened scope A Parallel Activities Parallel activities represents the Flow activity described in the BPEL-standard. The parallel activities component has more functionality than the standard flow as described in the BPEL-standard. The parallel activities allows parallelism of activities in the body of the parallel activities-construct. It does not allow cycles. It is possible to have activities executed in parallel as the intended functionality of the Flow activity. Activities which do not have links pointed to them will be executed whenever the Parallel Activities component is executed (figure A.20). It is possible to require activities to have ended before another activity can be executed. In Figure A.21 Assign1 and Assign3 have to be completed before Assign2 can be executed. It is also possible to put conditions on links. Depending on whether the condition is true or false the link will be activated resulting in executing the activity the link is pointing to. The conditions are implemented with XPath or a Java. A Cyclic Flow The cyclic flow-construct is similar to the parallel activities-construct in that activities can be put in the body and the execution order of those activities can be controlled in a graph-oriented manner by adding links between these activities. The difference between the cyclic flow and parallel activities is that cyclic flow does not allow parallelism while it does allow cycles. So it is possible

115 A. SOA Development in IBM WebSphere 114 Fig. A.19: Parallel activities Fig. A.20: Parallel activities

116 A. SOA Development in IBM WebSphere 115 Fig. A.21: Parallel activities Fig. A.22: Parallel activities with conditions

117 A. SOA Development in IBM WebSphere 116 Fig. A.23: Choice to go back and repeat activities. The conditions on the arrows between the activities decide the execution order. A Sequence A sequence is comparable to a scope, but it lacks the handlers that can be added to a scope. In BPEL, all activities are part of sequences. In WID these sequences can be hidden. It is allowed to nest encapsulation components like sequences and scopes. A Choice The Choice activity is comparable to a case distinction in regular programming languages (not an if-then-else). There are one or more cases, depending on how many cases are needed, with each a condition and there is a case named otherwise which is taken when all the other case conditions lead to false. Otherwise is not required to exist. It is possible to do nothing and go on with the rest of the process if not one of the cases is true and there does not exist an otherwise. The conditions of the cases are implemented using Java or XPath. The activities in the body of the first case (most left) of which the condition is true, are executed. If more cases are true (which is not a best-practise) only the body of the first case (most left) is executed. A While-Loop The while loop is comparable to the while loop in regular programming languages. As long as the condition is true, the activities in the body of the while-loop are executed. The condition is implemented using Java or XPath.

118 A. SOA Development in IBM WebSphere 117 Fig. A.24: While A For Each The For Each-component is not described in the BPEL4WS 1.1 Specification. It is something that IBM created to easily work with lists. It is comparable with the foreach statement that is found in C#. It is possible to have an index variable loop through all the elements of an array. Another possibility is to have the index variable loop through a static range of integer values. It is also possible to have a dynamic range of integer values. By choosing expression in the type field, it is possible to calculate the bounds of the range. Java is used for calculating both the lower bound and the upper bound of the range. The indexvariable of the for each-construct can be used in Java and XPath expressions in activities in the body of the for each-construct. A.4.4 Error/Event Handling A Activities There are four activities for error handling: throw, rethrow, terminate and compensate. The throw activity is used to throw a fault, but this fault must be handled in the enclosing scope within the process. Otherwise it will be returned to the invoking system as a runtime exception. Replying business faults to invoking systems is done with the reply-activity. The rethrow-activity enables the process to rethrow a fault to an enclosing scope in case it can not be handled by the current fault handler or in case the enclosing scope has to be made aware. The rethrow-activity is only available in

119 A. SOA Development in IBM WebSphere 118 Fig. A.25: Foreach fault-handlers. The terminate-activity does exactly what its name suggests, it terminates the process immediately. The compensate-activity can be used to execute compensation handlers. A compensate-activity has a target activity which is a scope. If the compensationactivity is executed, the compensation handler of the scope which is set as target activity is executed. If a compensation-activity does not have a target activity set, all the compensation handlers of scopes that exist within the scope in which the compensation-activity is placed, are executed. A Handlers The different handlers that are available in BPEL-processes are: event-handler, compensation-handler and fault-handler. A fault-handler is a sequence of activities that is executed if a fault or exception occurs. This can be for a specific fault or exception, or any fault or exception. After the activities in the fault handler are executed, the process continues after the activity or scope which generated the fault/exception. A compensation-handler is only available for scopes in a long-running process. This handler is meant to balance a process after an unexpected error happened. A compensation-handler is an isolated sequence of activities which is executed in the following three cases: A compensation activity with its target activity set to the scope of the compensation handler. This compensation activity must be in a fault or compensation of an enclosing scope.

120 A. SOA Development in IBM WebSphere 119 Fig. A.26: Condition in visual Java A compensation activity with no target activity. This compensation activity must be in a fault or compensation of an enclosing scope. An unhandled error occurs in an activity of the scope of the compensation handler. The event-handler is a sequence of activities that is executed when a certain event happens. This event can be a user-defined alarm or invocation by another system. A.4.5 Conditions and Expressions using Java/XPath Expressions and conditions are required in a lot of activities in BPEL processes. For example in while-loops, foreach-loops, assigns, snippets, choices. There are two available languages for creating expressions and conditions: Java and XPath. In assignments, XPath is the language that needs to be used, because this is predetermined by the BPEL-standard. If Java is used, variables that have a complex-type can be used as if they were objects in Java. If XPath is used, variables that have a complex-type can be used as if they were XML-documents. For creating Java expressions and conditions, the developer will the same editor in WID as is used for snippets (appendix A.4.2.6). It is possible to write Java code or create visual Java. In visual Java a returnconstruct is available for conditions. In that case an expression which is of type boolean or output-connector which returns a boolean value, must be connected to the return-construct (figure A.26). In XPath it is possible to create conditions, but only really simple ones since it is not possible to assign values to variables, to use complicated functions (as Java-functions) and make multiple statements. These three great advantages has Java over XPath. The XPath condition bpws:getvariabledata( input1 ) 5 has the same meaning as the visual Java condition in figure A.26. Note: an important difference between XPath and Java is how lists are indexed. The first item in a list has in Java index 0, but in XPath 1. The last item in a list has in Java index n-1, while in XPath it has n (n being the size of the list). This is important when using the index-variable of a for eachconstruct in a Java expression, since this variable goes from 1 to n while in Java it is expected to go from 0 to n-1. A.5 Adapters Adapters are the components that realize integration from other systems with IBM WebSphere. There are two types of adapters: inbound and outbound.

121 A. SOA Development in IBM WebSphere 120 An outbound adapter is invoked by components in the module it is placed. Outbound adapters exist for the following systems: CICS, IMS, , flat file, FTP, JDBC, JD Edwards EnterpriseOne, PeopleSoft, SAP and Siebel. An inbound adapter invokes components in the module it is placed. This adapter cannot be invoked. Inbound adapters exist for the following systems: , flat file, FTP, JDBC, PeopleSoft, SAP and Siebel. An inbound adapter can be a polling service. This is the case for for example. The adapter will keep polling the server for new mail. If a new arrives, the adapter can convert the in a variable supported by IBM WebSphere, and send it to another component for processing. An inbound adapter can also be a service which passes requests from other systems to components within its module. Adapters are generated by WID depending on certain parameters. There are wizards where the required information needs to be given to WID by the user after which the automatic generation starts. It is possible to implement custom adapters. This is described in [6].

122 B. DETAILED DESCRIPTION OF CENTRAL REGISTER S OPERATIONS In this chapter, detailed descriptions of the operations of the CentralRegister are given. CentralRegister is the context-component for the supply chain management system exercise (section 5.1). B.1 RetrieveAllStudents Operation The operation is defined as follows: Type Name Data-type input dummy string output StudentList StudentList Data-type StudentList: Field Data-type Description StudentList list of Student a list that contains elements of data-type Student Data-type Student: Field Data-type Description Id integer id of the student Name string name of the student This operation will return a list of all students that are defined in the system. The implementation (figure B.1) contains the logging of the event that the student-made system retrieved the list of students, and the retrieving and returning of the list of students itself. The retrieving of the list needs three BPELactivities. The first activity is the initialization of the input of the databaseadapter. The second activity is the invocation of the database-adapter which will retrieve the complete list of students from the database. The third activity is a business object map which converts the list retrieved from the database to the format of the RetrieveAllStudents-operation s output (StudentList). Then the list is ready to be returned (using the Reply-activity). B.2 RetrieveAllUniversities Operation The operation is defined as follows: Type Name Data-type input dummy string output UniversityList UniversityList

123 B. Detailed Description of Central Register s Operations 122 Fig. B.1: BPEL-implementation of RetrieveAllStudents Fig. B.2: BPEL-implementation of RetrieveAllUniversities

124 B. Detailed Description of Central Register s Operations 123 Fig. B.3: BPEL-implementation of RetrieveAllCourses Data-type UniversityList: Field Data-type Description UniversityList list of University a list that contains elements of data-type University Data-type University: Field Data-type Description Id integer id of the university Name string name of the university This operation will return a list of all universities that are defined in the system. The implementation (figure B.2) contains the logging of the event that the student-made system retrieved the list of universities, and the retrieving and returning of the list of universities itself. The retrieving of the list needs three BPEL-activities. The first activity is the initialization of the input of the database-adapter. The second activity is the invocation of the databaseadapter which will retrieve the complete list of universities from the database. The third activity is a business object map which converts the list retrieved from the database to the format of the RetrieveAllUniversities-operation s output (UniversityList). Then the list is ready to be returned (using the Replyactivity). The operation is defined as follows: Type Name Data-type input dummy string output CourseList CourseList B.3 RetrieveAllCourses Operation

125 B. Detailed Description of Central Register s Operations 124 Fig. B.4: BPEL-implementation of RetrievePriorKnowledge Data-type CourseList: Field Data-type Description CourseList list of Course a list that contains elements of data-type Course Data-type Course: Field Data-type Description Id integer id of the course Name string name of the course This operation will return a list of all courses that are defined in the system. The implementation (figure B.3) contains the logging of the event that the student-made system retrieved the list of courses, and the retrieving and returning of the list of courses itself. The retrieving of the list needs three BPELactivities. The first activity is the initialization of the input of the databaseadapter. The second activity is the invocation of the database-adapter which will retrieve the complete list of courses from the database. The third activity is a business object map which converts the list retrieved from the database to the format of the RetrieveAllCourses-operation s output (CourseList). Then the list is ready to be returned (using the Reply-activity).

126 B. Detailed Description of Central Register s Operations 125 B.4 RetrievePriorKnowledge Operation The operation is defined as follows: Type Name Data-type input CourseId integer output CourseList CourseList fault fault string CourseList is described in section B.3. This operation returns a list of courses which are prior-knowledge for the course of which the id is required as input. A fault is generated if the given course requires no prior-knowledge. A fault is returned instead of an empty list, because in BPEL it is easier to react on a fault than testing the emptiness of a list. Moreover, when using database adapters to retrieve data from a database, an exception is returned if the result is empty. This makes it a more consistent solution. The implementation (figure B.4) contains the logging of the event that the student-made system retrieved the prior-knowledge of a given course, and the retrieving and returning of the list of courses which are the prior-knowledge of the given course. The retrieving of the list of courses needs the following steps: first the input of the database-adapter is assigned. This is the given course id. The next step is invoking the database-adapter which will return a list of courses that are the prior-knowledge of the given course. Then the list is converted to the CourseList data-type by using a business object map-activity. The list has now the needed elements and the required data-type. The elements are lacking the name of the courses. So for every element of the list, the course-name needs to be retrieved. A foreach-activity is used to go through the elements of the list. For each element there are three BPEL-activities needed to retrieve the coursename. First an assignment-activity to assign the input for the database-adapter. This is the course id contained in the element. Then the name of the course is retrieved by invoking the database-adapter. A last assignment is needed to actually assign the retrieved course-name to the right variable in the element. Finally a list is constructed which contains a list of courses that contains the id and the name of each course. B.5 RetrieveCourseOffers Operation The operation is defined as follows: Type Name Data-type input UniversityId integer output CourseList CourseList fault fault string CourseList is described in section B.3. This operation will return a list of courses that are taught by the university of which the id is required as input. A fault is generated if the given university does not exist.

127 B. Detailed Description of Central Register s Operations 126 Fig. B.5: BPEL-implementation of RetrieveCourseOffers The implementation (figure B.5) contains the logging of the event that the student-made system retrieved the course-offers of a given university, and the retrieving and returning of the list of courses which are offered by the given university. The retrieving of the list of courses needs the following steps: first the input of the database-adapter is assigned. This is the given university id. The next step is invoking the database-adapter which will return a list of courses that are offered by the given university. Then the list is converted to the CourseList data-type by using a business object map-activity. The list has now the needed elements and the required data-type. The elements are lacking the name of the courses. So for every element of the list, the course-name needs to be retrieved. A foreach-activity is used to go through the elements of the list. For each element there are three BPEL-activities needed to retrieve the coursename. First an assignment-activity to assign the input for the database-adapter. This is the course id contained in the element. Then the name of the course is retrieved by invoking the database-adapter. A last assignment is needed to actually assign the retrieved course-name to the right variable in the element. Finally a list is constructed which contains a list of courses that contains the id and the name of each course.

128 B. Detailed Description of Central Register s Operations 127 Fig. B.6: BPEL-implementation of RetrieveStudentRegistration B.6 RetrieveStudentRegistration Operation The operation is defined as follows: Type Name Data-type input StudentId integer output University University fault fault string University is described in section B.2. This operation will return the university where the given student is registered. A fault is generated if the given student does not exist or is not registered at any university. The implementation (figure B.6) of RetrieveStudentRegistration has two parts: first the event that the student-made system wants to retrieve a student-registration, is logged. Then the university where the given student is registered, is retrieved. The second part needs five BPEL-activities to retrieve the university of the given student. First the input for the database-adapter is assigned using an assignactivity. Then the id of the university where the student is registered, is retrieved using the database-adapter. The third activity is also an assignment and again assigns the input of the database-adapter. The fourth activity is the invocation of the database-adapter which retrieves the name of university. Now the id and the name of the home-university of the given student are known and in the fifth activity assigned to the output of the RetrieveStudentRegistration-operation.

129 B. Detailed Description of Central Register s Operations 128 Fig. B.7: BPEL-implementation of LogExternalRegistration Fig. B.8: BPEL-implementation of LogPayment B.7 LogExternalRegistration Operation The operation is defined as follows: Type Name Data-type input ExternalRegistration ExternalRegistrationLog output dummy string Data-type ExternalRegistrationLog: Field Data-type Description StudentId integer id of the student UniversityId integer id of the university CourseId integer id of the course PaymentId integer id of the payment This operation will log the external registration that was created by the student-made system. The implementation (figure B.7) only contains the logging of the event that an external registration was made. The operation is defined as follows: Type Name Data-type input PaymentId integer output dummy string B.8 LogPayment Operation

130 B. Detailed Description of Central Register s Operations 129 Fig. B.9: BPEL-implementation of RetrieveStudentName This operation will log the payment that was fulfilled in the student-made system. The implementation (figure B.8) only contains the logging of the event that a payment was fulfilled. B.9 RetrieveStudentName Operation The operation is defined as follows: Type Name Data-type input StudentId integer output StudentName string fault fault string This operation returns the name of the given student. A fault is generated if the student does not exist. The implementation (figure B.9) will now be described: first the event that the name of a student is retrieved, is logged by using the Student-System I/O Logger. Then the name of the student is retrieved in three steps: first the input for the database-adapter is assigned by using an assign-activity. Then the database-adapter is invoked. The last step is assigning the output from the database-adapter to the output of RetrieveStudentName. Then the studentname is returned. B.10 RetrieveUniversityName Operation The operation is defined as follows: Type Name Data-type input UniversityId integer output UniversityName string fault fault string

131 B. Detailed Description of Central Register s Operations 130 Fig. B.10: BPEL-implementation of RetrieveUniversityName Fig. B.11: BPEL-implementation of RetrieveCourseName This operation returns the name of the given university. A fault is generated if the university does not exist. The implementation (figure B.10) will now be described: first the event that the name of a university is retrieved, is logged by using the Student- System I/O Logger. Then the name of the university is retrieved in three steps: first the input for the database-adapter is assigned by using an assign-activity. Then the database-adapter is invoked. The last step is assigning the output from the database-adapter to the output of RetrieveUniversityName. Then the university-name is returned.

132 B. Detailed Description of Central Register s Operations 131 B.11 RetrieveCourseName Operation The operation is defined as follows: Type Name Data-type input CourseId integer output CourseName string fault fault string This operation returns the name of the given course. A fault is generated if the course does not exist. The implementation (figure B.11) will now be described: first the event that the name of a course is retrieved, is logged by using the Student-System I/O Logger. Then the name of the course is retrieved in three steps: first the input for the database-adapter is assigned by using an assign-activity. Then the database-adapter is invoked. The last step is assigning the output from the database-adapter to the output of RetrieveCourseName. Then the course-name is returned.

133 C. DETAILED DESCRIPTION OF THE TESTCASEGENERATION OPERATION In this chapter, the implementation of Generator/Collector s operation Test- CaseGeneration is described in greater detail. First an Java-object is created which represents the student-made system. This is needed to be able to invoke the student-made system. The field Test- CaseAmount states how many test-case inputs have to be generated and executed. A loop has been constructed to fit this purpose. This loop loops as many times as the number of test-case inputs needed. The input of a student-made system is required to be a complex data-type. This means that the input always has one or more fields. A value has to be constructed and assigned to each field of the test-case input. A loop (which is nested in the TestCaseAmount loop) is constructed for that purpose. This loop loops as many times as a complex data-type has fields. In this loop we have a case-statement which makes a distinction on the type of field. This is the Type-field in the FieldData data-type. Depending on the data-type a value is chosen, if the field has a simple data-type, or constructed, if the field has a complex data-type. If the variable has type 0, this means that the test-case input field has data-type string and that it gets its value randomly chosen from the StringList field of FieldData. If the field has type 1, this means that the test-case input field has data-type integer and that it gets its value randomly chosen from the IntegerList field of FieldData. If the field has type 2, this means that the test-case input field has data-type integer and that it gets its value randomly chosen from an integer domain which is bound by a lower bound and upper bound which are defined by the FieldData fields LowerBound and UpperBound. If the field has type 3, this means that the test-case input field has data-type boolean and that it gets its value at random (true or false). If the field has type 4, this means that the test-case input field has a complex data-type and that a complex-typed value must be constructed. ComplexType- List contains a list with elements that contain data for the construction of complex-typed values. One of these elements is randomly selected and given to the Java function createcomplextype (section ). This function returns a DataObject which is assigned to the test-case input field. The implementation of createcomplextype is similar to TestCaseGeneration. If the field has type 5, this means that the test-case input field has data-type list of string. Field StringLists contains a list of string lists. One of these string

134 C. Detailed Description of the TestCaseGeneration operation 133 lists is randomly chosen and assigned to the test-case input field. If the field has type 6, this means that the test-case input field has data-type list of integer. Field IntegerLists contains a list of integer lists. One of these integer lists is randomly chosen and assigned to the test-case input field. If the field has type 7, this means that the test-case input field has data-type list of boolean. Field BooleanLists contains a list of boolean lists. One of these boolean lists is randomly chosen and assigned to the test-case input field. If the field has type 8, this means that the test-case input field has as datatype a list of complex-typed elements. Field ComplexTypeLists contains a list of lists of data that can be used to generate complex-typed values. The function selectcomplextypelist takes a randomly chosen list out of ComplexTypeLists as input and returns a DataObject which is a list of complex-typed elements. This DataObject is assigned to the test-case input field. selectcomplextypelist uses the function createcomplextype to construct a complex-typed value from each element from the list it gets as input. If the field has type 9, this means that the test-case input field has as datatype a list of strings. The function buildstringlist takes as input parameters StringList and listsize. buildstringlist generates and returns a DataObject which contains a list of string values with the list having size listsize. This list is assigned to the test-case input field. If the field has type 10, this means that the test-case input field has as datatype a list of integers. The function buildintegerlist takes as input parameters the values of the fields IntegerList and listsize. buildintegerlist generates and returns a DataObject which contains a list of integer values with the list having size listsize. This list is assigned to the test-case input field. If the field has type 11, this means that the test-case input field has as datatype a list of integers. Again the function buildintegerlist is used. This function is overloaded to also take as parameters the values of the fields LowerBound, UpperBound and listsize. buildintegerlist returns a DataObject which contains a list of integer values which are in the integer domain specified by LowerBound and UpperBound and has size listsize. This list is assigned to the test-case input field. If the field has type 12, this means that the test-case input field has as datatype a list of booleans. The function buildbooleanlist is used. buildbooleanlist takes as input listsize and returns a DataObject which contains a list of boolean elements with size listsize. This list is assigned to the test-case input field. If the field has type 13, this means that the test-case input field has as data-type a list of complex-typed values. The function buildcomplextypelist is used. buildcomplextypelist takes as input the values from the fields Complex- TypeList and listsize. It returns a DataObject which contains a list of complex typed elements with the list having size listsize. buildcomplextypelist uses the function createcomplextype to construct the complex-typed elements. create- ComplexType gets as input randomly picked elements from ComplexTypeList. If for each field (also nested fields in case of complex-typed fields) of the student-made system s input a value is constructed and assigned, this input is ready to be used as test-case input. First the test-case input is logged using

135 C. Detailed Description of the TestCaseGeneration operation 134 the LogInput function. Then the student-made system is invoked with the constructed test-case input. The output produced by the student-made system is logged by using the LogOutput function. This is done as many times as the number of test-cases required (this is specified by the variable TestCaseAmount).

136 D. DETAILED DESCRIPTIONS OF SCOPES USED IN THE UNIVERSITY COMPONENT In this chapter, detailed descriptions are given of scopes that are used in the BPEL-implementation of the University component. University is a component that is used in the implementation of the OUS exercise (section 7.2). D.1 Scopes used in Operation CourseRegistrationRequest D.1.1 CheckCourseAvailability-scope The CheckCourseAvailability-scope (figure D.1) contains the activities that check whether the university offers the course. First the central register (operation RetrieveCourseOffers) is used to retrieve the courses that are offered by this university. This is done by using an invoke-activity. An assignment is used to assign the input of this invocation which is the identifier of the university. This assignment also sets a boolean variable named CourseIsAvailable, to false which will later be used in a foreach-structure to remember whether the course which was in the external registration-request, is offered by the university. A list of course-offers is returned by the invocation of the central register s Retrieve- CourseOffers-operation. Next comes a foreach-structure which loops through the course-offers that are in the list returned by the central register. For each course-offer is executed the following activities: An assign-activity picks the current course-offer out of the list and assigns it to a temporary variable. Then in a choice-structure is checked whether the identifier of the current course-offer is equal to the identifier of the course that is in the external registration-request. If this is the case, an assign-activity assigns true to the boolean variable CourseIsAvailable. This completes the body of the foreach-structure. What remains is a choice-structure that checks whether the course in the external registrationrequest was not in the course-offer-list (CourseIsAvailable is false). If this is the case, a fault is returned and the process terminates. Otherwise the process goes to the next scope. D.1.2 CheckStudentRegistration-scope The CheckStudentRegistration-scope (figure D.2) checks the registrations of the student that requests an external registration. First the registration is retrieved by invoking the central register (operation RetrieveStudentRegistration). The input for this invocation is the student-identifier and assigned to the input of

137 D. Detailed Descriptions of Scopes used in the University Component 136 Fig. D.1: Contents of the CheckCourseAvailability-scope

138 D. Detailed Descriptions of Scopes used in the University Component 137 Fig. D.2: Contents of the CheckStudentRegistration-scope the invoke-activity by using an assign-activity. The output of this invocation is the identifier of the home-university of the student. The next step is an assignment which assigns the input for the invocation of the database-adapter OUSDB and assigns true to the boolean variable ExistsExternalRegistration. The invocation of OUSDB tries to retrieve the exact same external registration (as is requested) from the database. If this invocation fails, it is clear that there does not exist an exact same external registration and the boolean-variable ExistsExternalRegistration is assigned false. Then a choice-structure checks for two cases. The first case checks whether the home-university of the student that requests an external registration, is equal to the university at which the students wants an external registration. If this is the case, it means the students requests an external registration at his own university and the process returns a fault and terminates. In the second case is checked whether the boolean-variable ExistsExternalRegistration is true. If this is the case, it means that the external registration already exists and the process returns a fault and terminates. If both cases evaluate to false, it means the check is passed and the scope ends. D.1.3 CheckStudentsPriorKnowledge-scope The CheckStudentsPriorKnowledge-scope (figure D.3 checks whether the priorknowledge of the student that is requesting the external-registration, is sufficient for the course in the external registration-request. First the prior-knowledge that is required for the course, is retrieved by invoking the central register

139 D. Detailed Descriptions of Scopes used in the University Component 138 Fig. D.3: Contents of the CheckStudentsPriorKnowledge-scope (operation RetrievePriorKnowledge). An assignment assigns the input for this invocation which is the identifier of the course. A list of courses is returned by the central register in case there is prior-knowledge required. In case there is no prior-knowledge required, the check is skipped and the scope ends. A foreach-structure loops through the courses in the list returned by the central register. For each course in the list, an invocation of the database-adapter OUSDB is executed to see if the database contains a result of the student for that particular course in the prior-knowledge-list that has a positive grade. The input for this invocation is assigned by an assign-activity. In case the database contains no positive result for the needed course, it means the student lacks prior-knowledge and the process returns a fault and terminates. If the foreachstructure successfully loops through all the courses, it means that the student has all prior-knowledge for the course. The check is passed and the scope ends. D.1.4 ExaminationsCommitteeCheck-scope The ExaminationsCommitteeCheck (figure D.4) creates an overview of the previous results of the students which requested the external registration and shows these to the examinations committee which will decide whether the external registration is accepted. First the results of the student are retrieved by invoking the OUSDB. An assignment is used to assign the input for the invocation of OUSDB. Now a variable named StudentFile with data-type StudentFile is instantiated in a snippet-activity (appendix A.4.2.6). StudentFile will contain all the results obtained by the student. The data-type StudentFile is defined as follows: Field Data-type StudentName string CourseHistory list of CourseResult Data-type CourseResult:

140 D. Detailed Descriptions of Scopes used in the University Component 139 Fig. D.4: Contents of the ExaminationsCommitteeCheck-scope

141 D. Detailed Descriptions of Scopes used in the University Component 140 Field CourseName Grade Data-type string integer Next is a foreach-structure that loops through the list of results. For each result in the list retrieved by invoking OUSDB, is retrieved the name of the course, because the results only contain the identifier of the course. The name of the course is retrieved by invoking the RetrieveCourseName-operation of the central register. The input for central register is the identifier of the course of the result and this input is assigned in an assignment before the invocation. Then as last activity in the body of the foreach-structure, the current result is added to the StudentFile in a snippet-activity. This snippet contains five statements: statement 1: A temporary variable (named TempCourseResult) with data-type CourseResult, is instantiated; statement 2: The course name that was just retrieved is assigned to TempCourseResult; statement 3: The current result is retrieved from the list and assigned to a temporary variable; statement 4: The grade in the temporary variable is assigned to the grade in TempCourseResult; statement 5: TempCourseResult is added to the StudentFile. Now the name of the student is retrieved by using the RetrieveStudent- Name-operation of the central register. Also the name of the course for which the student wants an external registration is retrieved. This is done by using the RetrieveCourseName-operation of the central register. Then the ExaminationsCommittee component is invoked with as input the studentfile of the student and the name of the student and the name of the course which the student wants to follow. The ExaminationsCommittee component will return an output which is an boolean that tells whether the external registration is accepted or denied. A choice-structure with a case that is executed if the external registration was denied, will return a fault and terminate the process. In case the external registration was accepted no cases in the choice-structure will evaluate to true and the examinations committee-check is passed. Now all checks are passed which were necessary to accept the external registration. D.1.5 RequestPayment-scope The next scope (figure D.5) will request a payment at the bank. RequestPayment invokes the RegisterPayment-operation of the Bank component. The input for this operation is assigned in an assignment before the invocation. The output of this invocation is an identifier of a payment which is stored with the external registration.

142 D. Detailed Descriptions of Scopes used in the University Component 141 Fig. D.5: Contents of the RequestPayment-scope Fig. D.6: Contents of the CreateExternalRegistration-scope D.1.6 CreateExternalRegistration-scope The CreateExternalRegistration-scope actually stores the external registration in the database using the database-adapter. This is done by assigning the input for the invocation and invoking the OUSDB component which stores the external registration in the database. Then the central register is invoked using the LogExternalRegistration-operation to log the event that an external registration was created. Then all the scopes are executed. What remains, is assigning the output which is the identifier of the payment. Then the output is returned. That completes the description of the CourseRegistrationRequest-operation of the University component. D.2 Scopes used in Operation RequestExamination D.2.1 CheckRegistrationKind-scope The CheckRegisterKind-scope (figure D.7) contains two activities. The first is an assignment which assigns true to a boolean-variable named ExistsExternalRegistration and it assigns the input for the invocation of the database-adapter. Then the invocation of the OUSDB is executed. It retrieves the external registration if it exists. If it does not exist, the invocation returns a fault and false is assigned to the boolean-variable ExistsExternalRegistration. This boolean-variable is used