Eindhoven University of Technology MASTER Student … Student SOA Lab is used in the realization of...

Eindhoven University of Technology

MASTER

Student SOA lab

Leijten, P.J.M.

Award date:2008

DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand 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 policyIf you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediatelyand investigate your claim.

Download date: 01. Jul. 2018

Student SOA Lab

P.J.M. Leijten,TU/e,

Eindhoven

November 10, 2008

ABSTRACT

This thesis describes the requirements for the Student SOA Lab. It describes theconcept developed from these requirements. It also contains all documentationconcerning the implementation of the Student SOA Lab. Moreover it containsa manual for IBM WebSphere.

CONTENTS

1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1 Context of Student Labs . . . . . . . . . . . . . . . . . . . . . . . 72.2 Project Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Outline of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Related Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4. Student SOA Lab Concept . . . . . . . . . . . . . . . . . . . . . . . . 124.1 Usage/User Requirements . . . . . . . . . . . . . . . . . . . . . . 124.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1 Exercise-independent part of the Student SOA Lab . . . . 144.2.2 Exercise-dependent part of the Student SOA Lab . . . . . 16

5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1 Supply Chain Management System . . . . . . . . . . . . . . . . . 18

5.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . 185.1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 185.1.3 Required Interface . . . . . . . . . . . . . . . . . . . . . . 205.1.4 Context-Components . . . . . . . . . . . . . . . . . . . . . 20

5.2 Open University System . . . . . . . . . . . . . . . . . . . . . . . 215.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 215.2.3 Required Interface . . . . . . . . . . . . . . . . . . . . . . 235.2.4 Context-Components . . . . . . . . . . . . . . . . . . . . . 23

6. Realization of the Student SOA Lab . . . . . . . . . . . . . . . . . . . 276.1 Realization of the exercise-independent part . . . . . . . . . . . . 27

6.1.1 COTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.1.2 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 306.1.3 Generator/Collector Component . . . . . . . . . . . . . . 326.1.4 Student-System I/O Logger Component . . . . . . . . . . 386.1.5 Execution Trace Logger Component . . . . . . . . . . . . 41

6.2 Realization of the exercise-dependent part . . . . . . . . . . . . . 436.2.1 Context-Components . . . . . . . . . . . . . . . . . . . . . 43

Contents 4

7. Case Studies Implemented in Student SOA Lab . . . . . . . . . . . . . 447.1 Supply Chain Management System . . . . . . . . . . . . . . . . . 44

7.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 447.1.2 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.3 Derived Business Processes . . . . . . . . . . . . . . . . . 477.1.4 Process Descriptions per Component . . . . . . . . . . . . 497.1.5 Test-Cases and Student SOA Lab results . . . . . . . . . 57

7.2 Open University System . . . . . . . . . . . . . . . . . . . . . . . 667.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 667.2.2 Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 677.2.3 Derived Business Processes . . . . . . . . . . . . . . . . . 687.2.4 Process Descriptions . . . . . . . . . . . . . . . . . . . . . 697.2.5 Test-Cases and Student SOA Lab results . . . . . . . . . 83

8. Comparison and Future Work . . . . . . . . . . . . . . . . . . . . . . . 89

Appendix 91

A. SOA Development in IBM WebSphere . . . . . . . . . . . . . . . . . . 92A.1 Concepts in IBM WebSphere . . . . . . . . . . . . . . . . . . . . 92

A.1.1 Component Hierarchy in IBM WebSphere . . . . . . . . . 92A.1.2 SCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93A.1.3 CEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94A.1.4 WebSphere Integration Developer . . . . . . . . . . . . . . 95

A.2 Assembly Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 95A.2.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . 96A.2.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 97A.2.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 98A.2.4 Implementations . . . . . . . . . . . . . . . . . . . . . . . 98A.2.5 Data types/Business Objects . . . . . . . . . . . . . . . . 98A.2.6 Business Object Maps . . . . . . . . . . . . . . . . . . . . 100A.2.7 Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . 100A.2.8 Human Tasks . . . . . . . . . . . . . . . . . . . . . . . . . 100

A.3 Component Implementation Types . . . . . . . . . . . . . . . . . 102A.3.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102A.3.2 WS-BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . 102A.3.3 State Machine . . . . . . . . . . . . . . . . . . . . . . . . 103A.3.4 Human Task . . . . . . . . . . . . . . . . . . . . . . . . . 104A.3.5 Interface Map . . . . . . . . . . . . . . . . . . . . . . . . . 104A.3.6 Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105A.3.7 Business Rules . . . . . . . . . . . . . . . . . . . . . . . . 105

A.4 WS-BPEL Processes . . . . . . . . . . . . . . . . . . . . . . . . . 107A.4.1 Partnerlink/Reference Partner . . . . . . . . . . . . . . . 107A.4.2 Basic Activities . . . . . . . . . . . . . . . . . . . . . . . . 108A.4.3 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Contents 5

A.4.4 Error/Event Handling . . . . . . . . . . . . . . . . . . . . 117A.4.5 Conditions and Expressions using Java/XPath . . . . . . 119

A.5 Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

B. Detailed Description of Central Register’s Operations . . . . . . . . . 121B.1 RetrieveAllStudents Operation . . . . . . . . . . . . . . . . . . . 121B.2 RetrieveAllUniversities Operation . . . . . . . . . . . . . . . . . . 121B.3 RetrieveAllCourses Operation . . . . . . . . . . . . . . . . . . . . 123B.4 RetrievePriorKnowledge Operation . . . . . . . . . . . . . . . . . 125B.5 RetrieveCourseOffers Operation . . . . . . . . . . . . . . . . . . . 125B.6 RetrieveStudentRegistration Operation . . . . . . . . . . . . . . . 127B.7 LogExternalRegistration Operation . . . . . . . . . . . . . . . . . 128B.8 LogPayment Operation . . . . . . . . . . . . . . . . . . . . . . . 128B.9 RetrieveStudentName Operation . . . . . . . . . . . . . . . . . . 129B.10 RetrieveUniversityName Operation . . . . . . . . . . . . . . . . . 129B.11 RetrieveCourseName Operation . . . . . . . . . . . . . . . . . . . 131

C. Detailed Description of the TestCaseGeneration operation . . . . . . . 132

D. Detailed Descriptions of Scopes used in the University Component . . 135D.1 Scopes used in Operation CourseRegistrationRequest . . . . . . . 135

D.1.1 CheckCourseAvailability-scope . . . . . . . . . . . . . . . 135D.1.2 CheckStudentRegistration-scope . . . . . . . . . . . . . . 135D.1.3 CheckStudentsPriorKnowledge-scope . . . . . . . . . . . . 137D.1.4 ExaminationsCommitteeCheck-scope . . . . . . . . . . . . 138D.1.5 RequestPayment-scope . . . . . . . . . . . . . . . . . . . . 140D.1.6 CreateExternalRegistration-scope . . . . . . . . . . . . . . 141

D.2 Scopes used in Operation RequestExamination . . . . . . . . . . 141D.2.1 CheckRegistrationKind-scope . . . . . . . . . . . . . . . . 141D.2.2 CheckPayment-scope . . . . . . . . . . . . . . . . . . . . . 142D.2.3 CheckRegistration-scope . . . . . . . . . . . . . . . . . . . 142D.2.4 CheckStudentsPriorKnowledge-scope . . . . . . . . . . . . 143D.2.5 CheckCourseAvailability-scope . . . . . . . . . . . . . . . 144D.2.6 TeacherEvaluatesDeliverable-scope . . . . . . . . . . . . . 144D.2.7 RegisterResult-scope . . . . . . . . . . . . . . . . . . . . . 144

E. Java Code of the Generator/Collector-Component . . . . . . . . . . . 146

F. Java Code of the ExecutionTraceLogger-Component . . . . . . . . . . 153

G. Java Code of the GetCurrentTimeStamp-Component . . . . . . . . . . 160

H. Java Code of the InputUIDRetriever-Component . . . . . . . . . . . . 161

1. ABBREVIATIONS

Term DefinitionBO Business ObjectBPEL Business Process Execution LanguageCOTS Components Off-The-ShelfEDE Educational Development EnvironmentIDE Integrated Development EnvironmentJDBC Java Database ConnectivityJMS Java Message ServiceMQ Message QueueMSC Message Sequence ChartQoS Quality of ServiceSCA Service Component ArchitectureSDO Service Data ObjectSOA Service Oriented ArchitectureUID Unique IdentifierURI Universal Resource IdentifierWID WebSphere Integration DeveloperWS-BPEL (BPEL4WS) BPEL for Web ServicesWSDL Web Service Definition LanguageXML Extensible Markup LanguageXSD XML Schema DefinitionXSL Extensible Stylesheet LanguageXSLT XSL Transformation

2. INTRODUCTION

2.1 Context of Student Labs

Modern information systems are constructed out of components from whichca. 80% is already available (Components Off-The-Shelf (COTS)). ComputerScience students have to learn to build these systems using state of the arttechnology. 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 systemusing COTS. A workflow engine, rule engine, database engine, orchestrationengine, 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 studentsshould not get stuck on technical problems caused by these technologies.

Obviously the complexity that students are confronted with, when they areimplementing their system, has also its effect on the task of the instructor. Aninstructor wants to know whether the system is correct (preferably by auto-matic checking and testing) and the instructor wants to be able to estimate theelegance of the solution. At this moment the instructor has no means and isdependent on the documentation and the presentation that is given by the stu-dents. Often there is no time available for an instructor to actually understandthe systems of students in detail.

2.2 Project Goals

In the ideal situation there would exist an educational development environ-ment (EDE) which is easy to understand, easy-to-use and which abstracts fromimplementation and integration details. COTS like a workflow engine, rule en-gine, database engine, data warehouse, etc. should be available. This meansthat students would be able to design an architecture, select the componentsthey need, configure and integrate them. Optionally students could design andimplement their own components and integrate these into their system.

The EDE will enable instructors, who create assignments, to set up thecontext 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

2. Introduction 8

by instructors. A stub is a component that is used by a student-made systemand a driver is a component that uses a student-made system.

The EDE should also provide means for an instructor to validate the systemsof students and provide insight in these systems by showing (real-time) executiontraces and data transformations. An instructor should be able to follow theactions that happen inside software components and the interactions betweensoftware components.

Software development frameworks exist which provide means to develop andintegrate software components, but they lack the functionality required. Asuited software development framework will be selected on which the EDE willbe based. This EDE implements the goals set in this project.

IBM WebSphere has been selected as base development framework, be-cause IBM WebSphere implements the concept of Service Oriented Architec-ture (SOA) and provides a number of generic COTS out-of-the-box. Moreoverintegration with other systems is supported in IBM WebSphere.

The EDE will be given the name Student SOA Lab. SOA is an architecturalstyle that supports service orientation. Service orientation is a way of thinking interms 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 theresponse. Components that are build with the SOA-principles in mind, will actas services.

The Student SOA Lab will enable students to build a (business) informa-tion system made up from components that act like services. Furthermore theStudent SOA Lab will enable instructors to evaluate and simulate the systemsdesigned 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 com-bination with the Student SOA Lab and to gain experience with IBMWebSphere;

• Research is required to invest whether there exist systems which resemblethe Student SOA Lab. Knowledge about existing educational systems canhelp in the development;

• Elicitation of Requirements for the Student SOA Lab;

• The concept for the Student SOA Lab is developed. This concept mustmeet the requirements;

• Two exercises will be developed which will be used as show-cases for theStudent SOA Lab;

• The Student SOA Lab is implemented in IBM WebSphere;

2. Introduction 9

• The Student SOA Lab is used in the realization of the two exercises toshow 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 prototypeis documented in this thesis. The Student SOA Lab is tested on two studentexercises. Both the description of these exercises as the implementation of theseexercises are documented in this thesis.

In section 3 projects/systems are discussed which are comparable to the Stu-dent SOA Lab. These systems are developed for educational purposes. Then theconcepts and requirements (Section 4) for the Student SOA Lab are describedand explained. In section 5 two exercises for which the Student SOA Lab willbe applied are described. These use cases are used to show how the StudentSOA Lab can help students and instructors. In section 6 the realization of theStudent SOA Lab will be described in detail. In section 7 the specific applica-tion of the Student SOA Lab on the two exercises (section 5) will be described.The implementation of the two exercises will be completely documented andresults from the Student SOA Lab are presented. In section 8 the Student SOALab will be compared to existing educational laboratories and potential futureresearch and opportunities will be presented. The first appendix of this docu-ment contains a manual for IBM WebSphere. This manual describes conceptsused in IBM WebSphere and how it is possible to develop systems using Web-Sphere Integration Developer (WID). WID is the development environment forIBM WebSphere. It is recommended to read the IBM WebSphere manual (ap-pendix A) before proceeding to the chapters that describe the implementationof systems. The other appendices contain the source code of components.

3. RELATED PROJECTS

In this chapter, projects will be discussed that develop or developed systemswhich 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 submissionof work in one or more files. Peach enables teachers to collect, store, evaluateand compare submitted work and results.

There are three different users defined in Peach: students, graders and teach-ers. A teacher sets up an assignment in the Peach system. A teacher does thisby preparing a ”Peach package” and deploying it to the Peach system. Gradersare able to view submissions, provide feedback and determine results. Studentsare able to join courses and/or groups, submit work and view feedback andresults. There are two types of evaluation possible in Peach: automatic andmanual. Automatic evaluation is meant for programming assignments. ThePeach system is able to do some preprocessing on a file, compile the file andcheck it by executing it and compare the outputs with the inputs. Manual eval-uation is an option when automatic evaluation is not. The evaluation is thenleft to the graders. [7]

Another project with an educational purpose is the TALER (Teaching AndLEarning Research) Lab. The goal of the Teaching And LEarning Research Lab(TALER) in the School of Information Sciences, University of Pittsburgh is todesign, develop, and evaluate tools that can support students in learning andprofessors in teaching Information Science courses [4]. Technologies that areinvolved in some of the tool of the TALER Lab are the languages C, C++, Javaand SQL. Moreover there is a tool which provides adaptive access to lectureslides, examples, quizzes and dissections (KnowledgeTree).

QuickPACK (Quizzes for Parameterized Assessment of C Knowledge) is oneof tools in the TALER Lab. It enables students to do web-based dynamic pa-rameterized quizzes for programming-related courses. The idea of QuizPACKis simple. A teacher provides the core content of a question: a parameterizedfragment of code to be evaluated and an expression that has to be evaluated bythe student at the end of the fragment execution. The system does the rest:randomly generates a question parameter, creates a presentation of the param-eterized question in a Web-based quiz, gets the student’s input, compares thestudent’s answer with the result of running the parameterized code ”behind the

3. Related Projects 11

stage”, and records the results into a server-side database [5].

4. STUDENT SOA LAB CONCEPT

The Student SOA Lab is an EDE based on existing SOA middleware, i.e. IBMWebSphere. The Student SOA Lab will be used in an educational setting toteach students to develop business information systems using SOA principles ina simplified way. Moreover, the Student SOA Lab provides means for instructorsto easily understand, simulate and evaluate the system that is designed by thestudent.

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. Thefunctionality required for both groups will be described in this section.

Instructors will use the Student SOA Lab for preparing a student exerciseand for evaluation of student-made systems.

Students will use the Student SOA Lab to build a (business) informationsystem according to the requirements defined in an exercise, in such a way thatinstructors are able to evaluate the system by means of test-cases. Furthermorethe Student SOA Lab enables students to use COTS and use predefined com-ponents which simulate services in the context of the exercise, provided by theinstructor.

Requirement 1. The Student SOA Lab must provide means for an instructorto construct exercise-dependent components (from now on referred to as context-components).

Some exercises require components that represent services that make up thecontext of an exercise. The Student SOA Lab must provide tools, which aninstructor can use to construct context-components, or documentation, whichgives guidelines on how to construct context-components.

Requirement 2. An instructor should be able to provide input by means oftest-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 orhave the Student SOA Lab automatically generate test-cases.

Testing is a very important part of software development. It starts withdefining requirements in the form of use cases. Use cases describe processeswhich are executed by the users. Later in the software development process

4. Student SOA Lab Concept 13

test-cases can be derived from these use cases with test-cases containing inputsfor the system and the expected outputs of the system for each input. Test-casesenable instructors to check whether the system behaves as intended. Studentswill 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 canchoose among different ways of providing input for evaluation and testing pur-poses. With input is meant the input that is delivered to a student-made systemfor test-case execution.

The simplest way is manual input. This means that the Student SOA Lablets the instructor provide the data that makes up the test-case input. It shouldbe possible to provide a list of test-case inputs which are executed on a student-made system sequentially.

The other way is automatic generation of test-case input. The test-caseinput will have a XML-format. This input will have one or more XML-elementswith each element having a data-type (integer, string, boolean, etc.). Values forthese elements have to be generated by the Student SOA Lab. For each elementthe instructor has to be able to provide a list from which a value for the elementcan be taken. This list can be implicit or explicit. An implicit list is a list whichis defined by given bounds. An explicit list is an actual list with a number ofelements. This explicit list can be made by the instructor, but it is also possiblethat this list comes from a database.

Requirement 3. The execution traces of test-cases executed on a student-madesystem, are retrieved and stored in a usable data-format.

With execution trace is meant the interactions among components and ifpossible the actions executed within components during execution of a test-case. 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 andexecution traces of test-cases.

A user interface must be available which enables the instructor to (re)viewthe test-case inputs, test-case outputs and the execution traces of executed test-cases. In this interface a list of inputs of executed test-cases, is available to theinstructor. By clicking on an input all the related data will become available tothe instructor. This related data contains detailed input data, a list of outputsand a report of the execution trace. Multiple kind of reports of the executiontrace are available to the instructor. The instructor will choose which kind ofreport will be shown. Detailed output data will become available when clickingon the output. The detailed data for inputs and outputs contains the identifier,timestamp and the data of the input/output. The detailed output data containson top of that an error message (if any) and the (context-)component where theoutput came from.

Requirement 5. Students should be able to select, configure and integrate thefollowing COTS into their system: rule engine, workflow engine and database


engine. Optionally the following COTS should be supported: orchestration en-gine, data warehouse, content management system and document managementsystem.

COTS are components that contain functionality that is used by businessinformation systems. There are domain-dependent and domain-independentCOTS. Here we focus on domain-independent COTS like described in the re-quirement.

A selection of these COTS should be available in the Student SOA Lab. TheStudent SOA Lab should enable students to select, configure and integrate theCOTS in their system without having to worry about the implementation ofthese components.

IBM WebSphere implements this requirement. IBM WebSphere already pro-vides a simple rule engine, state machine and BPEL-processes. BPEL-processescan be used for the implementation of business processes (workflow engine),but can also be used for orchestration purposes. State machines can also beused for orchestration. Furthermore IBM WebSphere provides for integrationwith other systems using adapters (appendix A.5). So it is possible to integratewith COTS, like a data warehouse. IBM WebSphere also incorporates a JDBCadapter which makes it possible to integrate with database engines using JDBC(Java Database Connectivity).

Requirement 6. Students should be able to design and implement softwarecomponents themselves.

Not all functionality can be fulfilled by using COTS. Sometimes there is needto design and implement a custom component.

IBM WebSphere implements this requirement. In IBM WebSphere are twoavailable 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 isbased upon the functionality provided by the SOA middleware. This becomesclear from figure 4.1, because the Student SOA Lab is placed on top of theSOA middleware. The Student SOA Lab consists of two parts. One part isdependent on the exercise that is given to the students, the other part is exercise-independent. The exercise-dependent part has to be developed and implementedper exercise. These parts are described in separate sections. Students will usethe functionality provided by the Student SOA Lab to build their systems.

4.2.1 Exercise-independent part of the Student SOA Lab

The exercise-independent part is the part of the Student SOA Lab that is thesame for each exercise. It implements requirements 1, 2, 3, 5, 6 and is requiredfor storing the data needed for the user interfaces described in requirement 4.


Fig. 4.1: Concept Architecture

IBM WebSphere has been selected as SOA middleware. As described in sec-tion 4.1, IBM WebSphere implements requirements 5 and 6. This functionalityof IBM WebSphere can be used by the Student SOA Lab to allow the integra-tion of COTS as described in requirement 5, and the implementation of customcomponents described in requirement 6, available to students.

The Student-System I/O Logger component is part of the exercise-independentpart. This component enables other components in the Student SOA Lab to logdata. This data consists of inputs and outputs related to test-cases. The datais logged in the database. This test-case data is later used for visualization oftest-cases as described in requirement 4.

The exercise-independent part also contains the Generator/Collector compo-nent. The Generator/Collector implements requirement 2. This is a componentthat can generate test-case inputs or manually takes test-case inputs as its inputand executes the test-cases on a student-made system. The input generated bythe Generator/Collector or provided by the instructor and the output that isreturned by the student-made system, is send to the Student-System I/O Log-ger, to store it in the database that is part of the exercise-independent part ofthe Student SOA Lab.

Furthermore the independent part also contains the Execution Trace Loggercomponent. The Execution Trace Logger component implements requirement3. It retrieves execution trace data from IBM WebSphere. The Execution Trace


Logger component converts this data into a format that is usable for reporting tothe instructor. The Execution Trace Logger component should be able to reportreal-time and also store the execution trace data in a database where this datawill be linked to the input of the corresponding test-case. This enables theinstructor not only to follow the execution of a system real-time but also toreview execution data of test-cases that have been executed in the past.

As mentioned, this part of the Student SOA Lab also contains a databasewhich contains input data and output data of test-cases that is logged by compo-nents 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 requirement4.

4.2.2 Exercise-dependent part of the Student SOA Lab

The exercise-dependent part is meant to provide the functionality required byrequirement 1.

This part of the Student SOA Lab will only exist if the exercise has a needfor context-components. These context-components are stubs for services thatwould have existed if the exercise was a real-life problem. This feature of theStudent SOA Lab gives the exercise designers the ability to log vital informationfor evaluation purposes, but also to represent services which make the exercisemore realistic and/or complex.

Exercise designers are completely free in designing these services using COTSand building custom components. A context-component is able to deliver infor-mation to a student-made system on request or it is possible that the exerciserequires that a student-made system sends data to a context-component forevaluation purposes. It is also possible to combine these two functionalities.

5. CASE STUDIES

Two case exercises are described which can be handed out to students. Theseexercises oblige students to use the Student SOA Lab. Students will use IBMWebSphere to implement their solutions to these exercises.

Each exercise will require from the student to design and implement a SOA-system which is composed of software components. Each component has aninterface which lets the component act as a web service. Students are encouragedto use generic COTS.

Students should use IBM WebSphere for their implementation. IBM Web-Sphere supports SOA architectures and offers some standard components likea rule group component which is comparable to a rule engine. Moreover IBMWebSphere 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 theStudent SOA Lab to give good results:

• The student-made system will receive its input from the Student SOA Laband eventually an output will be returned to the Student SOA Lab via apredefined interface that is part of the exercise. The Student SOA Lab actsas a driver. During execution, the student-made system might use context-components which log intermediate data. It is important that after thefinal output is returned to the Student SOA Lab, no more interactionshappen with the context-components. The reason is that intermediateoutputs might otherwise be logged for the wrong test-case. The reason forthis, is best given by an example. Imagine a set of test-cases which are exe-cuted sequentially. A certain test-case is being executed and it sends a finaloutput to the Student SOA Lab, but the student-made system keeps inter-acting with context-components. The Student SOA Lab assumes that thetest-case execution ended, because it received the final output and startsexecution of the next test-case. The student-made system did not endthough. By keeping interacting with the context-components, intermedi-ate outputs might still get logged, but because another test-case alreadystarted, these intermediate outputs are logged for the wrong test-case;

• Students should stick to one input and one output field per operation whenthey design interfaces for components. If this constraint is not respected,not all communication data can be logged by the Student SOA Lab. To

5. Case Studies 18

compensate for this constraint, it is possible to use complex-types for theinput and output fields. Reason for this described in section 6.1.3;

• If a component has a BPEL-implementation, the component and theBPEL-process (which is the implementation of the component) are re-quired to have the same name. The reason for this can be found in section6.1.5);

• Students are required to enable the SCA-events on the interfaces of thecomponents they have implemented and the BPEL-events in the BPEL-processes (explanation in appendix A.1.3).

In this chapter, interfaces (appendix A.2.2) and complex data-types (or busi-ness objects) (appendix A.2.5) have to be described (for example in 5.1.3). In-terfaces and complex data-types are specified in WSDL (appendix A.2.2) andXSD (appendix A.2.5). In WID (appendix A.1.4), design tools are availablethat abstract from the details in WSDL and XSD. In this document, interfacesand 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 threedifferent types of fields: input, output and fault. The type-column distinguishesthese three types. Each field has a name which is shown in the second columnand 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.5is explained, these complex data-types can be seen as records. In a table, thedifferent fields with their data-types are described. The first column of the tableis the name of the field and the second column is the data-type. A third columncan be used to describe which data is meant to be in the field.

5.1 Supply Chain Management System

5.1.1 Description

In this exercise, students will build a supply chain management system. A sup-ply chain management system is a system that manages the supply of productsamong suppliers in order to fulfill a customer’s needs. In this case it will be asoftware system that manages the supply chain. A supply chain is a chain ofsuppliers that supply each other with products that are sold to customers orused in the production process.

There are four different types of actors in this supply chain. First we have thecustomers that will place orders. Then there are two types of suppliers: factoriesand warehouses. As fourth actor there will be a service broker. On request itprovides a list of possible suppliers for a given product. This service broker willbe used by warehouses, factories and customers to retrieve the suppliers thatcan supply the products that are needed.

5.1.2 Requirements

Students must strive to incorporate the following requirements:

5. Case Studies 19

• An interface is predefined which should be used by the student-made sys-tem and is made available to the Student SOA Lab. The input of theSCM system is a customer order. The output of the SCM System has thesame fields as the input plus some additional variables that will hold theinformation whether the order was successfully processed or failed. Theinterface and input and output data-types are described in section 5.1.3;

• The SCM system must support multiple suppliers. Two types of suppliersmust 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 warehousedoes not produce any products. The delivery time of a warehouse dependson the time the ordered products are available plus a fixed delay. Awarehouse must keep its inventory replenished at all time;

• Each factory produces a particular set of products. Factories do not havean inventory. Some products might require other products as parts in theproduction process. A factory needs to procure these parts from ware-houses to be able to start the production process. The delivery time of afactory depends on the time that all parts are available plus the time ittakes to set up the production process for the product type plus the timeit 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 sup-pliers for their own orders.

• The SCM system incorporates the context-components described in sec-tion 5.1.4.

Students are encouraged to incorporate a data warehouse in their system,either by integrating an existing data warehouse into IBM WebSphere or bydesigning a simple data warehouse themselves. This data warehouse would beable to give insight in the performance of the supply chain (KPIs). It could giveinsight in the following metrics:

• Average time between an accepted order and the delivery per producttype, per supplier;

• The number of failed orders compared to the number of accepted ones;

Students are free in giving insight in other metrics.

5. Case Studies 20

5.1.3 Required Interface

An interface is predefined that the students are required to support in theirsystem. This interface will be used by the Student SOA Lab to test the student-made system. This interface has one operation named Order :

Type Name Data-typeinput input OrderInputoutput output OrderOutputfault fault string

Data-type OrderInput :Field Data-type DescriptionSupplierId string Variable that identifies the supplier where the order is placedCustomerId string Variable that identifies the customer who placed the orderProductId string Variable that identifies the product which is orderedQuantity integer How many products are ordered

The output carries the data-type OrderOutput which is defined as follows:Field Data-type DescriptionOrderId string Variable that identifies the orderSupplierId string Variable that identifies the supplier where the order is placedCustomerId string Variable that identifies the customer who placed the orderProductId string Variable that identifies the product which is orderedQuantity integer How many products are orderedPrice integer Price of the orderOrderSuccessfull Boolean Whether the order was successfully processedComments string Any comments

The OrderOutput contains the fields that are in the OrderInput. This is donefor verification and validation purposes. It would be nice if the Comments fieldis 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 student-made system to report fatal errors that might happen or to report that theorder contains contradictory data if that is the case.

5.1.4 Context-Components

There are two context-components for this exercise. These context-componentsare used for logging information that will give the instructor more insight in thestudent-made system and whether test-cases are executed successfully. Studentsare required to integrate these context-components in their systems.

The first context-component is named LogInternalOrders. The componentwill log any internal orders that might occur. With internal orders is meantthe orders that factories place for parts (that are needed for the productionprocess) and replenishment orders by warehouses. A students-made systemwill invoke LogInternalOrders to let the Student SOA Lab know which internalorders occurred.

The interface of LogInternalOrders has one operation which also has the

5. Case Studies 21

name LogInternalOrders:Type Name Data-typeinput input OrderOutputoutput Dummy string

The input has data-type OrderOutput which is described in section 5.1.3.The input will contain the data of a completed order. The output is a dummywhich forces synchronous communication. This is required for the reasons de-scribed for the constraints in the introduction of chapter 5.

The second context-component is named LogInventoryChanges. This context-component will log the changes in the inventories of warehouses during test-caseexecution. Once an inventory-change occurs, the student-made system will in-voke the LogInventoryChanges component.The interface of LogInventoryChanges has one operation which also has the

name LogInventoryChanges:Type Name Data-typeinput input InventoryChangeoutput Dummy string

The output of operation LogInventoryChanges is a dummy to force syn-chronous communication for the same reason as for LogInternalOrders. Theinput has data-type InventoryChange which is defined as follows:

Field Data-type DescriptionProductId string id of the product in the inventory of which the quantity changedSupplierId string id of the warehouse of which the inventory changedOldQuantity integer the quantity before the changeNewQuantity integer the quantity after the change

5.2 Open University System

5.2.1 Description

In this exercise, students will design a system which enables students to followany course at a university of their choice.

This exercise distinguishes the following actors: students, universities, theregistration committee, correctors (teachers), the bank, the course register andthe central register service.

5.2.2 Requirements

General requirements:

• An interface will be predefined that students must integrate in their sys-tem. This interface will make it possible for the Student SOA Lab totest the student-made system. The input and output data-types of thisinterface are also predefined and are described in section 5.2.3;

5. Case Studies 22

• Students are registered at one particular university, called their home-university. Students are able to attend courses that are given at otheruniversities;

• A university offers courses to students registered there, but also to studentsregistered at other universities;

• When a student requests a registration for a course at a university whichis not his home-university (named external registration), two registrationcommittees will have to approve the external registration. One registrationcommittee is from the home-university. The other registration committeeis from the university where the student wants to follow the course;

• A corrector is a person employed at a university who can execute studentexaminations. Whenever a student is tested for a course, a corrector willjudge the student’s work and decide whether the student completed thecourse successfully;

• Students pay a yearly lecture fee to their home-university. The paymentfor an external registration is handled by the home-university and theuniversity where the external registration was requested. A bank handlesthese payments among universities;

• The course register is used by students to retrieve available courses, uni-versities which offer a given course and prior-knowledge which is requiredfor a given course;

• The central register provides universities with certain information (section5.2.4). The central register is implemented as a context-component;

• An external registration can only be approved when the student has anactive registration at a university, the needed prior-knowledge and theapproval of the registration committees;

• Students can only attend courses and do an examination for those coursesat a university (which is not their home-university) if they have a validexternal registration for which the payment has been handled;

• A student can only successfully complete a course when s/he has success-fully made a test for the course. The test made by a student is evaluated bya 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, thisresult will be transferred to the home-university of the student;

• The tasks of the registration committees and correctors need to be handledin BPEL by using the human task activities;

5. Case Studies 23

• The student-made system must use the context-component (central regis-ter) described in section 5.2.4.

Students are free to integrate a data warehouse. This data warehouse wouldlog 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.

5.2.3 Required Interface

An interface is defined which the students are required to integrate in theirsystem. The interface is used by the Student SOA Lab to test the student-made system.

This interface is named Student and it has one operation (also named stu-dent):

Type Name Data-typeinput input CourseRegistrationDataoutput output Gradefault fault string

The fault must be used to report any exceptions that might occur in thestudent-made system to the Student SOA Lab.

Data-type CourseRegistrationData is defined as follows:Field Data-type DescriptionStudentId integer id of a studentCourseId integer id of a courseUniversityId integer id of a university

and data-type Grade:Field Data-type DescriptionGrade integer the grade received for the course


There is one context-component that the student-made system is required to use.The context-component is named CentralRegister. The CentralRegister can beused 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) andthe prior knowledge required for a course. CentralRegister also logs events suchas: the request of data by the student-made system and logging registered andcompleted payments and the creation of external registrations. Students are

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 wascreated and when a payment is completed.

This context-component is dependent on two other components: OUSCon-textDB and Student-System I/O Logger (figure 5.1). OUSContextDB is thedatabase-adapter which manages communication with the database that con-tains the data. Student-System I/O Logger is the Student SOA Lab-componentwhich is able to log outputs (intermediate outputs in case of a context-component).

The interface of CentralRegister is named CentralRegister and has the fol-lowing operations:

• RetrieveAllStudents;

• RetrieveAllUniversities;

• RetrieveAllCourses;

• RetrievePriorKnowledge;

• RetrieveCourseOffers;

• RetrieveStudentRegistration;

• LogExternalRegistration;

• LogPayment.

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 figure5.2. It contains three activities. The first is an assignment which initiates thevariable that will contain the event-data and it assigns the source to the event-data. The source is the component that logs the event and in this case thatis CentralRegister. The second activity is a snippet (appendix A.4.2.6), whichassigns a string to a field named Data. This string contains text that describesthe event that occurred. Data is a field of the input of the Student-System I/OLogger. The third activity is the activity which invokes the Student-System I/OLogger. At that moment the intermediate output is actually logged.

The detailed descriptions of the operations of CentralRegister are given inappendix B.

5.2.4.1 Data Model

The central register has a database (figure 5.3) which contains the following ta-bles: Student, Course, University, Registration, CourseOffer and PriorKnowl-edge.

Student contains the students that are available in the system. The followingfields are defined for this table: Id (Primary Key (PK)), Name. Id is theidentifier of the student and Name contains the name of the student.

Course contains the courses that are available in the system. The followingfields are defined for this table: Id (PK), Name. Id is the identifier of the courseand Name contains the name of the course.

University contains the universities that are available in the system. Thefollowing fields are defined for this table: Id (PK), Name. Id is the identifier ofthe university and Name contains the name of the university.

Registration contains the relation between students and universities. Everystudent is registered at one university. The following fields are defined for thistable: StudentId (PK and Foreign Key (FK)), UniversityId (PK, FK). StudentId

5. Case Studies 26

refers to the student. UniversityId refers the university at which the student isregistered.

CourseOffer contains the relation between courses and universities. A uni-versity offers one or more courses to students at a certain cost. The followingfields are defined for this table: UniversityId (PK, FK), CourseId (PK, FK) andCosts. UniversityId refers to a university. CourseId refers to the course that isoffered 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 thata course requires prior-knowledge. Prior-knowledge is a set of courses. Thefollowing fields are defined for this table: CourseId (PK, FK) and Prerequisite-CourseId (PK, FK). CourseId refers to a course. PrerequisiteCourseId refersto a course which is required as prior-knowledge for the courses referred to byCourseId. Courses that need more than one course as prior-knowledge will occurmore than once in this table.

6. REALIZATION OF THE STUDENT SOA LAB

Readers unfamiliar with IBM WebSphere, are advised to read sections A.1 andA.2 before reading the realization of the Student SOA Lab.

For the notation of complex data-types and interface operations, readers areadvised to read the introduction of section 5.

6.1 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 interactionamong the components. Every component is described in greater detail in sep-arate sections.

The Generator/Collector (section 6.1.3) takes input from an instructor. Thisinput is data from which test-case inputs can be retrieved or generated. TheGenerator/Collector will execute test-cases on a student-made system usingthese test-case inputs. The inputs and outputs produced by a student-madesystem are logged by using the Student-System I/O Logger -component (section6.1.4).

The Student-System I/O Logger is, as stated above, used by the Genera-tor/Collector to log test-cases (test-case inputs and test-case outputs). TheStudent-System I/O Logger is also used by context-components in the exercise-dependent part of the Student SOA Lab to log relevant intermediate outputsproduced by the student-made system during execution of a test-case. TheStudent-System I/O Logger uses the JDBC adapter component named Stu-dentSOALabDB to get access to the database to store test-case inputs and out-puts. The Student-System I/O Logger uses the Java implemented componentnamed InputUIDRetriever to retrieve the unique identifier of the last storedtest-case input to be able to relate outputs produced by the student-made sys-tem to the test-case input. The Student-System I/O Logger needs the GetCur-rentTimeStamp component to get a timestamp of the current time and datain 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 theexecution trace of a test-case.

The RegisterStudentGroup component is a very simple component imple-mented by a BPEL process (figure 6.3) with an interface with one one-wayoperation that takes as input a string which should be the unique name of astudent group. The RegisterStudentGroup component stores the name of the

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


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-casesexecuted on the system the student group developed to this particular studentgroup.

6.1.1 COTS

COTS (Components Off-The-Shelve) are software components that are readyto use and only have to be configured and integrated. The Student SOA Labshould 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, statemachine and software components that can have a BPEL-implementation orJava-implementation are available in IBM WebSphere. Moreover IBM Web-Sphere provides means to integrate third party COTS using adapters (appendixA.5).


6.1.2 Data Model

The Student SOA Lab uses a database of which an ER-diagram is shown infigure 6.4. The Student SOA Lab database contains all the data related totest-cases. In the case of the Student SOA Lab the data that is related to atest-case, is one input, one or more outputs and the execution trace data of thetest-case. The execution trace data contains the names of the components thatwere involved in the execution trace, the instances of those components andthe different events that were emitted by these instances. Events are logged attwo levels. The BPEL events which are emitted by the BPEL runtime and SCAevents which are emitted by the SCA environment. The database belongs to theexercise-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 ofwhich the system has been or must be tested by the Student SOA Lab. TheStudentGroup 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 manuallyby the instructor or generated by the Generator/Collector component. TheInput table contains the following data fields: Id (Primary Key), Data, TimeS-tamp and StudentGroupName (Foreign Key). The Id is automatically generatedand is used to identify each input. The Data field contains the input data (in aSDO-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 ini-tiated. The StudentGroupName points to the group of students whose systemthis input has been tested on.

The Output table contains all the outputs that were retrieved from test-caseexecution. The Output table contains the following data fields: Id (PrimaryKey), Data, TimeStamp, Source and InputId (Foreign Key). The Id is auto-matically generated and is used to identify each output. The Data field containsthe output data (in a SDO representation (section A.1)) as it was received fromthe student-made system. The TimeStamp field contains the date and timeof when this output was received from the student-made system. The Sourcefield contains the name of the component in the exercise-dependent part of theStudent 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 acomponent that represents a context-component and wants to log certain datafor evaluation purposes. The InputId links the output to the correspondinginput.

The Component table contains all the components that were invoked duringtest-case execution. Components can occur more than once in this table, becausecomponents are stored per test-case (thus per input). This is done to be ableto show which components were instantiated during test-case execution and tobe able to trace the test-cases related to instances and events. The Componenttable contains the following data fields: Id (Primary Key), Name and InputId(Foreign Key). The Id is automatically generated and is used to identify each


component per input. The Name field contains the name of the component andthe InputId links the component to the corresponding input.

The Instance table contains all the instances of components during test-caseexecution. The Instance table contains the following data fields: Id (PrimaryKey), Name and ComponentId (Foreign Key). The Id is automatically gener-ated and is used to identity each instance. The Name field contains the nameof the instance and the ComponentId links the instance to the correspondingcomponent.

Two different events are logged by the Execution Trace Logger -component:BPEL and SCA events. See 6.1.5 for more information on events and loggingthese events. The Execution Trace Logger -component saves the relevant eventdata in two tables in the database: BPELEvent and SCAEvent.

The BPELEvent table contains all the events that were generated during ex-ecution of BPEL processes. The BPELEvent table contains the following datafields: Id (Primary Key), GlobalInstanceId, ExtensionName, SequenceNumber,CreationTime, ApplicationData, ActivityKind, ActivityName, Operation, Fail-ureMessage and InstanceId (Foreign Key). The Id is automatically generatedand is used to identify each BPEL-event. The GlobalInstanceId is the identifierthat is given to the event by IBM WebSphere. The ExtensionName holds thename of the kind of event that was emitted. The SequenceNumber is a numberwhich states the position of the event in the order in which events were gener-ated. The CreationTime contains the date and time of the moment that theevent was generated. The ApplicationData holds the data that was processedby the activity that emitted the event. Case application data does not exist forevery BPEL-event. The ActivityKind holds the kind of activity that emittedthe 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 areceive activity. FailureMessage holds the message that describes the error incase an BPEL-activity failed. The InstanceId links the event to the correspond-ing instance. Not every field is used by each kind of event. Only those fieldsactually used by an event will have a value in the database for that particularevent.

The SCAEvent table contains all the events that were generated by theSCA environment during interaction of components. The SCAEvent tablecontains the following data fields: Id (Primary Key), GlobalInstanceId, Exten-sionName, SequenceNumber, CreationTime, SourceComponent, SourceInterface,SourceOperation, SourceModule, TargetComponent, TargetInterface, TargetOp-eration, TargetModule, ApplicationData and InstanceId (Foreign Key). TheId is automatically generated and is used to identify each SCA-event. TheGlobalInstance, ExtensionName, SequenceNumber and CreationTime have thesame meaning as they do for BPEL-events. An SCA-event is an event thatdescribes the event that one component invokes another component. The in-voking component is the source and the invoked component is the target. Foreach component the module (SourceModule/TargetModule), name (SourceCom-ponent/TargetComponent), interface (SourceInterface/TargetInterface), opera-tion (SourceOperation/TargetOperation) are stored in the database. If there


is data communicated from the source component to the target component,this data is stored in the ApplicationData field. The InstanceId identifies theinstance to which the SCA-event belongs. This is the instance to which thesource component belongs.

6.1.3 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 initiatesthe student-made system, and logging the input, output and execution traceof the test-case by invoking the Student-System I/O Logger. The initiation-component is part of the student-made system and is made available to theGenerator/Collector by the export and import mechanisms which are describedin section A.1.1.

The Generator/Collector can be used in two ways. The first way is provid-ing test-case inputs manually. These test-cases will be executed sequentially.This is done by using the interface operation named TestCaseManual. The sec-ond way is providing data from which test-case inputs are generated by theGenerator/Collector. This is done by using the interface operation named Test-CaseGeneration.

There are constraints for the interface of the student-made systems: theoperation of the student-made system’s interface, which is used for executingthe test-cases, is allowed to have one input field and one output field. Theinput field and output field must have complex data-types (A.2.5), because theGenerator/Collector is implemented to expect the input and output to have acomplex data-type. The Generator/Collector would be even more complex ifboth simple and complex data-types were allowed for inputs and outputs.

Another constraint is that the interface of the student-made system’s compo-nent that handles the incoming test-case input, needs to be set to synchronouscommunication, because the Generator/Collector is not able to handle responsesfrom asynchronous communication.

The TestCaseManual and TestCaseGeneration operations rely on other func-tions to be able to log the inputs and outputs, these functions are described insection 6.1.3.3. Furthermore the Generator/Collector depends on SDO (ap-pendix A.2.5.1) to be able to handle the data in variables which have a complexdata-type.

6.1.3.1 TestCaseManual Operation

TestCaseManual is the operation of choice when the instructor wants to test thestudent-made system with pre-made test-cases. TestCaseManual is a one-wayoperation and therefore has no output.

Operation TestCaseManual is defined as follows:Type Name Data-typeinput input TestCaseManualData


Data-type TestCaseManualData has the following fields:Field Data-typeStudentGroupName stringStudentSystemPartner stringOperationName stringTestCasesListName stringOutputName stringTestCases anyType

StudentGroupName is a field that contains the name of the student groupwhich designed the system which is tested. This variable is used to group allthe test-cases that belong to one system.

The StudentSystemPartner and OperationName are fields needed to be ableto invoke the student-made system. The StudentSystemPartner is the nameof the reference on the Generator/Collector -component, to the student-madesystem. The OperationName identifies the operation that is used to invoke thestudent-made system.

The field TestCases contains the test-case input data and is a field which isof type anyType. This means that a value of any type could be assigned to thisfield. TestCases should be assigned a list of which the elements are test-caseinputs. The elements of this list can be of any type. Because TestCases is of anytype, the system does not know what the name of the list with test-case inputsis. Therefore TestCasesListName should be assigned the name of the list oftest-case inputs. In this way the Generator/Collector has all the information tobe able to retrieve the test-case inputs from the TestCases variable and executethem.

The OutputName field should contain the name of the output field of thestudent-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 sys-tem. 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. Thisis needed to be able to invoke the student-made system. Then for each elementin the list of test-case inputs the following is done: The element is retrievedfrom the list. Remember that this element is a test-case input. The test-caseinput is logged by using the LogInput function. After that the student-madesystem is invoked with the input and the output produced is logged by using theLogOutput function. LogInput and LogOutput are described in section 6.1.3.3.

6.1.3.2 TestCaseGeneration Operation

TestCaseGeneration is the operation of choice when the instructor wants to havethe Generator/Collector generate test-cases. TestCaseGeneration is a one-wayoperation and therefore has no output. The instructor has to provide data outof which the Generator/Collector can generate test-case inputs.

Operation TestCaseGeneration is defined as follows:


Type Name Data-typeinput input TestCaseGenerationData

Data-type TestCaseGenerationData has the following fields:Field Data-typeStudentGroupName stringStudentSystemPartner stringOperationName stringNameType stringNamespaceType stringTestCaseAmount integerOutputName stringTestCaseData FieldDataList

StudentGroupName is a field that contains the name of the student groupwhich designed the system which is tested. This variable is used to group allthe test-cases that belong to one system.

The StudentSystemPartner and OperationName are fields needed to be ableto invoke the student-made system. The StudentSystemPartner is the name ofthe reference to the student-made system. The OperationName identifies theoperation 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. Tobe able to instantiate a variable of the data-type that is required by the input ofthe student-made system, the name and the namespace of this data-type haveto be given. The fields NameType and NamespaceType exist for this purpose.

The TestCaseAmount is required by the Generator/Collector to know howmany test-cases have to be generated.

The OutputName field should contain the name of the output field of thestudent-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 tobe able to log the output.

TestCaseData contains the data that is necessary to generate test-case in-puts. The Generator/Collector does not know what the input of the student-made system’s input looks like, nor does it know what the actual data is. TheTestCaseData must contain the data from which the Generator/Collector canconstruct test-case inputs. To be able to generate inputs for the student-madesystem, it is required that the input has a certain format. The Generator/-Collector can generate inputs for which the input data-type has the followingspecifics:A student-made system’s input data-type can have one or more fields. Thesevariables can be simple data-types, complex data-types, simple data-type listsand complex data-type lists. Complex data-types can be nested.

FieldDataList has the following field:Field Data-typeFieldDataList list of FieldData


FieldData is a type that is meant to hold all the information to enable theGenerator/Collector to assign a value to each field of the student-made system’sinput. This means that FieldDataList has an element for each field that thedata-type of the test-case input has.

FieldData has the following fields:Field Data-typeName stringType integerListSize integerStringList StringListStringLists list of StringListIntegerList IntegerListIntegerLists list of IntegerListLowerBound integerUpperBound integerBooleanLists list of BooleanListComplexTypeList ComplexTypeListComplexTypeLists list of ComplexTypeList

Data-type StringList :Field Data-typeStringList list of string

Data-type IntegerList :Field Data-typeIntegerList list of integer

Data-type BooleanList :Field Data-typeBooleanList list of boolean

StringList, IntegerList and BooleanList might look superfluous, but this hasto do with SDO and DataObjects (appendix A.2.5.1). SDO does not easilyhandle lists. SDO handles DataObjects which can contain a list. For thatreason these lists are contained in a DataObject.

The Name field in the FieldData data-type will contain the name of thetest-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 con-structed to have an appropriate value.The following types are available:

0: The type of the field is string. The string value is randomly selected fromthe StringList field.

1: The type of the field is integer. The integer value is randomly selected fromthe IntegerList field.

2: The type of the field is integer. The integer value is randomly selected fromthe integer domain specified by the fields LowerBound and Upperbound.


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 randomlyselected from the ComplexTypeList field.

5: The type of the field is a list of strings. The list is randomly selected fromthe StringLists field.

6: The type of the field is a list of integers. The list is randomly selected fromthe IntegerLists field.

7: The type of the field is a list of booleans. The list is randomly selected fromthe BooleanLists field.

8: The type of the field is a list of complex typed elements. The list is randomlyselected and constructed from the ComplexTypeLists field.

9: The type of the field is a list of strings. The list is randomly composed fromelements in the StringList field. The list will have the size specified in thefield ListSize.

10: The type of the field is a list of integers. The list is randomly composedfrom elements in the IntegerList field. The list will have the size specifiedin the field ListSize.

11: The type of the field is a list of integers. The list is randomly composed fromthe 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 randomlycomposed from elements in the ComplexTypeList field. The list will havethe size specified in the field ListSize.

As becomes clear from the type description, depending on which type thefield is, certain fields in FieldData are used to assign a value to the field of thetest-case input.

It is possible to nest complex data-types and because these also have tobe composed randomly, additional data-types are required to be able to con-struct these nested complex data-types. ComplexTypeList is made for generat-ing 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 toconstruct complex-typed values for nested fields (in the test-case input). Com-plexTypeList has one field with also the name ComplexTypeList :

Field Data-typeComplexTypeList list of ComplexType Generation


ComplexType Generation is a data-type which is made to contain the datato generate one complex-typed value.

ComplexType Generation:Field Data-typeFieldList List of FieldDataNameComplexType stringNamespaceComplexType string

The recursive nature of constructing values for fields becomes clear fromthe table describing ComplexType Generation. FieldList is a list of FieldData.So again it is possible to generate values for fields nested in a complex-typedfield. The NameComplexType and NamespaceComplexType are fields needed toinitialize a DataObject (appendix A.2.5.1) of the required data-type.

The implementation of TestCaseGeneration is described in greater detail inappendix C.

6.1.3.3 Java logging functions

The Generator/Collector contains in its implementation four functions whichare needed to be able to log the inputs and outputs of test-cases. These are fourfunctions of which two functions have the same name. This function name isoverloaded. An overloaded function (name) is a set of functions with the samename. Different input parameters are required to identify the functions. Thenames of these functions are LogInput, LogOutput and ParseDataObject.

LogInput is the function which is used to log test-case inputs. LogInput re-quires as its input parameters a DataObject, named InputData, and a string,named StudentGroupName. The DataObject represents the test-case inputwhich needs to be logged. The string is required to be the name of the studentgroup. 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 invokedto log the input.

LogOutput is used to log the outputs which are produced by the student-made 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 namedOutputData. The first and second implementation are very similar. The firstimplementation is used when a student-made system executes the test-case andreturns an output which is a DataObject. In the second implementation the datato be logged, is a string. A student-made system does not return a DataObjectwhen it fails to execute the test-case. In that case the exception message (whichis a string) is logged.In both implementations the LogOutput operation of the Student-System I/OLogger component is invoked to log the output.

The ParseDataObject function returns a string representation of DataOb-jects. The input parameter is a DataObject, named DO and the return type


of ParseDataObject is a string. ParseDataObject is used by the LogInput andLogOutput functions to be able to get a complete string representation of theinputs and outputs which have to be logged.ParseDataObject is required, because of the possibility that inputs and outputsof student-made systems have nested complex-typed fields. A DataObject has afunction which returns a string representation of the DataObject. The problemhere is that if the DataObject has complex-typed fields, the actual data of thesecomplex-typed fields is not shown. ParseDataObject is a recursive function andreaches into the DataObject to also retrieve a string representation of nestedcomplex-typed fields.

6.1.4 Student-System I/O Logger Component

The Student-System I/O Logger (named StudentSystemIOLogger in the imple-mentation) is a component that has a BPEL-implementation. The Student-System I/O Logger is used by the Generator/Collector to log test-case inputsand test-case outputs. The Student-System I/O Logger is also used by context-components to log outputs which are produced by the student-made systemduring execution of a test-case. The Student-System I/O Logger also logs theexecution traces of test-cases. As shown in figure 6.2 the Student-System I/OLogger depends on four other components:

• The StudentSOALabDB -component is a JDBC adapter which makes itpossible for a component to invoke a database system. This particularadapter makes it possible for the Input/Output Logger to actually storeinput and output in the database. This database is described in section6.1.2;

• The InputUIDRetriever -component (source-code in appendix H) is a Java-component (component with a Java implementation) that retrieves theunique identifier (UID) of the last test-case input that was stored in thedatabase. The UID is needed to link outputs and execution flow data totest-case inputs. It was decided to let the database generate unique identi-fiers for test-case inputs, because databases have mechanisms included forthis purpose. This means that it is not necessary to include a generatorof identifiers in the Student SOA Lab;

• The Execution Trace Logger (section 6.1.5) is a Java component that re-trieves the execution trace data and converts this into a usable formatbefore storing this data in the database;

• The GetCurrentTimeStamp-component (source-code in appendix G) whichconstructs a timestamp of the current time and data in the format: dd-MM-yyyy HH:mm:ss. This timestamp is returned to the invoking compo-nent which is the Student-System I/O Logger.

The Student-System I/O Logger component has an interface with two oper-ations: LogInput and LogOutput.


Fig. 6.5: BPEL Implementation of the Input/Output Logger


Operation LogInput :Type Name Data-typeInput input LogInputDataTypeOutput dummy string

LogInput has one input with data-type LogInputDatatype:Field TypeData stringStudentGroupName string

The LogInput operation should only be invoked by the Generator/Collector -component. Every test-case has one input. This means that the UID of an inputalso uniquely identifies the corresponding test-case.

The LogInput operation requires as input, the input data that corresponds tothe data that was used to initiate the student-made system and a StudentGroup-Name which identifies a student-group. The StudentGroupName is needed togroup all the test-cases that were run on the system of this particular student-group.

After the LogInput has been invoked the branch in the BPEL-implementationthat corresponds to this operation will be executed. The GetCurrentTimeS-tamp-component will be invoked to retrieve a timestamp of the current timeand date. The input-data will then be stored in the database together with thetimestamp and StudentGroupName by using the StudentSOALAbDB -adapter.Also the ClearCEIEvents operation of the Execution Trace Logger is invoked tomake sure that the CEI (Common Event Infrastructure) data-source is emptyand only events of the current test-case will be in the CEI data-source when thetest-case execution ends.

Operation LogOutput :Type Name Data-typeInput input LogOutputDataTypeOutput dummy string

LogOutput has one input with data-type LogOutputDatatype:Field TypeData stringSourceComponent string

LogOutput is an operation that is invoked by the Generator/Collector andby the context-components in the exercise-dependent part of the Student SOALab. The Generator/Collector invokes this operation when the final output ofthe student-made system is received.

The LogOutput operation can also be used by context-components definedin the exercise-dependent part of the Student SOA Lab to store output fromintermediate results.

After the final output has been received by the Generator/Collector, thestudent-made system should have no more instances of components runningthat possibly have context-components log intermediate outputs. Otherwise itis possible that output data is stored linking to the wrong test-case, because


another test-case has already been started. (A new UID has already been gen-erated in that case.) If the identifier of a test-case input was part of the inputof the Student-System I/O Logger, this constraint would not be necessary. Theadvantage of the current design is that components that use the Student-SystemI/O Logger are not concerned with linking test-case outputs to the right test-case input. If the constraint, stated above, is respected, all test-case outputsare related to the right test-case input automatically.

The fields of LogOutputDataType are described: the variable named Datarepresents the output data produced by a student-made system. The Source-Component is the name of the component that wants to store the output. Thiscan be the Generator/Collector or the name of a context-component defined inthe exercise-dependent part of the Student SOA Lab.

After the LogOutput operation has been invoked, the corresponding branch ofthe BPEL-process is executed. The first action in this branch is retrieving theUID of the last-logged input by invoking the InputUIDRetriever -component.The UID is required to relate the output-data to the right test-case (whichis identified by the UID of the last-logged input). Then a timestamp is re-quested from the GetCurrentTimeStamp-component. Then the SourceCompo-nent, output-data, timestamp and UID are stored in the database using theStudentSOALabDB -adapter.

If the source-component is the Generator/Collector component it means thatthe execution of the current test-case has ended and the execution flow of thelast test-case needs to be logged, parsed and stored in the database. So theExecution Trace Logger -component is invoked with the UID of the last test-caseas input.

6.1.5 Execution Trace Logger Component

The requirements for the Student SOA Lab mention the ability to retrieve tracesof the test-case’ executions (requirement 3). Multiple options were investigatedfor this purpose. One of the options was to build a component which would pro-cess all the communication among the different student-build components andpass on the requests and responses from these student-build components. Thiscomponent would act as a proxy for all communication. The advantage of thissolution is that it is independent of SOA middleware, but it has setbacks. Thecomponent would have a very complex implementation to be able to processall communication. It would be a strain on the students, because they wouldhave to integrate this component in all the interactions of the components intheir system. It is difficult for students to start designing and implementingan information system in an environment (i.e. IBM WebSphere) which is com-pletely new to them. On top of that having students integrate a componentwhich would parse all communication, is not helping. Especially because IBMWebSphere provides a built-in service (CEI) which can be easily used for exactlythis purpose without burdening students. The only setback is that the StudentSOA Lab is dependent on IBM WebSphere for this service.

The Execution Trace Logger retrieves event-information from the CEI that


is supported by IBM WebSphere. More information on the CEI is in appendixA.1.3. The Execution Trace Logger -component has a Java implementation andhas two operations available. (Source code in appendix F.)

The first operation of the Execution Trace Logger is named ClearCEIData-source and is used to clear the CEI data-source to make sure no events of otherexecutions exist. This first operation has one input and one output. This op-eration is only used to trigger the Execution Trace Logger. There is no relevantdata communicated from and to the Execution Trace Logger.

The second operation is named RetrieveEvents. This operation has one inputand one output. The input has the name UID which contains the unique identi-fier of the test-case’ input to which the execution trace belongs. RetrieveEventsretrieves all the events from the CEI data-source. The events are parsed andstored in the database related to the input with identifier UID (section 6.1.2).

The RetrieveEvents operation has a more complex implementation. Re-trieveEvents 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 aninstance of a certain component. A tree-like structure is constructed whereinstances are related to components and events are related to instances;

3. Relevant properties of events are retrieved from the XML document byusing the JDOM 1.1 for Java library. Which properties are retrieved forBPEL and SCA-events is described in 6.1.2;

4. All the gathered information about events is stored in the database. Soall the components which were invoked are stored. The instances of thesecomponents are stored and the events emitted during execution of theseinstances are stored. Using foreign keys the relations among components,instances and events are stored. This makes it possible to report on test-cases.

There are two constraints on student-made systems to make sure that theevents are logged in the right way:

• BPEL-processes and the components they belong to, should have the samename. This is needed, because BPEL-events are generated by the BPEL-process, while SCA-events are generated by the component. If a compo-nent and its BPEL-process have different names, it is impossible to relatethe SCA-events and BPEL-events.

• Interfaces of the components in the student-made system are required tohave one input and in case it has output, one output. If this constraintis not respected, the application data of SCA-events does not contain alldata.

It is assumed that the CEI is dedicated to the student-made system thatis being tested by the Student SOA Lab, because at the end of a test-case’


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 assumedto be only from the student-made system that is tested by the Student SOALab.

Another constraint is that only one instance of the Execution Trace Loggercan run at one time. If this is not respected, the CEI data-source could beemptied at a moment the execution of a test-case would still be going on andnot 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 theStudent-System I/O Logger, because then the Execution Trace Logger is invokedwith 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 morecontext-components.


Context-components are components which are designed to represent third partyservices in an exercise and/or are needed to log intermediate results using theInput/Output Logger component.

Instructors are not restricted by the Student SOA Lab in developing context-components. The Student SOA Lab provides the possibility to log intermediateresults (outputs) by using the Student-System I/O Logger. At this moment thereare no tools for instructors to help them with the specific task of designing andimplementing context-components.

7. CASE STUDIES IMPLEMENTED IN STUDENT SOA LAB

In this chapter the implementations of the two exercises described in chapter5 are described. There are minor discrepancies between the implementationsand exercise descriptions, because both exercises have been improved after theimplementations were completed.

The figures of the system architectures have the following meaning. Theblocks represent components and the cylinders represent databases. An arrowbetween a component A and a component B means that component A can invokecomponent 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 implementa-tion of the exercise described in section 5.1. The system described here, does notimplement all the requirements of the exercise exactly as they were described inthe exercise. Instead of the OrderInput and OrderOutput data-types that aredefined for the system’s interface (section 5.1.3), the data-type Order is usedwhich has the same specification as OrderOutput. Another difference is thatwarehouses only order at factories instead of both warehouses and factories.The service broker described in the exercise is here named UDDI.

7.1.1 Architecture

The SCM system has four types of actors: customers, warehouses, factories andthe UDDI. The system has components that represent the factories, warehousesand the UDDI. The customers will be triggering this system by putting ordersinto the system.

The architecture of the SCM system is shown in figure 7.1. The system willhave multiple factories and multiple warehouses. The various suppliers (factoriesand warehouses) can invoke each other. All the suppliers can invoke the UDDI.

Factories produce products. Factories do not have an inventory where theystore 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 itneeds. The production process can begin when all parts are delivered. Whenthe production process is successfully completed, the order is delivered.

Warehouses cannot produce products. A warehouse has an inventory inwhich products are stored. Warehouses need to check their inventories regularly

7. Case Studies Implemented in Student SOA Lab 45

Fig. 7.1: Architecture of the SCM system


Fig. 7.2: ER-diagram of the SCM system

and make sure that the inventory has a certain amount of each product at alltimes. Warehouses can place orders at factories. A Warehouse finds the factorywhich produces the products it needs by using the UDDI.

The UDDI is able to return a list of suppliers of a certain kind (warehouseor factory) that can supply a certain product.

The system supports quotations, which means that a customer can checkhow much an order is going to cost before the order is actually placed. Boththe warehouses and factories have the functionality to handle quotations.

7.1.2 Data Model

The ER Diagram in figure 7.2 shows the database tables that have been de-signed for this system. The architecture of the SCM system suggests that eachwarehouse, each factory and the UDDI have their own databases. In the im-plementation it is decided that one database is used by all the components toreduce the workload.

The database contains five tables: Supplier, Product, Produces, Inventoryand Dependency. One view was created named ProducesRelationOverview.

The Supplier table contains all the suppliers which are available in the sys-tem. The following fields are defined for this table: Id (Primary Key (PK)),Name, Type, Address, Phone, City and Country. Id is an identifier which isunique 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 typesare Factory and Warehouse. The rest of the fields is not used in the implemen-tation.

The Product table contains all the products that are available in the SCMsystem. The following fields are defined for this table: Id (PK), Name andDescription. Every product has a unique identifier which is stored in the Idfield. The Name field contains the name of the product. The Description fieldcontains a description of the product. In the implementation this field is ignored.


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. ProductIdrefers to a product. The price field says how many the product costs at thissupplier.

The Inventory table contains for every warehouse which products it con-tains and the quantities of those products. The following fields are defined forthis 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, arecontained 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 re-quire other products as parts in the production process. The following fieldsare defined for this table: ProductId (PK, FK), DependencyId (PK, FK) andQuantity. The ProductId refers to a product. The DependencyId refers to aproduct which is needed in the production of the product that is referred to byProductId. The Quantity says how many of the product referred to by Depen-dencyId, are needed in the production process. It is possible that multiple typesof products are needed in the production process of a product.

7.1.3 Derived Business Processes

Figure 7.3 shows what has become of the architecture shown in figure 7.1 whenit is implemented in IBM WebSphere. There are four BPEL implemented com-ponents: Factory, UDDI, Warehouse and WarehouseReplenishment.

The Factory component contains the functionality of the Factory compo-nent in the architecture. The UDDI component also holds all the functionalityas it was intended for the UDDI component in the architecture. The Ware-house and WarehouseReplenishment components together are the Warehousecomponent in the architecture. Although there is only one Factory component,one Warehouse component and one WarehouseReplenishment component, thesystem does support multiple warehouses and factories. To lower the workloadthe decision was made to let the components dynamically act as the supplierthe order was sent to. So if an order was sent to a factory named ’factory1’, theFactory component will act as ’factory1’.

Factory DB, UDDI DB and Warehouse DB are JDBC adapters (adaptersthat make communication possible with a database via JDBC). All these adaptercomponents are adapters for the same database. Multiple adapters were madeto resemble the architecture which shows a separate database for each supplierand UDDI.

The OrderQuotationRouter component is a component which routes the quo-tations and orders to the right component. For example if an order is meantfor a factory (any factory), the OrderQuotationRouter will be able to route theorder to the Factory component.


Fig. 7.3: Component-diagram of the SCM system


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 com-ponents that are described in the exercise-description (section 5.1). Thesecontext-components are integrated in the system to log vital information for theStudent SOA Lab. The StudentSystemIOLogger is the import of the Student-System I/O Logger component that is part of the Student SOA Lab 6.1.4. Thiscomponent is used by the context-components for logging purposes.

InventoryReplenishmentConstants and UDDISupplierType are componentsthat contain business rules for this system. InventoryReplenismentConstantsis used by the WarehouseReplenishment component to know when a productneeds to be replenished and what the quantity of the replenishment order willbe. UDDISupplierType is used by the Factory component and the Warehouse-Replenishment component. This component contains the rules which say atwhich supplier type a supplier can order. For example if a factory invokes thiscomponent, it will get as response that it is allowed to order only at warehouses.

7.1.4 Process Descriptions per Component

7.1.4.1 UDDI

UDDI (BPEL-implementation in figure 7.4) has an interface with one operationnamed Inquiry that is defined as follows:

Type Name Data-typeinput input Inquiry Inputoutput output Inquiry Outputfault fault string

Data-type Inquiry Input :


Field Data-typeProduct Id stringSupplier Id string

Data-type Inquiry Output :Field Data-typeSuppliers list of Supplier

Data-type Supplier :Field Data-typeId stringName stringType stringAddress stringPhone stringCity stringcountry string

The UDDI receives a product identifier and a supplier type as input. TheUDDI DB adapter is used to retrieve all the suppliers that supply that productand 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. Amapping is created which maps the output from the database adapter to theoutput of the UDDI.

7.1.4.2 Factory

Factory (BPEL-implementation in figure 7.5 and contents of scope 1 in figure7.6) has the interface named Supplier which has two operations: Order andQuotation. Order (operation):

Type Name Data-typeinput input Orderoutput output Orderfault fault string

Data-type Order :Field Data-typeOrderId stringSupplierId stringCustomerId stringProductId stringQuantity stringPrice stringComments string

Operation Quotation:


Fig. 7.5: BPEL-implementation of the Factory component


Fig. 7.6: Contents of Scope1 in the Factory process


Type Name Data-typeinput input Quotationoutput output Quotationfault fault string

Data-type Quotation:Field Data-typeOrderId stringSupplierId stringCustomerId stringProductId stringQuantity stringPrice stringComments 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. Ifthe factory does not supply the product that was in the Quotation a fault isgenerated 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 andthe process terminates. If so, the process continues to checking parts for theproduction process.The dependencies are retrieved for the ordered product. Dependencies are theproducts that are needed in the production of the ordered product. The nextstep is to order the dependencies. The following steps are repeated for eachdependency:

• 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 isnot 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 ordersucceeds, the dependency will be delivered and this order will be loggedusing the LogInternalOrders component.

If all the dependencies are received by the factory, it is ready to start productionof the ordered products. If the production process ends, the order is completedand a confirmation is returned to whoever placed the order.

7.1.4.3 Warehouse

Warehouse (BPEL-implementation in figure 7.7) also has the Supplier interfacewhich has been described in the last section.


Fig. 7.7: BPEL-implementation of the Warehouse component


The Warehouse component handles the Quotation operation the same asthe Factory component.

If the Order operation of the Warehouse component is invoked, first ischecked whether the warehouse can supply the product in the Order. If not, anerror is generated and the process terminates. If so, the inventory is checkedto see if it is sufficient for the order. If not, again an error is generated andthe process terminates. If the inventory has sufficient stock, the inventory willbe updated, because the products ordered will be removed from the inventoryand the order will be completed. A inventory change will be logged using theLogInventoryChanges component. A confirmation of a successful order is re-turned to whoever placed the order. This is done after replenishment, becausethe Student SOA Lab requires that a student-made system does not continueexecution after sending the final output (section 5).

7.1.4.4 WarehouseReplenishment

WarehouseReplenishment ’s BPEL-implementation is visible in figure 7.8 withthe contents of Scope1, Scope2 and Scope3 in figure 7.9, figure 7.10 and figure7.11 respectively. WarehouseReplenishment has the interface named Replenishwith one operation (also named Replenish):

Type Name Data-typeinput input stringoutput output string

The input in the Replenish operation is required to be the identifier of thewarehouse which requires replenishment.

The WarehouseReplenishment component will replenish the products thatneed it. The WarehouseReplenishment component will for each product of thewarehouse, perform the following steps:

• Check whether the product needs replenishment, by checking the quantityof 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 willbe performed;

• Update the economic quantity of the product, because at this moment thecomponent 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 notdelivered, an order is sent to the factory with the lowest quotation. If theorder fails, the next factory with the lowest quotation is tried. If the listwith factories is empty, the replenishment of the product fails and the nextproduct in the inventory will be checked. If the order succeeds, the productwill be delivered and this order will be logged using the LogInternalOrders


Fig. 7.8: BPEL-implementation of the WarehouseReplenishment component


Fig. 7.9: Contents of Scope1 in the WarehouseReplenishment process

component. Also the inventory will be updated. This will be logged byinvoking the LogInventoryChanges component.

7.1.5 Test-Cases and Student SOA Lab results

In this section, results from executing test-cases with the Student SOA Labare presented. A number of test-cases were executed using the manual testoperation and the automated test operation of the Student SOA Lab. Theinputs 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 mightbe shown, because it might be overwhelming. For example for a test-case canexist over 70 SCA-events.

7.1.5.1 Manual Test-Case

A test-case, using the manual test operation of the Student SOA Lab, is pre-sented in this section.

The input given to the Generator/Collector using operation TestCaseManual(section 6.1.3.1):StudentGroupName ( s t r i n g ) : SCMStudentSystemPartner ( s t r i n g ) : Suppl i e rPartnerOperationName ( s t r i n g ) : OrderTestCasesListName ( s t r i n g ) : OrderListOutputName ( s t r i n g ) : outputTestCases ( anyType ) :

OrderList ( Order [ ] ) :OrderList [ 0 ] ( Order ) :



OrderId ( s t r i n g ) : Order1Supp l i e r Id ( s t r i n g ) : W002CustomerId ( s t r i n g ) : PietProductId ( s t r i n g ) : P005Quantity ( i n t e g e r ) : 10Pr ice ( 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/Col-lector. This input has fields and nested fields for the complex-typed fields. Thefield names are presented on the left side of the colon. Between brackets isstated the data-type of the field. Indents are used to show nested fields of com-plex data-types like Order. Order[] means that the data-type of OrderList is alist of elements which have data-type Order. OrderList[0] means that it is theelement on the 0th place of the list. On the right side of the colon is given theactual 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/Col-lector using the Student-System I/O Logger :

Id Data TimeStamp StudentGroupName201 BusinessObject:

Order@51c051c(OrderId=Order1,SupplierId=W002,CustomerId=Piet,ProductId=P005,Quantity=10,Price=0,Comments=)

17-10-2008 10:24:50 SCM

The following outputs (intermediate and final) were logged by the Student-System I/O Logger :


Id Data TimeStamp Source611 BusinessObject:

Invento-ryChange@8b808b8(ProductId=P005,SupplierId=W002,OldQuantity=302,NewQuantity=292)

17-10-2008 10:24:51 LogInventoryChanges

612 BusinessObject:Order@4dd44dd4(OrderId=W002ReplenishmentOrder,SupplierId=F003,CustomerId=W002,ProductId=P003,Quantity=100,Price=300,Comments=OrderSuccessful)

17-10-2008 10:24:51 LogInternalOrder

613 BusinessObject:Invento-ryChange@44604460(ProductId=P003,SupplierId=W002,OldQuantity=264,NewQuantity=364)


614 BusinessObject:Invento-ryChange@6ebe6ebe(ProductId=P004,SupplierId=W002,OldQuantity=371,NewQuantity=271)


615 BusinessObject:Invento-ryChange@df20df2(ProductId=P003,SupplierId=W002,OldQuantity=364,NewQuantity=164)


616 BusinessObject:Order@6ae86ae8(OrderId=W002ReplenishmentOrder,SupplierId=F003,CustomerId=W002,ProductId=P003,Quantity=100,Price=300,Comments=OrderSuccessful)



Continued:Id Data TimeStamp Source617 BusinessObject:

Invento-ryChange@60006000(ProductId=P003,SupplierId=W002,OldQuantity=164,NewQuantity=264)


618 BusinessObject:Order@1d661d66(OrderId=NewOrder,SupplierId=W002,CustomerId=F001,ProductId=P003,Quantity=200,Price=1000,Comments=OrderSuccessful)


619 BusinessObject:Order@6e2c6e2c(OrderId=W002ReplenishmentOrder,SupplierId=F001,CustomerId=W002,ProductId=P004,Quantity=100,Price=1800,Comments=OrderSuccessful)


620 BusinessObject:Invento-ryChange@65666566(ProductId=P004,SupplierId=W002,OldQuantity=271,NewQuantity=371)



Continued:Id Data TimeStamp Source621 BusinessObject:

Order@3a063a06(OrderId=NewOrder,SupplierId=W002,CustomerId=F003,ProductId=P004,Quantity=100,Price=2000,Comments=OrderSuccessful)


622 BusinessObject:Order@56c056c(OrderId=W002ReplenishmentOrder,SupplierId=F003,CustomerId=W002,ProductId=P005,Quantity=100,Price=2100,Comments=OrderSuccessful)


623 BusinessObject:Invento-ryChange@23b023b0(ProductId=P005,SupplierId=W002,OldQuantity=292,NewQuantity=392)


624 BusinessObject:Order@186c186c(OrderId=Order1,SupplierId=W002,CustomerId=Piet,ProductId=P005,Quantity=10,Price=230,Comments=OrderSuccessful)

17-10-2008 10:24:57 GeneratorCollector

These outputs are intermediate outputs logged by the context componentswhich were defined for the SCM-exercise and the final output which was loggedby the Generator/Collector. By which component the output was logged canbe seen in the Source column.

For this test-case there were also 70 SCA-events retrieved from the CEI,


Fig. 7.12: Part of the MSC of the test-case with input identifier 201


and parsed by the Execution Trace Logger component. Listing 70 events isoverwhelming, but from these events it is possible to draw a Message SequenceChart (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 itis possible to generate these charts automatically. The components involvedin the test-case execution are shown in the blocks on top. The vertical linesbelow the blocks represent time-lines. Going down along a line is going forwardin time. An arrow pointing from component A to component B means thatcomponent A invoked component B at that moment in the time. A stripedarrow from component B to component A is a response from component B onan invocation by component A. A red response-arrow means that a fault wasreturned. 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: in-stances of components are ignored. In the MSC only components are visible.On the IBM WebSphere Process Server, multiple instances of a component canexist. In figure 7.12 the interactions of various instances of the same componentare connected to the same time-line.

7.1.5.2 Automated Test-Case Generation

In this section it is presented how the Generator/Collector can be used to gen-erate test-case inputs for the SCM-system.

The input given to the Generator/Collector using operation TestCaseGen-eration (section 6.1.3.2):StudentGroupName ( s t r i n g ) : SCMStudentSystemPartner ( s t r i n g ) : Suppl i e rPartnerOperationName ( s t r i n g ) : OrderNameType ( s t r i n g ) : OrderNamespaceType ( s t r i n g ) : http ://SCMLibTestCaseAmount ( s t r i n g ) : 1OutputName ( s t r i n g ) : outputTestCaseData ( Fie ldDataLis t ) :

F ie ldDataLi s t ( FieldData [ ] ) :FieldData [ 0 ] :

Name ( s t r i n g ) : Supp l i e r IdType ( i n t e g e r ) : 0L i s t S i z e ( i n t e g e r ) :S t r i n gL i s t ( S t r i n gL i s t ) :

S t r i n g l i s t ( s t r i n g [ ] ) :S t r i n gL i s t [ 0 ] ( s t r i n g ) : F001S t r i n gL i s t [ 1 ] ( s t r i n g ) : W001S t r i n gL i s t [ 2 ] ( s t r i n g ) : W002

S t r i n gL i s t s ( S t r i n gL i s t [ ] ) :I n t e g e rL i s t ( I n t e g e rL i s t ) :I n t e g e rL i s t s ( I n t e g e rL i s t [ ] ) :LowerBound ( i n t e g e r ) :UpperBound ( i n t e g e r ) :Boo leanLis t s ( BooleanList [ ] ) :ComplexTypeList ( ComplexTypeList ) :ComplexTypeLists ( ComplexTypeList [ ] ) :

FieldData [ 1 ] :Name ( s t r i n g ) : ProductIdType ( i n t e g e r ) : 0L i s t S i z e ( i n t e g e r ) :S t r i n gL i s t ( S t r i n gL i s t ) :

S t r i n g l i s t ( s t r i n g [ ] ) :S t r i n gL i s t [ 0 ] ( s t r i n g ) : P001S t r i n gL i s t [ 1 ] ( s t r i n g ) : P004S t r i n gL i s t [ 2 ] ( s t r i n g ) : P003

S t r i n gL i s t s ( S t r i n gL i s t [ ] ) :I n t e g e rL i s t ( I n t e g e rL i s t ) :I n t e g e rL i s t s ( I n t e g e rL i s t [ ] ) :LowerBound ( i n t e g e r ) :UpperBound ( i n t e g e r ) :Boo leanLis t s ( BooleanList [ ] ) :ComplexTypeList ( ComplexTypeList ) :ComplexTypeLists ( ComplexTypeList [ ] ) :


FieldData [ 2 ] :Name ( s t r i n g ) : QuantityType ( i n t e g e r ) : 2L i s t S i z e ( i n t e g e r ) :S t r i n gL i s t ( S t r i n gL i s t ) :S t r i n gL i s t s ( S t r i n gL i s t [ ] ) :I n t e g e rL i s t ( I n t e g e rL i s t ) :I n t e g e rL i s t s ( I n t e g e rL i s t [ ] ) :LowerBound ( i n t e g e r ) : 30UpperBound ( i n t e g e r ) : 41Boo leanLis t s ( BooleanList [ ] ) :ComplexTypeList ( ComplexTypeList ) :ComplexTypeLists ( ComplexTypeList [ ] ) :

One test-case input was generated by the Generator/Collector and loggedusing the Student-System I/O Logger :


Order@2bb62bb6(SupplierId=F001,ProductId=P001,Quantity=35)

17-10-2008 09:44:07 SCM

For this test-case also exist intermediate outputs and a final output similarto those listed in section 7.1.5.1. For this test-case were also the events inthe CEI retrieved and parsed by the Execution Trace Logger and stored in thedatabase.


Fig. 7.13: Architecture of the OUS system

7.2 Open University System

This implementation of an open university system is an implementation of theexercise described in section 5.2. The system described here does not implementall the requirements exactly as stated in section 5.2. There is only one regis-tration committee that needs to approve an external registration instead of tworegistration committees. This is the registration committee of the universityat which the student requested to follow a course. Another difference is thatpayments for external registrations involve the student. In the exercise thesepayments are settled between universities.

7.2.1 Architecture

The system (architecture in figure 7.13) has seven actors: student, course regis-ter, university, teacher, examinations-committee, bank and the central register.The system supports multiple students and universities. The Central Registeris 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 universitiesdifferent from their home-university.

A university must make it possible for students from other universities torequest a registration for a course (external registration). Students that havean external registration or have a normal registration should be able to do


Fig. 7.14: ER-diagram of the OUS system

examinations for courses. A university must be able to transfer a result whichhas been achieved by a student on a different university. At last, a universitymust be able to receive payments from the bank that are done by students tobe able to follow courses for which an external registration exists.

The bank has two tasks. First it must be possible for universities to requestpayments. 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 thebank.

The course register provides students with course-information. Studentscan find all the courses that are available, at which universities these coursesare 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 certainset 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 ex-ternal registrations. This is also implemented as a human-task.

7.2.2 Data Model

More than one university is supported by the system. Every university wouldhave its own database in a realistic setting. In this implementation it wasdecided that there exists one database that is used by all the universities. Thisreduces the workload, but does not reduce the functionality of the system.

The database (figure 7.14) that is used by the OUS system contains threetables: Result, ExternalRegistration and Payment. The Result table containsall 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. UniversityIdrefers to the university where the student followed the course. StudentId refersto the student who followed the course. Successful is a boolean which is set totrue when the student successfully completed the course and Grade is the gradethat the student got for his examination of the course.

The Payment table contains the payments of courses. Payment is onlyaccessible by the bank. The bank registers and completes payments. A paymentis completed when the payment is received by the bank. The following fields aredefined for this table: Id (PK), ClientId, Amount and Fulfilled. Id identifies a


Fig. 7.15: Component-diagram of the OUS system

payment and is automatically generated when a payment is registered. ClientIdrefers to the university which requested the registration of payment. Amount isthe amount that has to be payed and Fulfilled is set to true when a payment isreceived.

The ExternalRegistration table contains the external registrations. An exter-nal registration is created when a student successfully registers for a course ona university different from his home-university. The following fields are definedfor this table: CourseId (PK), UniversityId (PK), StudentId (PK), PaymentId(FK), PaymentFulfilled, Successful and Grade. CourseId refers to the coursethe student follows. UniversityId refers to the university where the course isfollowed. StudentId refers to the student that follows the course. PaymentIdrefers to the payment that needs to be payed to enable the student to actuallycomplete the course. PaymentFulfilled is set to true when the bank lets the uni-versity know that the payment was completed. Successful is set to true whenthe student successfully completes the course and Grade is the grade that thestudent got for his examination.

7.2.3 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 com-ponents in figure 7.13. These components are described in greater detail inseparate sections.

Central Register is the context-component which depends on the componentsStudentSystemIOLogger and OUSContextDB. Central Register is predefined ascontext-component and described in section 5.2.4.

There are several other components visible in the component-diagram: Stu-dentExport, RetrieveLastPaymentId and OUSDB.

StudentExport is an SCA export component (appendix A.1) of the Studentcomponent. This makes it possible for the Student SOA Lab to invoke the OUSsystem.

RetrieveLastPaymentId is used by the Bank component to retrieve the iden-


tifier of a payment. The identifier (saved in the Id -field in the Payment tablein section 7.2.2) is automatically generated by the database at the moment apayment is stored in the database. The only way to retrieve this identifier is byusing a separate component with a Java-implementation.

The OUSDB is the database-adapter that makes it possible for componentsto use the database.

7.2.4 Process Descriptions

7.2.4.1 Student

The Student component has an interface which is also named Student. Thisinterface contains one operation (named student) and this operation is definedas follows:

Type Name Data-typeinput input CourseRegistrationDataoutput output Gradefault fault string

Data-type CourseRegistrationData:Name Data-typeStudentId integerCourseId integerUniversityId integer

Data-type Grade:Name Data-typeGrade integer

The Student component represents a student and executes the steps a stu-dent would execute if he wants to follow a course at a certain university. Thefirst step is to request an external registration at the university where the stu-dent wants to follow the course. This is done by invoking the CourseRegis-trationRequest-operation of the University component. This activity has threepossible outcomes. The first possibility is the request fails. This can happenif the prior-knowledge of the student is insufficient or the university does notteach that particular course. In this case the Student component generates afault with the same message as it received from the university and the processterminates. Another possibility is that the student is requesting an externalregistration at his home-university. In this case a different fault is generated bythe University component, because an external registration is unnecessary at ahome-university. A boolean-variable is set to represent that the student is try-ing to follow a course at his own university. A payment is unnecessary, becausecourses can be followed freely at a home-university. The third possible outcomeis that the external registration is successfully registered. The boolean-variableremains set to representing that the student wants to follow the course at a uni-versity different from his home-university. This boolean-variable was initializedin the assignment-activity named Initialization.


Fig. 7.16: BPEL-implementation of Student


The next step is paying for the external registration. This is done in a choice-structure, because the payment is only necessary if an external registrationwas successfully registered. If the student is following the course at his home-university, this is unnecessary. In the choice-structure are two activities: aassignment which assigns the input for the invocation of the Bank and theinvocation of the Bank itself. This invocation represents the student paying forhis external registration.

Then there is a assignment named Assign DeliverableRequest. Here a boolean-variable named Successful is initialized to false. This variable represents the factthat the student successfully completed the course. A while-structure is placedafter the assignment. The body of the while-structure is being executed untilSuccessful is set to true. The boolean-variable can be set to true in the bodyof the while-structure. The first activity in the body of the while-structure isa human-task (appendix A.4.2.8). The human-task has the following interface(one operation):

Type Name Data-typeinput input stringoutput Deliverable string

An user-interface is generated for this human-task where the user will see theinput and must provide the Deliverable. The input is initialized with the text”Please send in deliverable!”. The generated user-interface lets the user fill ina string which will be saved in Deliverable. Then an examination is requestedat the university by invoking the RequestExamination-operation of the Uni-versity component’s interface. The input for this invocation is assigned in anassignment-activity before the invocation. The input is the deliverable retrievedby the human-task together with the input of the Student component. The out-put 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 eval-uates to true if the grade given by the corrector is six or higher. In that casean 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 newdeliverable 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 Studentcomponent. The reply-activity sends the output out and ends the process.

7.2.4.2 Course Register

Course Register has an interface named Course Register. The interface hasthree operations: RetrieveCourses, RetrieveUniversities and RetrieveNeeded-PriorKnowledge. RetrieveCourses:

Type Name Data-typeinput Dummy stringoutput CourseList CourseList

Data-type CourseList:


Fig. 7.17: BPEL-implementation of Course-Register


Field Data-typeCourseList list of Course

Data-type Course:Field Data-typeId integerName string

RetrieveCourses retrieves a list of all the courses that are available. Theoperation RetrieveAllCourses from the context-component Central Register isused to retrieve all the courses. An invocation of RetrieveAllCourses is requiredfor this. Before the invocation an assignment-activity is placed where the inputof the invocation is initialized. The invocation of RetrieveAllCourses retrievesa list of courses which is immediately ready to be send out as the output of thisoperation.

Operation RetrieveUniversities:Type Name Data-typeinput CourseId integeroutput UniversityList UniversityList

Data-type UniversityList :Name Data-typeUniversityList list of University

Data-type University :Name Data-typeId integerName string

RetrieveUniversities retrieves a list of universities. Each university in thatlist offers the course from which the identifier is given as the input of the op-eration. The context-component Central Register can return a list of courseswhich are offered by a university (operation RetrieveCourseOffers). We have touse this operation to construct the list of universities requested.

First a list of all universities is retrieved by invoking the RetrieveAllUniver-sities-operation of the Central Register component. Then in a foreach-structureis 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-typeUniversityList is initialized.

First the courses are retrieved which are offered by the university that iscurrently handled in the loop of the foreach-structure. This is done by invokingthe RetrieveCourseOffers-operation of the central register after assigning theinput of this operation. A list of courses is returned.

A new foreach-structure loops through the course-list. For each course ischecked whether the identifier of the course is equal to the identifier given asinput 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 thecourse. This means that the university must be added to the list of universities


Fig. 7.18: BPEL-implementation of the CourseRegistrationRequest-operation of theUniversity component

which is at the end of the process send out as output.

7.2.4.3 University

The University component implements the functionality described for the uni-versity. It has an interface named University which contains four operations:CourseRegistrationRequest, CourseResultTransfer, RequestExamination and Re-ceivedPayment. Scopes (appendix A.4.3.1) are used in the implementation ofthe operations CourseRegistrationRequest and RequestExamination, because theprocesses would otherwise be too overwhelming. Scopes can be used to groupactivities and hide them.

The operations are described in greater detail. The first operation is Cours-eRegistrationRequest (figure 7.18).

Operation CourseRegistrationRequest is defined as follows:


Type Name Data-typeinput input CourseRegistrationRequest Inputoutput output CourseRegistrationRequest Outputfault fault stringfault OwnUniversityFault string

Data-type CourseRegistrationRequest Input :Field Data-typeCourseRegistrationData CourseRegistrationData

Data-type CourseRegistrationData:Field Data-typeStudentId integerCourseId integerUniversityId integer

Data-type CourseRegistrationRequest Output :Field Data-typePaymentId integerCosts integer

CourseRegistrationRequest is used by students, if they want to follow a courseat a university which is different from their home-university, to request an ex-ternal registration. There are a number of checks which have to be executedand passed for a student to get an external registration. The checks are (in theorder that they are executed):

• The course which the student wants to follow must be offered by theuniversity at which the student wants to get an external registration.

• The external registrations of the student are checked. In the cases thatthe student is not registered at all, an exact same external registrationalready exists or the student requests an external registration at his home-university, the process returns a fault and terminates. Otherwise the re-quest passes the check.

• The prior-knowledge of the student is checked. If the prior-knowledge isinsufficient, a fault is returned and the process terminates.

• The last check is the examinations committee which examine the previ-ous results of the student and decide whether the external registration isaccepted.

In case all the checks are passed, a payment is requested by the university atthe bank. Then the external registration is registered in the database. Theidentifier of the payment and the costs of the course are returned to the studentas output.

The BPEL-implementation of CourseRegistrationRequest (figure 7.18) hassix closed scopes of which the first four scopes correspond to the checks described


Fig. 7.19: BPEL-implementation of the CourseResultTransfer -operation of University

before: CheckCourseAvailability, CheckStudentRegistration, CheckStudentsPri-orKnowledge, ExaminationsCommitteeCheck, RequestPayment and CreateEx-ternalRegistration. 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’ implementa-tions are also available in this appendix.

CourseResultTransfer (figure 7.19) is the next operation of the universitywhich will be described in detail:

Type Name Data-typeinput input CourseResultTransfer Inputoutput Dummy stringfault fault string

Data-type CourseResultTransfer Input :Name Data-typeCourseRegistrationData CourseRegistrationDataGrade integer

Data-type CourseRegistrationData is described in section 7.2.4.1.CourseResultTransfer is used between universities to transfer a result when

a student has successfully finished a course at a different university than his/herhome-university. This operation is used by the university where the course wasfinished. The university that executes this operation is the university which isthe home-university of the student.

First there is an assign-activity which will assign the input that is requiredlater for the invocation of the database-adapter that stores the result in thedatabase. This input contains the course-registration-data, the grade and aboolean variable named successful that says whether the course was success-fully completed. The second activity is a snippet-activity which contains onestatement that is a choice-statement. If the grade is six or higher, successful willbe assigned true. Otherwise successful will be assigned false. Now the input forthe invocation is ready and the database-adapter OUSDB is invoked to storethe result in the database.

This completes the description of the CourseResultTransfer -operation. The


Fig. 7.20: BPEL-implementation of the RequestExamination-operation of University

next operation that will be described in detail, is RequestExamination (figure7.20).

Operation RequestExamination is defined as follows:Type Name Data-typeinput input RequestExamination Inputoutput Grade integerfault fault string

Data-type RequestExamination Input :Field Data-typeDeliverable stringCourseRegistrationData CourseRegistrationData

Data-type CourseRegistrationData is described in section 7.2.4.1.RequestExamination is like CourseRegistrationRequest quite overwhelming

when seen in its whole. Therefore again scopes are used to group activities andimprove understandability. RequestExamination is used by students when theywant to send in their examination for a course. It can be used by students whichhave an external registration or by students who just want to do an examinationfor a course at their home-university.

In the CheckRegistrationKind -scope is decided whether there exists an exter-nal registration for the examination. After the scope there is a choice-structurewith a case and a otherwise. The case has a condition which tests whether therewas an external registration present. In this case there has to be checked whether


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 finisha course. Other checks are not necessary, because there exists an external regis-tration and all checks have been done before an external registration is created.If there was not an external registration present, the otherwise branch in thechoice-structure will be taken. This means that there is no external registrationfor the examination, but it is possible that the student wants do an examinationfor a course at his home-university. This is checked in the CheckRegistration-scope. If this check is successful, it is checked whether the prior-knowledge ofthe student is sufficient in the CheckStudentsPriorKnowledge-scope and whetherthe course is actually offered at the university in the CheckCourseAvailability-scope. If these checks are successful, a teacher will evaluate the deliverable thatwas send in by the student in the TeacherEvaluatesDeliverable-scope. Then theresult is stored. This is done in the RegisterResult-scope. For detailed descrip-tions of the scopes’ implementations, see appendix D.2.

This concludes the description of RequestExamination. There is one opera-tion of the University component left to describe.

This last operation is ReceivedPayment and is defined as follows:


Fig. 7.22: BPEL-implementation of the Teacher component

Type Name Data-typeinput input ReceivedPayment Inputoutput Dummy stringfault fault string

Data-type ReceivedPayment Input :Field Data-typePaymentId integerUniversityId integer

The ReceivedPayment-operation (figure 7.21) is used by the Bank componentto let a university know that a payment for an external registration has been re-ceived. First the external registration that carries the same payment-identifieras the payment-identifier in the input, is retrieved by invoking the adapter-component 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 thereare no external registration or more than one external registrations retrieved inthe database. In that case a fault is returned by the university and the processterminates. If one external registration is returned by the database, the processcontinues to the next invocation of the OUSDB which is an update of the exter-nal registration. This update sets the paymentfulfilled -variable of the externalregistration to true. This means that the payment for the external registrationhas been received. The last step of the implementation of ReceivedPayment,is logging the received payment by invoking the LogPayment-operation of thecentral register. The input for the central register is assigned in an assignmentand contains only the payment-identifier. This concludes the description of theReceivedPayment-operation and the University component in its whole.

7.2.4.4 Teacher

The Teacher component (figure 7.22) is invoked by the university if an exami-nation of a deliverable is required. Teacher has an interface that is also namedTeacher. This interface contains one operation named RequestEvaluation. Re-


Fig. 7.23: BPEL-implementation of the Examinations-Committee component

questEvaluation is defined as follows:Type Name Data-typeinput Deliverable stringinput CourseName stringoutput Grade integerfault fault string

The BPEL-implementation of Teacher is very simple. There are three activ-ities. The first is the receive-activity which receives the deliverable which needsto be evaluated and the name of the course. The second activity is a human-task (appendix A.4.2.8). This human-task has the same interface as the Teachercomponent. The reply-activity is the last activity and returns the grade thatwas given by the teacher, to the invoking university.

7.2.4.5 Examinations-Committee

The ExaminationsCommittee component (figure 7.23) is invoked by the univer-sity if a request for an external registration is received, to request the evaluationof the external registration by the examinations-committee. This component hasan interface that also carries the name ExaminationsCommittee. This interfacehas one operation named RequestExaminationCommitteeEvaluation:

Type Name Data-typeinput input1 StudentFileinput input2 Courseoutput Grade integerfault fault string

Data-type StudentFile is described for operation CourseRegistrationRequest insection 7.2.4.3. Data-type Course is described in section 7.2.4.2.

The BPEL-implementation of the ExaminationsCommittee component issimilar to the implementation of the Teacher component. It contains threeactivities: the first activity receives the student-file which contains the nameof the student and the student’s result-history, and the name of the coursefor which the student wants an external registration. The second activity is ahuman-task which requests the approval for the external registration from the


Fig. 7.24: BPEL-implementation of the Bank component

examinations-committee based on the student-file. A boolean-variable whichcontains the response from the examinations-committee, is returned to the in-voking university.

7.2.4.6 Bank

The Bank component (figure 7.24) implements the functionality that is requiredfor the bank in the OUS system. This includes two tasks: registering paymentswhich means that if an external registration is created for a student, this studentneeds to pay for this external registration. In that case the university requestsa payment-registration at the bank. The student must complete this paymentbefore he can do an examination for the course. The second task of the bank is


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 RegisterPayment-operation implements the first task of the bank. RegisterPayment is defined asfollows:

Type Name Data-typeinput input RegisterPayment Inputoutput PaymentId integerfault fault string

Data-type RegisterPayment Input :Field Data-typeAmount integerClientId integer

The operation receives as input an amount which is the height of the pay-ment and identifier of the client which is the identifier of the invoking university.There are two steps in the implementation of RegisterPayment. The first stepis storing the payment in the database. This is done by two activities: Thefirst activity is an assignment which assigns the input for the invocation of thedatabase-adapter OUSDB. This input consists of the height of the payment(amount), the identifier of the client and a boolean-variable named fulfilledwhich is initialized to false. Fulfilled represents whether the payment has beencompleted. The second activity is actually invoking OUSDB to store the pay-ment. The second step is obtaining the payment identifier which has beengenerated by the database. This is done by invoking the RetrieveLastPaymen-tId component which retrieves the last-generated identifier and returns it. Thispayment-identifier is returned to the invoking university by a reply-activity.

The MakePayment-operation implements the second task of the bank andis defined as follows:

Type Name Data-typeinput PaymentId integeroutput Dummy stringfault fault string

The operation receives as input a payment-identifier which is the identifierof the payment that has been payed. The implementation of MakePaymentconsists of two steps: The first step updates the database that a payment wascompleted. This step contains two activities. The first activity is an assignmentwhich assigns the input for the invocation of OUSDB. This input is the identifierof the payment and true to the boolean-variable fulfilled which means thatthe payment was completed. The second activity is the actual invocation ofOUSDB which updates the database. It is possible that the payment-identifierdoes not exist in the database. In that case the update will fail, a fault isgenerated and the process will terminate. The second step is informing theuniversity which registered the payment, that the payment is completed. Firstan assignment assigns the input of an invocation of OUSDB. This input is


the payment-identifier. Then the invocation is executed which will return theidentifier of the university. The last part is informing the university. Thisconsists of two activities. An invocation of the ReceivedPayment-operation ofthe 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.

7.2.5 Test-Cases and Student SOA Lab results

In this section, results from executing test-cases with the Student SOA Labare presented. A number of test-cases were executed using the manual testoperation and the automated test operation of the Student SOA Lab. Theinputs 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 mightbe shown, because it might be overwhelming. For example for a test-case canexist over 70 SCA-events.

7.2.5.1 Manual Test-Case

Two test-cases, using the manual test operation of the Student SOA Lab, arepresented in this section.

The input given to the Generator/Collector using operation TestCaseManual(section 6.1.3.1):StudentGroupName ( s t r i n g ) : OUSStudentSystemPartner ( s t r i n g ) : StudentPartnerOperationName ( s t r i n g ) : studentTestCasesListName ( s t r i n g ) : CourseReg i s t rat ionDataLis tOutputName ( s t r i n g ) : outputTestCases ( anyType ) :

CourseReg i s t rat ionDataLi s t ( CourseRegistrat ionData [ ] ) :CourseReg i s t rat ionDataLi s t [ 0 ] ( CourseRegistrat ionData ) :

StudentId ( i n t e g e r ) : 1CourseId ( i n t e g e r ) : 10Un ive r s i ty Id ( In t ege r ) : 3

CourseReg i s t rat ionDataLi s t [ 1 ] ( CourseRegistrat ionData ) :StudentId ( i n t e g e r ) : 7CourseId ( i n t e g e r ) : 15Un ive r s i ty Id ( In t ege r ) : 5

For an explanation on the notation, see section 7.1.5.1.The test-case inputs that were logged to the database by the Generator/-

Collector using the Student-System I/O Logger :



CourseRegistra-tionData@9ba09ba(StudentId=1,CourseId=10,UniversityId=3)

20-10-2008 09:30:55 OUS

222 BusinessObject:CourseRegistra-tionData@9d409d4(StudentId=5,CourseId=15,UniversityId=5)

20-10-2008 09: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:


Id Data TimeStamp Source701 Event: Courses that are

offered by universitywith id 3 are retrieved.

20-10-2008 09:31:04 CentralRegister

702 Event: Id of thehome-university ofstudent with id 1 isretrieved


703 Event: Prior Knowledgeof course with id 10 isretrieved.


704 Event: Name of thestudent with id 1 isretrieved


705 Event: Name of thecourse with id 10 isretrieved


706 Event: Externalregistration was created:StudentId: 1,UniversityId: 3,CourseId: 10,PaymentId: 30


707 Event: Payment with id30 is fulfilled.


708 Event: Name of thecourse with id 10 isretrieved


709 BusinessObject:Grade@731c731c(Grade=7)

20-10-2008 09:33:07 GeneratorCollector

These outputs are intermediate outputs logged by the context-componentswhich were defined for the OUS-exercise (CentralRegister) and the final outputwhich was logged by the Generator/Collector.

For this test-case there were also 40 events retrieved from the CEI, andparsed by the Execution Trace Logger component. Listing 40 events is over-whelming, but from these events it is possible to draw a Message SequenceChart (MSC). In figure 7.25 this MSC is visible. For the explanation of thenotation of the MSC, see section 7.1.5.1.

7.2.5.2 Automated Test-Case Generation

In this section it is presented how the Generator/Collector can be used to gen-erate test-case inputs for the OUS system.

The input given to the Generator/Collector using operation TestCaseGen-eration (section 6.1.3.2):


Fig. 7.25: MSC of the test-case with input identifier 221


StudentGroupName ( s t r i n g ) : OUSStudentSystemPartner ( s t r i n g ) : StudentPartnerOperationName ( s t r i n g ) : studentNameType ( s t r i n g ) : CourseRegistrat ionDataNamespaceType ( s t r i n g ) : http ://OUSLibTestCaseAmount ( i n t e g e r ) : 5OutputName ( s t r i n g ) : outputTestCaseData ( Fie ldDataLis t ) :

F ie ldDataLi s t ( FieldData [ ] ) :F ie ldDataLis t [ 0 ] ( FieldData ) :

Name ( s t r i n g ) : StudentIdType ( i n t e g e r ) : 2L i s t S i z e ( i n t e g e r ) :S t r i n gL i s t ( S t r i n gL i s t ) :S t r i n gL i s t s ( S t r i n gL i s t [ ] ) :I n t e g e rL i s t ( I n t e g e rL i s t ) :I n t e g e rL i s t s ( I n t e g e rL i s t [ ] ) :LowerBound ( i n t e g e r ) : 1UpperBound ( i n t e g e r ) : 11Boo leanLis t s ( BooleanList [ ] ) :ComplexTypeList ( ComplexTypeList ) :ComplexTypeLists ( ComplexTypeList [ ] ) :

F ie ldDataLis t [ 1 ] ( FieldData ) :Name ( s t r i n g ) : CourseIdType ( i n t e g e r ) : 2L i s t S i z e ( i n t e g e r ) :S t r i n gL i s t ( S t r i n gL i s t ) :S t r i n gL i s t s ( S t r i n gL i s t [ ] ) :I n t e g e rL i s t ( I n t e g e rL i s t ) :I n t e g e rL i s t s ( I n t e g e rL i s t [ ] ) :LowerBound ( i n t e g e r ) : 1UpperBound ( i n t e g e r ) : 21Boo leanLis t s ( BooleanList [ ] ) :ComplexTypeList ( ComplexTypeList ) :ComplexTypeLists ( ComplexTypeList [ ] ) :

F ie ldDataLis t [ 2 ] ( FieldData ) :Name ( s t r i n g ) : Un ive r s i ty IdType ( i n t e g e r ) : 2L i s t S i z e ( i n t e g e r ) :S t r i n gL i s t ( S t r i n gL i s t ) :S t r i n gL i s t s ( S t r i n gL i s t [ ] ) :I n t e g e rL i s t ( I n t e g e rL i s t ) :I n t e g e rL i s t s ( I n t e g e rL i s t [ ] ) :LowerBound ( i n t e g e r ) : 1UpperBound ( i n t e g e r ) : 6Boo leanLis t s ( BooleanList [ ] ) :ComplexTypeList ( ComplexTypeList ) :ComplexTypeLists ( ComplexTypeList [ ] ) :

Five test-case inputs was generated by the Generator/Collector and loggedusing the Student-System I/O Logger :



CourseRegistra-tionData@1b801b8(StudentId=10,CourseId=2,UniversityId=1)

20-10-2008 09:51:51 OUS

224 BusinessObject:CourseRegistra-tionData@3cee3cee(StudentId=9,CourseId=12,UniversityId=3)

20-10-2008 09:51:55 OUS

225 BusinessObject:CourseRegistra-tionData@18a018a(StudentId=6,CourseId=20,UniversityId=2)

20-10-2008 09:51:58 OUS

226 BusinessObject:CourseRegistra-tionData@5dc05dc(StudentId=1,CourseId=2,UniversityId=2)

20-10-2008 09:52:02 OUS

227 BusinessObject:CourseRegistra-tionData@478a478a(StudentId=7,CourseId=2,UniversityId=4)

20-10-2008 09:52:06 OUS

For these test-cases also exist intermediate outputs and a final output similarto those listed in section 7.2.5.1. For these test-cases the events in the CEI wereretrieved and parsed by the Execution Trace Logger.

8. COMPARISON AND FUTURE WORK

In this chapter a comparison will be made with existing systems and futurework and opportunities are presented.

The Student SOA Lab is innovative, because it combines actual developmentin an IDE, with education. The two other projects (Peach and TALER) thatwere described in chapter 3 are different in that they do not involve the de-velopment of systems by students. The Student SOA Lab provides some greatadvantages in that sense over other educational systems. Moreover the Stu-dent SOA Lab also enables students themselves to test and evaluate their ownsystems.

Peach provides automatic evaluation (or validation) for some kind of as-signments. Moreover peach completely manages courses and all the submittedwork of students. The Student SOA Lab is able to group the test-cases for onestudent-made system, but it does not manage the student-made systems in anyway (by storing these systems in some place).

There is still work to be done on the Student SOA Lab. At this moment theredo not exist graphical human interfaces (GUI) for the interactions with the Stu-dent SOA Lab which were described in requirement 4. The GUI would enableinstructors to execute the test-cases on the student-made systems. Moreover itshould be possible to review the executed test-cases (inputs, intermediate out-puts and final outputs) and extract certain diagrams and reports, like messagesequence charts (MSC), execution traces of BPEL-processes and verificationbased on intermediate outputs and final outputs.

There should be research about metrics and diagrams that could possiblybe extracted from the test-case data, i.e. inputs, intermediate outputs, finaloutputs, BPEL-events and SCA-events. MSCs can be constructed from SCA-events. The automatic construction of these MSCs should be designed andimplemented. The BPEL-events could be used to construct execution traceswithin BPEL-processes. Maybe other metrics and/or diagrams could be con-structed out of test-case data and presented to instructors in reports.

The Student SOA Lab has currently two ways of setting up input for test-cases: manual and automated. In the automated input generation, it is at themoment not possible to use a database which holds test-case inputs while it wasa requirement for the Student SOA Lab. This is something that needs to bedesigned and implemented in the future.

Validation is another future requirement for the Student SOA Lab. At thismoment the validation is supported by the Student SOA Lab by means of loggingevents, i.e. intermediate outputs, and the test-case output. The validation itself

8. Comparison and Future Work 90

must be done manually by the instructor. Research should be done to automaticvalidation of student-made systems. An option could be another frameworkwhich uses the Student SOA Lab as it is now, to extract test-case data andcompare it with an architecture of the student-made system. This architecturecould be described as a set of Petri-nets or in any other modeling language. Thisframework could analyze the test-case data and hold it against the architectureto see whether the implementation violates the architecture.

The Student SOA Lab is at the moment not able to visually show the real-time execution of a test-case. The CEI can emit Java-events on receiving SCA-and BPEL-events. This can be used for the real-time representation of a test-case. This is something which should be looked at.

Since the Student SOA Lab is dependent on the IBM WebSphere for theBPEL- and SCA-events, it is not possible to retrieve events for a system whichis implemented on another platform, like Oracle SOA. An event concept shouldbe developed. This concept should incorporate the definitions, emitting andretrieving of events on different levels, i.e. on SCA-level, BPEL-level, but maybealso BPEL-activity-level.

APPENDIX

A. SOA DEVELOPMENT IN IBM WEBSPHERE

This appendix is a manual for IBM WebSphere. It gives information aboutconcepts important for understanding IBM WebSphere. Moreover it explainsthe various implementations available for components in IBM WebSphere anda 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 knowl-edge is needed to understand how IBM WebSphere is set up and will helpunderstand 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 ina 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 morecomponents that can interact with one another. The unit that is deployed tothe IBM WebSphere Process Server is a module. This means that IBM Web-Sphere Process Server is the runtime environment for modules. IBM WebSphereProcess 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 sendingan input, and returns an output. A module contains multiple components, buta module can also act as a service by exporting one or more components. Anexample 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 amodule A, an export component Q with a SCA-binding of component Y needs tobe generated. This component Q is placed in module B. An import componentP with a matching binding needs to be generated in module A. This importcomponent P will be importing the export component Q. Now it is possiblefor component X to invoke component Y via import component P and exportcomponent 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 ableto invoke P.

An export-component is a component which makes it possible for compo-nents running in environments outside of the module to invoke component X. It

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 com-ponents which are adapters, because adapters are import-components. Thereare different bindings for the export-components depending on the protocol re-quired. Different technologies use different protocols for communication. Thebinding-type determines which protocol-conversion is applied by the export-component. For example it is possible to invoke a component in a modulefrom a PHP-script. This would require a SOAP/HTTP-binding for the export-component. The export-component will translate the invocation by the PHP-script which uses the SOAP/HTTP-protocol, to the protocol which is used forcommunication between the components contained in a module and deployedto the IBM WebSphere Process Server. The response from the component isconverted from the protocol used internally in the module, to SOAP/HTTP.So the PHP-script can receive the response. There are bindings available forSCA, JMS, MQ and Web Services. For a PHP-script to be able to invoke anexport-component, it requires the URI of the export-component. For inter-module communication (communication between SCA-modules, as described inthe example), the component that wants to invoke an export-component doesnot require a URI of this export-component, but instead an import-componentis generated which is placed in the module of the invoking component. By in-voking the import-component, the request is passed on to the export-componentin the other module. An import-component requires the same interface as theexport-component it refers to. A good practise is to place the interface ofthe export-component (originally the interface of the component for which theexport-component was generated) in a library. This library can then be im-ported in the project in which the module is being designed which contains theimport-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 isresponsible for the description of a component. It is a component-model. SCAdistinguishes three parts that make up a component: interface, references and


the implementation. This means that in theory, components can have all kindsof implementations as long as they handle the operations that are described inthe interface of the component.In practice IBM WebSphere provides six kinds of implementations for compo-nents (described in appendix A.2.4).

A big advantage of SCA is loose coupling. Loose coupling is part of the SOAprinciples. Loose coupling means: making as few assumptions as possible aboutthe systems that invoke a component and about the systems which a componentinvokes. The interface of a component (appendix A.2.2) contains no endpointinformation of systems that invoke it. The references on a component (appendixA.2.3) have an interface-reference which is required to be set, but the actualcomponent-reference (endpoint) is not required to be set. This means that acomponent can be implemented without needing the components it dependson. These can be set later (dynamically at runtime is a possibility) as longas the interfaces of these partner components are specified. The advantages ofloose coupling are easy-change and independence of technology. Easy-changemeans that it is easy to replace a component as long as the same interface isused. Independence of technology means that various technologies can be usedto 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 CEI

The CEI (Common Event Infrastructure) is what IBM WebSphere uses to emit,store and retrieve events. The Common Base Event is a default model thatis used for describing events. IBM WebSphere has a set of standard eventsthat can be emitted. IBM WebSphere has different runtimes that are used forexecuting business modules. The SCA-runtime is the environment in whichdifferent components run. This runtime does not care for what happens duringthe 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 differentruntimes for executing the implementations of components. One of these isthe BPEL-runtime. This runtime is used to execute BPEL-processes. TheSCA-runtime and BPEL-runtime are able to emit events. The BPEL-runtimeis able to emit events when certain BPEL-activities are executed. The SCA-runtime 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 CommonBase Event-model has certain default properties which do not hold interestingdata. There is one property which can be used to hold data that does not fitother properties. This versatile property is used by IBM WebSphere. If anevent is emitted this property will hold all the relevant data in the form of aXML-document. The XML-document seems not to be consistent. The XML-document’s layout seems to be depending on the kind of event, but this doesnot hold in all cases. The XML-documents that are part of SCA-events havean acceptable consistency to be able to construct an message sequence chart of


executed test cases. BPEL-events will be logged to the database but are at themoment not used for analysis.

The emitting of events has to be switched on manually. SCA-events can beswitched 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 ofan operation has an Event Monitor -tab. Here can be set whether all events, orno 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 invokedwith that particular operation. An exit-event is emitted when the component’sexecution ends. A failure-event is emitted when a component ends because ofan error.

The emitting of BPEL-events has to be switched on in the properties of aBPEL-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 EventSetting-tab where predefined events for a number of BPEL-activities can beswitched on. Finally for each separate BPEL-activity there are a number ofevents 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 providedfor development of webSphere technology. It is based on the Eclipse-framework.Eclipse is a well-known extendable development environment. WID providestools for the development of various technologies: J2EE, EJB, Web, SCA-modules, etc.. It is mainly directed on development for the IBM WebSphereProcess Server.

In WID the developer will create projects. In a project, software can bedeveloped. The scope of this paper remains on SCA-modules. A module isdeveloped in a project. A developer may define interfaces, data-types, data-transformations, implementations and components and the way componentsinteract. WID also provides tools for testing components and testing compo-nents in isolation. In WID, a module can be deployed to the IBM WebSphereProcess Server.

It is also possible to develop libraries which may contain interfaces, data-types and data-transformations. These libraries can be imported in projects.This makes it possible to use an interface in different modules. This is requiredif components from different modules invoke one another.

A.2 Assembly Diagram

The Assembly diagram is the architectural overview of the SCA-module youare developing in your project. It shows all the components that are includedin your project and the way they refer to each other. It can be seen as thearchitecture of the system. IBM has separated the different parts that makeup a component. Interfaces, references, data-types and implementations areindependent of a component. This makes it possible to develop all these parts


Fig. A.2: Assembly Diagram

separately and to re-use them. Obviously when you want to use a component, itneeds an interface, an implementation, possibly references to other componentsand probably variables.

A.2.1 Components

The components are the main building blocks in modules. Every componentconsists of three parts: the interface, the references and the implementation.The interface defines how a component can be used by others. These others canbe components in other modules, but also a PHP-script or any other technologyfor which a binding exists (via generated export-components).

The components have an implementation of a certain type. The possibleimplementations in IBM WebSphere are Java, BPEL, business rule, state ma-chine, human-task and selector. Adapters can also be seen as components, butin this document they will be handled separately since adapters are generatedand cannot be developed like components.

The interface and implementation can be developed separately, but obviouslyit is required that the implementation handles the operations defined in theinterface. When a component is invoked by another system, an instance of thatcomponent is created. Multiple instances of the same component can exist atthe same time. Once a component instance reaches the end of the process, theinstance will be destroyed by the server.

A component is stateless by itself. This means that once a component in-stance is destroyed all the variables are destroyed as well. Once a componentis invoked, the created instance doesn’t know anything about what any otherinstances of that component did.


An instance of a short-running component is created once the component isinvoked. The instance is executed and destroyed after the response is given. Thiscomponent can have only one receive-activity and that is the receive operationat the start of the process. This receive-activity also creates the instance. Ashort-running component can also have no human-tasks.

It is possible to have receive-operations in the middle of a component’s pro-cess and/or human-tasks in a process. These components are required to belong-running, because it can block on a receive activity or human-task. In bothcases 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 tosend a message. In case of blocking on a human-task, the process must wait fora human to complete a task. This also requires a mechanism to find the rightinstance of a component, because it must be possible to send a message to theright 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 definedin the Web Service Definition Language (WSDL). WSDL is a language basedon XML.

Interfaces contain one or more operations. Operations can be of type: one-way or request-response. A one-way operation has one or more inputs and nooutputs. A request-response operation contains one or more inputs and one ormore outputs. The input is given by the invoking component. The output is theresponse of the invoked component. Every input and every output has a nameand a data-type. These data-types can be simple-types like string, integer or


boolean. It is also possible to use complex-types or business objects (appendixA.2.5).

Interfaces have certain properties which can be set. One property is thepreferred interaction style which is either asynchronous, synchronous or any.Any is used when the decision of synchronous or asynchronous-communicationis left to the WebSphere Process Server. Interfaces also have Quality of Service-properties (QoS) which are for example security-properties or data-validationproperties. On an interface it is also possible to enable the emitting of SCA-events.

A.2.3 References

References are used by components to interact with other components. Areference is part of a component and consists of an interface-reference and acomponent-reference (or wire to a component). The interface-reference setsthe interfaces which the reference can refer to. So it can only refer to compo-nents with the same interface as the interface that is set on the reference. Thecomponent-reference is used to set the partner component. This is actually awire to another component. This means that a certain reference can only beused for components with a certain interface. A component-reference does nothave to be set, but a partner component can only be invoked if the endpoint isset using a wire to another component.

References have, like interfaces, certain properties that can be set. A prop-erty is the multiplicity. By default this is set to 1..1, which means that areference must have exactly one component wired to it. Another possibility is0..n. This means that a reference can have zero or more components wired toit. Components that have references with a 0..n-multiplicity can only have aJava-implementation. References have QoS-properties that can be set. Theseproperties are for example timeout- and reliability-properties.

A.2.4 Implementations

Every component needs to be assigned an implementation. Implementations canbe developed independently of a component. The interface and component typeneed to match the component’s interface and type though. Implementations canbe in Java or BPEL. An implementation can also be a Rule Group (which issimilar to a rule engine) or a state machine. More information on the possibleimplementations 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 referredto as Business Objects (BO) in the WebSphere Integration Developer (WID).This can be confusing because for some technologies, objects contain the dataand classes describe the structure of the data.


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 existtools for designing data-types. These complex data-types are presented in WIDlike records or structs (as in popular programming languages). So a complexdata-type has multiple typed fields. The type of a field in this record, can be acomplex data-type or a simple data-type again. It is possible to present complexdata-types like a tree-structure. A developer does not need knowledge of XSDto work with data in WID.

Variables used in BPEL-processes are typed and can have simple data-typeslike integer, string and boolean. The variables can have type also have complexdata-types. The variables can be used in expressions in BPEL. These expressionscan be described in XPath or Java. The variables behave as objects in Java oras XML-documents if XPath is used.

A.2.5.1 SDO

If a component has a Java-implementation and there are variables used in thecomponent’s interface that have complex data-types, the Service Data Object(SDO)-framework is used to interact with the variables. SDO provides a unifiedframework for access to data. SDO has a Java API which can be used to workwith data from multiple kinds of data sources like relational databases, entityEJB 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 objectof this class represents a certain data source. The functions defined in theDataObject class, provide ways of accessing and manipulating the data in this


data source. For each data source an object of the DataObject class must beinstantiated. Variables which are used in IBM WebSphere and have a complexdata-type, can only be handled in a Java component by using SDO. Thesevariables 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 ofanother data type. These mappings are implemented in XSL-transformations(XSLT) (XSL stands for Extensible Stylesheet Language). Developers are notconfronted with the XSLT language. WID provides tools for designing thesemappings. These mappings can be used in the BPEL-activity Business ObjectMap (appendix A.4.2.7) to map one variable to another, and in the interfacemap-component (appendix A.3.5).

A.2.7 Correlation

Correlation is a BPEL-construct that is used for referencing the right instance ofa component. Correlation is required in components with a BPEL-implementationwhich contain receive-activities that do not instantiate the component and com-ponents that have a state machine as implementation. (Notice that a BPEL-process can be the implementation of a component. BPEL-process and BPEL-implementation are definitions that can be interchanged.) What happens is thatwhen 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 newinstance, if it does not exist. In practise it means that an instance is chosenbased on data in the input field (or one of the input fields) of the operation thatinvokes a component that supports correlation.

There are certain requirements for the BPEL-process and interface of a com-ponent to be able to use correlation. The ’Join Transaction’ qualifier of the com-ponent’s interface needs to be set to false and the process that uses correlationneeds 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 inprocesses. There are three kinds of human tasks: to-do tasks, invocation tasksand collaboration tasks. The to-do task is a task that is scheduled for a humanby an automated service. An invocation task is a human invoking an automatedservice. A collaboration task is a human scheduling tasks for other humans.

A to-do task has an interface like a component. This interface can haveonly one operation. The input of this interface-operation is presented to thehuman and the output is returned by the human. The output holds the actionsperformed by the human. If a to-do task is scheduled by a service, it is insertedin a task queue. A human can claim a task if his role is assigned to the task.


If the task is claimed, the task cannot be claimed by another person. Nowthe human that claimed the task can execute the task. By executing the taskis meant, the human must do the actions required by the task. This can bemanipulating the data that was given as input, or just checking the data forerrors. The person has two options after executing the task, he/she can save thetask and open it again later or actually completing the task. Completing a taskmeans 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 atask, 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 isrequired to be the same as the interface from the service it invokes. The inputgiven by the human is passed to the service and the output produced by theservice passed back to the human. An invocation task can be done by a humanwith 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 otherhumans. These subtasks are completed by humans before the parent-task iscompleted. Follow-on tasks are tasks where a human completed a part of thetask and creates a follow-on task where another human completes the rest of thetask. WID does not provide visual tools for designing subtasks and follow-ontasks. The task API (Java API) is required for this purpose.

Security is organized by assigning roles to human tasks. Only humans whohave a role which is assigned to a task, can perform the task.

Another important aspect of human tasks are escalations. Escalations areexecuted when certain events are triggered. There exist three kind of escalations:ready, claimed and subtask. The ready-escalation is triggered, if a task is longerin the task queue than a certain period of time. The claimed-escalation istriggered, if a task is claimed longer than a certain period of time without beingcompleted or released. Finally the subtask-escalation is triggered, if a subtaskexists for too long. If an escalation is triggered, notifications are sent to certainpeople. These notifications are kept being sent until the task reaches a certainstate. For example if a task is claimed for too long, the person who claimed it,will receive e-mails 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 possibleto have the WID automatically generate Java Server Faces (JSF). Other tech-nologies available by default are IBM Lotus Forms and Business Space. Anout-of-the-box system for handling human tasks is Business Process Choreogra-pher Explorer. This is a web interface which enables users to execute tasks, butalso start any component designed in WID and get insight in running processesand finished processes.


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 oneor more references to other components. The interface operations of a javaimplemented component are handled by java functions. Each operation of theinterface has one java function to handle the operation. Each input fields of anoperation is represented as an argument of the java function. The name of thejava function is the same as the name of the interface operation and the returntype of the java function is the same as the data type of the operation’s outputfield.

Java as implementation requires an interface operation to only have oneoutput field, since the operation will be handled by a Java-function and Java-functions can have multiple parameters, but only one output. This limitationcan 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 anotherimplementation type. BPEL is an XML-based language which is meant for de-scribing processes and orchestration. The WS extension stands for Web Servicesand this means that the processes will act as services. A service handles a re-quest from another component and gives a response back. A BPEL-implementedcomponent requires one interface and can have one or more references to othercomponents. In BPEL, these references are named Partner-Links. The refer-ences of the component it implements have to match the partner-links definedin the BPEL-process.


BPEL describes a business process like a work-flow. There is a starting-pointof the process and an end-point. In between there are all kinds of structuresand activities. There are structures which influence the path of activities thatis 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. Thestate machine-component has one interface and one or more references to othercomponents. A state machine-implementation consists of states and transitions.Transitions are the arrows between states. A transition is ’fired’ (a state-changewill occur) if the state machine component is invoked with an interface operation


that is linked to a transition that is an outgoing arrow of the current state ofthe state machine.

States have options. When entering or exiting a state an action can beexecuted. These actions are implemented with java. It is also possible to let theaction be an invocation of a partner component.

Transitions have also options. A transition is required to have an interface-operation linked to it unless a time-out is set. In that case after a certain periodthe transition is fired automatically. It is also possible to give a transition acondition. This means that a transition will only be fired if the condition is trueat the moment of invoking the appropriate interface-operation. The conditionis implemented as a java snippet. The last option is the possibility to attach anaction 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 long-running component. Correlation is used to identify instances. State machine-implementations are not used by the IBM WebSphere Process Server. Insteada BPEL-process is generated from the State machine-implementation at themoment a state machine is deployed.

A.3.4 Human Task

The human task-component is a component that can be dropped on the assem-bly diagram. This component has an interface or a reference (impossible to haveboth).

If the component has a reference, it implements an invocation task. Theinterface 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 interfaceof the component is the same as the interface of the task. This component isinvoked 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.4.2.7. This component canbe used when component x needs to invoke component y which has interfaceA, but the reference on component x expects interface B. The interface mapcomponent can be used to map the inputs and outputs of interface operations.The interface map component would in this example have interface B and areference which refers to interface A of component y. The implementation ofthe interface map component would map the inputs of the operations of inter-face B to the inputs of the operations of interface A and map the outputs ofthe 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 componenty with interface B. The interface map component uses business object maps forthe mappings between the various fields of the operations.


A.3.6 Selector

Fig. A.9: Example of a Selector component

The selector component is a component that is used to dynamically relaythe invocation of components. This means that based on certain conditions acomponent is invoked. The conditions on which the decision is based to whichcomponent the invocation is relayed, is based on a date and time. So if acomponent invokes the selector-component, the input is relayed to component xbased on whether the current time and date fall in a period of time which is setfor component x. The periods set for various components may not overlap. Theselector 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 berouted in case there is no component for which a period of time is set in whichthe current time and date falls.

By default an invocation is relayed to a component based on the current timeand date. The ”current” time and date can be changed in Java. This meansthat the selector thinks it is a certain time while it is not. This can be used todynamically route invocations based on other conditions than the current timeand date.

The selector does not show the components to which it can relay invocationsin the assembly diagram. This can be confusing, because it is not immediatelyclear that the selector depends on components that are defined in the samemodule.

A.3.7 Business Rules

Fig. A.10: Example of a Business Rules component

The business rules component represents a simple rule engine. The businessrules component can be invoked by a service. Based on the existing businessrules and the input, a output is returned. There can be different business rulesdefined depending on which operation of the business rules’ interface is invoked.It is also possible to have different rules depending on the current time anddate. This uses the same mechanism as described for the selector component(appendix A.3.6).


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 containvariables. These rules and actions may use the variables.

An action just executes a statement. This statement may contain variablesdefined in the rule set or the input and output variables of the operation thatwas used to invoke the business rules-component.

A rule consists of a condition and an action. The action is executed if thecondition is true. This condition can depend on the input that was given to thebusiness rules-component and/or on variables defined in the rule set itself whichcannot be null. These variables can be assigned values by actions or rules whichare executed before the current rule. The action of a rule can assign values tothe 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 ofdifferent rules overlap and the same variable is assigned a value in the actionsof these rules, then the variable will have the value of the last rule (lowest inWID).

There are templates available for the rules in a rule set. These templates maycontain parameters which are used in the actual rule definition. A textual rep-resentation of the rule should be inserted. This textual representation describesthe rule in natural language and may contain the names of the parameters used


Fig. A.12: Example of a decision table

in the template. A business rule can be defined out of a template. The param-eters should be instantiated by actual values to be able to use the rule. A webinterface is available which makes it possible to add, remove and edit businessrules which use a template, on runtime. Only the textual representation of therule is available in the web interface.

In figure A.11 is an example visible of a rule set. It contains one variable, oneaction, two rules and one template. The execution order is Action1, Rule1 andthen Rule2. Rule2 is an instance of Template1. Template1 has two parameterswhich are used in the condition and the action.

A decision table has condition rows and action rows. Depending on thevalues of the variables in the condition rows, values in the action rows areassigned to variables. This is best explained using an example. In figure A.12an example of a decision table is given. If field1 and field2 of input1 have value1 and input3 has value ”x” then output1 is assigned ”a” and field2 of output2is assigned the calculated value of the expression ”input1.field2 + 1”.

The business rules component supports the execution of simple businessrules. For more sophisticated business rules, there exists an ILOG-adapter forIBM WebSphere. ILOG is an advanced rule engine.

A.4 WS-BPEL Processes

A.4.1 Partnerlink/Reference Partner

A partnerlink or reference partner as IBM calls it represents a link with anothercomponent to interact with. In WID these partnerlinks are generated from thereferences of the particular component. The generation of partnerlinks is doneat the moment the implementation of that component is generated. Addingpartnerlinks when an implementation already exists is not trivial. The easiestway of doing this is by right clicking on the component in the assembly dia-gram and clicking on ’to implementation’ from the ’Synchronize Interfaces andReferences’-menu and then ’from implementation’ from the same menu. Theimplementation’s interface and reference partners and component’s referencesand interfaces are synced. Partnerlinks are used by a number of BPEL activ-ities. Invoke is an activity used to invoke another component. Receive andReceive Choice are activities which handle the invocation of other componentsand store the input in a variable. Reply is the activity which replies the outputback to the invoking component (if it is two way communication). Reply only


Fig. A.13: Reference and partnerlink

follows after a Receive or Receive Choice activity, because there has to exist aninvoking partner.

A.4.2 Basic Activities

Basic actions are actions which do not encapsulate other activities or changecontrol flow. To add an activity to the process, click on the activity you wantto add to select it. Then click on the place in the process view where you wantto add the process.

A.4.2.1 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 seenas 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-activitymust be used for cases where the assignment lacks the functionality. The Assign-activity can have one or more sub-assignments. (These sub-assignments are ofthe 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 avariable or a sub-element of a variable. The ’from’ part of the assignment can bea 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 Assign-activity (not supported by WID at this moment). IBM only supports ’copy’ for


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. InWID, snippets have to be used for manipulating arrays/lists.

A.4.2.2 Invoke

The Invoke activity is the activity that is used to invoke other components. Tobe able to have an invoke activity invoke another component, this componenthas to be added as partnerlink. The Invoke activity needs a partnerlink, thepartnerlink’s interface and the operation that needs to be invoked. Furthermorevariables need to be linked to the parameters of the interface’ operation. It isimportant that the variables that are used as input are initialized using anAssign activity or snippet before the Invoke is executed.

A.4.2.3 Receive

Receive is the activity for receiving a request message. In a short-running com-ponent with BPEL-implementation, the Receive activity is what initiates theprocess. This means that an instance of the component which is invoked, iscreated. The connection between the instance of the component that invokesand the instance of the component that is invoked is created automatically.The Reply that might follow (depending on whether the invoked operation hasoutput fields), calls back to the right instance of the invoking component auto-matically. It is possible to have a Receive activity as not being the initiator ofa component (the component is long-running). In this case correlation needs to


Fig. A.15: Invoke activity

be used. A Receive needs a partnerlink, its interface, interface operation andvariable(s) linked to the operation’s input parameter(s). The variable(s) willget the value(s) of the parameter(s) when the receive activity is executed.

A.4.2.4 Receive Choice

The Receive Choice is comparable to Receive. The only difference is that thisactivity is used when the interface of the process has more than one opera-tion. The Receive Choice manipulates control flow based on which operation istriggered. This means that the part of the process that handles the initiated op-eration is executed and parts of the process which are meant to handle differentoperations are ignored. The rest is the same as Receive.

A.4.2.5 Reply

The reply-activity follows after a receive or receive-choice-activity if it is ex-pected by the partner component (two way communication, which means thatthe operation has output fields).

A reply needs a reference partner, the right interface, operation and anoutput variable.

It is possible to have multiple Reply activities. In this case correlation isused to know the partner to reply to.

The Reply-activity is also used to return business faults if these are definedin the interface.


Fig. A.16: Example of a visual snippet

A.4.2.6 Snippet

The Snippet-activity is not a standard BPEL activity. It is invented by IBMto compromise for shortcomings in the WS-BPEL standard. It has a widerange of functionality, because it allows developers to use Java. A snippetcan be used in two ways. It is possible to just write Java code. Anotherpossibility is the visual Java. visual Java is a visual representation of Java code.It allows developers to make Java statements using blocks, simple expressionsand 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 input-connectors and zero or one output-connectors. The input-connectors are theparameters of the function and the output-connector (if it exists) is the outputreturned by the function. In Java it is possible to have functions that returnvoid, which means there is no output returned. So it is possible to have blockswithout output-connectors. Developers are able to design blocks in WID. Alot of standard blocks are available by default. For example there are blocksavailable for array/list manipulation, date/time, type converters, business objectmanipulation, business object mapping, math, logic, text manipulation, etc.

In figure A.16 an example of visual snippet is given. It has two statementswhich can be seen from the two vertical lines with a curl at the bottom on theleft side. The first statement is the execution of a Java function. This functionremoves an item at a certain index from a list. This function is representedby the block. It has two parameters: the list and the index of an item. Thisis represented by the two connectors on the left side of the block. The firstconnector is the list and the second connector is the index. These are connectedto expressions which provide the values of the parameters. It is allowed to useoperators in expression-boxes. These are the same operators as available forexpressions in the Java language. The connector on the right side of the blockis the output of the Java function it represents. In the figure the connector isnot used, which means that the output is not used in any way. The secondstatement represents an assignment. The calculated value of the left expressionis assigned to the variable in the right expression. The left expression is allowedto contain operators. The right expression needs to be a variable.


Fig. A.17: Closed scope

A.4.2.7 Business Object Map

A business object map-activity is a generated visual Java snippet. In this snip-pet a business object mapping is executed. This mapping takes as parameteran input variable and an output variable. The data in the input variable istransformed so it fits the output variable.

A.4.2.8 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 interfaceof the to-do task have variables in the BPEL-process. The variable that isassigned 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.4.2.9 Wait

The Wait activity is what the name suggests. It is possible to have a simpletimeout. The process won’t continue until the timeout has occurred. It ispossible to set a date and time. The process will not continue until that dataand time has been reached.

A.4.3 Structures

A.4.3.1 Scope

A scope is used to group activities and give them a name. A scope can beconfigured to be isolated. This means that the activities within the scope cannotuse variables declared outside the scope. It is allowed to nest scopes. It ispossible to add certain handlers to a scope like compensation handlers, eventhandlers and fault handlers (appendix A.4.4).


Fig. A.18: Opened scope

A.4.3.2 Parallel Activities

Parallel activities represents the Flow activity described in the BPEL-standard.The parallel activities component has more functionality than the standard flowas described in the BPEL-standard. The parallel activities allows parallelismof activities in the body of the parallel activities-construct. It does not allowcycles.

It is possible to have activities executed in parallel as the intended function-ality of the Flow activity. Activities which do not have links pointed to themwill be executed whenever the Parallel Activities component is executed (figureA.20).

It is possible to require activities to have ended before another activity canbe executed. In Figure A.21 Assign1 and Assign3 have to be completed beforeAssign2 can be executed.

It is also possible to put conditions on links. Depending on whether thecondition is true or false the link will be ’activated’ resulting in executing theactivity the link is pointing to. The conditions are implemented with XPath ora Java.

A.4.3.3 Cyclic Flow

The cyclic flow-construct is similar to the parallel activities-construct in thatactivities can be put in the body and the execution order of those activitiescan be controlled in a graph-oriented manner by adding links between theseactivities. The difference between the cyclic flow and parallel activities is thatcyclic flow does not allow parallelism while it does allow cycles. So it is possible


Fig. A.19: Parallel activities




Fig. A.22: Parallel activities with conditions


Fig. A.23: Choice

to go back and repeat activities. The conditions on the arrows between theactivities decide the execution order.

A.4.3.4 Sequence

A sequence is comparable to a scope, but it lacks the handlers that can beadded to a scope. In BPEL, all activities are part of sequences. In WID thesesequences can be hidden. It is allowed to nest encapsulation components likesequences and scopes.

A.4.3.5 Choice

The Choice activity is comparable to a case distinction in regular programminglanguages (not an if-then-else). There are one or more cases, depending on howmany cases are needed, with each a condition and there is a case named other-wise which is taken when all the other case conditions lead to false. Otherwise isnot required to exist. It is possible to do nothing and go on with the rest of theprocess if not one of the cases is true and there does not exist an otherwise. Theconditions of the cases are implemented using Java or XPath. The activities inthe 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 firstcase (most left) is executed.

A.4.3.6 While-Loop

The while loop is comparable to the while loop in regular programming lan-guages. As long as the condition is true, the activities in the body of thewhile-loop are executed. The condition is implemented using Java or XPath.


Fig. A.24: While

A.4.3.7 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 comparablewith the foreach statement that is found in C#. It is possible to have an indexvariable loop through all the elements of an array. Another possibility is tohave the index variable loop through a static range of integer values. It is alsopossible to have a dynamic range of integer values. By choosing expression inthe type field, it is possible to calculate the bounds of the range. Java is used forcalculating both the lower bound and the upper bound of the range. The index-variable of the for each-construct can be used in Java and XPath expressions inactivities in the body of the for each-construct.

A.4.4 Error/Event Handling

A.4.4.1 Activities

There are four activities for error handling: throw, rethrow, terminate andcompensate.

The throw activity is used to throw a fault, but this fault must be handledin the enclosing scope within the process. Otherwise it will be returned to theinvoking system as a runtime exception. Replying business faults to invokingsystems is done with the reply-activity.

The rethrow-activity enables the process to rethrow a fault to an enclosingscope in case it can not be handled by the current fault handler or in case theenclosing scope has to be made aware. The rethrow-activity is only available in


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 compensation-activity is executed, the compensation handler of the scope which is set as targetactivity is executed. If a compensation-activity does not have a target activityset, all the compensation handlers of scopes that exist within the scope in whichthe compensation-activity is placed, are executed.

A.4.4.2 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 ex-ception occurs. This can be for a specific fault or exception, or any fault orexception. After the activities in the fault handler are executed, the processcontinues after the activity or scope which generated the fault/exception.

A compensation-handler is only available for scopes in a long-running pro-cess. This handler is meant to balance a process after an unexpected errorhappened. A compensation-handler is an isolated sequence of activities whichis executed in the following three cases:

• A compensation activity with its target activity set to the scope of thecompensation handler. This compensation activity must be in a fault orcompensation of an enclosing scope.


Fig. A.26: Condition in visual Java

• A compensation activity with no target activity. This compensation ac-tivity must be in a fault or compensation of an enclosing scope.

• An unhandled error occurs in an activity of the scope of the compensationhandler.

The event-handler is a sequence of activities that is executed when a certainevent happens. This event can be a user-defined alarm or invocation by anothersystem.

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, vari-ables 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 theywere XML-documents. For creating Java expressions and conditions, the devel-oper will the same editor in WID as is used for snippets (appendix A.4.2.6). Itis possible to write Java code or create visual Java. In visual Java a return-construct is available for conditions. In that case an expression which is of typeboolean or output-connector which returns a boolean value, must be connectedto the return-construct (figure A.26). In XPath it is possible to create con-ditions, but only really simple ones since it is not possible to assign values tovariables, to use complicated functions (as Java-functions) and make multiplestatements. These three great advantages has Java over XPath. The XPathcondition bpws:getVariableData(’input1’)¿5 has the same meaning as the visualJava condition in figure A.26.

Note: an important difference between XPath and Java is how lists areindexed. The first item in a list has in Java index 0, but in XPath 1. Thelast item in a list has in Java index n-1, while in XPath it has n (n being thesize of the list). This is important when using the index-variable of a for each-construct in a Java expression, since this variable goes from 1 to n while in Javait is expected to go from 0 to n-1.

A.5 Adapters

Adapters are the components that realize integration from other systems withIBM WebSphere. There are two types of adapters: inbound and outbound.


An outbound adapter is invoked by components in the module it is placed.Outbound adapters exist for the following systems: CICS, IMS, email, flat file,FTP, JDBC, JD Edwards EnterpriseOne, PeopleSoft, SAP and Siebel.

An inbound adapter invokes components in the module it is placed. Thisadapter cannot be invoked. Inbound adapters exist for the following systems:email, flat file, FTP, JDBC, PeopleSoft, SAP and Siebel. An inbound adaptercan be a polling service. This is the case for email for example. The adapter willkeep polling the email server for new mail. If a new email arrives, the adaptercan convert the email in a variable supported by IBM WebSphere, and send itto another component for processing. An inbound adapter can also be a servicewhich passes requests from other systems to components within its module.

Adapters are generated by WID depending on certain parameters. Thereare wizards where the required information needs to be given to WID by theuser after which the automatic generation starts.

It is possible to implement custom adapters. This is described in [6].

B. DETAILED DESCRIPTION OF CENTRAL REGISTER’SOPERATIONS

In this chapter, detailed descriptions of the operations of the CentralRegisterare given. CentralRegister is the context-component for the supply chain man-agement system exercise (section 5.1).

B.1 RetrieveAllStudents Operation

The operation is defined as follows:Type Name Data-typeinput dummy stringoutput StudentList StudentList

Data-type StudentList :Field Data-type DescriptionStudentList list of Student a list that contains elements of data-type Student

Data-type Student :Field Data-type DescriptionId integer id of the studentName 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 re-turning of the list of students 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 database-adapter whichwill retrieve the complete list of students from the database. The third activityis a business object map which converts the list retrieved from the database tothe format of the RetrieveAllStudents-operation’s output (StudentList). Thenthe list is ready to be returned (using the Reply-activity).

B.2 RetrieveAllUniversities Operation

The operation is defined as follows:Type Name Data-typeinput dummy stringoutput UniversityList UniversityList

B. Detailed Description of Central Register’s Operations 122

Fig. B.1: BPEL-implementation of RetrieveAllStudents

Fig. B.2: BPEL-implementation of RetrieveAllUniversities


Fig. B.3: BPEL-implementation of RetrieveAllCourses

Data-type UniversityList :Field Data-type DescriptionUniversityList list of University a list that contains elements of data-type University

Data-type University :Field Data-type DescriptionId integer id of the universityName string name of the university

This operation will return a list of all universities that are defined in thesystem.

The implementation (figure B.2) contains the logging of the event that thestudent-made system retrieved the list of universities, and the retrieving andreturning of the list of universities itself. The retrieving of the list needsthree BPEL-activities. The first activity is the initialization of the input ofthe database-adapter. The second activity is the invocation of the database-adapter which will retrieve the complete list of universities from the database.The third activity is a business object map which converts the list retrievedfrom the database to the format of the RetrieveAllUniversities-operation’s out-put (UniversityList). Then the list is ready to be returned (using the Reply-activity).

B.3 RetrieveAllCourses Operation

The operation is defined as follows:Type Name Data-typeinput dummy stringoutput CourseList CourseList


Fig. B.4: BPEL-implementation of RetrievePriorKnowledge

Data-type CourseList :Field Data-type DescriptionCourseList list of Course a list that contains elements of data-type Course

Data-type Course:Field Data-type DescriptionId integer id of the courseName 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 re-turning of the list of courses 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 database-adapter whichwill retrieve the complete list of courses from the database. The third activityis a business object map which converts the list retrieved from the database tothe format of the RetrieveAllCourses-operation’s output (CourseList). Thenthe list is ready to be returned (using the Reply-activity).


B.4 RetrievePriorKnowledge Operation

The operation is defined as follows:Type Name Data-typeinput CourseId integeroutput CourseList CourseListfault 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 givencourse 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 alist. 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 consistentsolution.

The implementation (figure B.4) contains the logging of the event that thestudent-made system retrieved the prior-knowledge of a given course, and theretrieving and returning of the list of courses which are the prior-knowledge ofthe 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 coursesthat are the prior-knowledge of the given course. Then the list is converted tothe CourseList data-type by using a business object map-activity. The list hasnow the needed elements and the required data-type. The elements are lackingthe name of the courses. So for every element of the list, the course-name needsto 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 course-name. 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 courseis retrieved by invoking the database-adapter. A last assignment is needed toactually 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 idand the name of each course.

B.5 RetrieveCourseOffers Operation

The operation is defined as follows:Type Name Data-typeinput UniversityId integeroutput CourseList CourseListfault 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 universitydoes not exist.


Fig. B.5: BPEL-implementation of RetrieveCourseOffers

The implementation (figure B.5) contains the logging of the event that thestudent-made system retrieved the course-offers of a given university, and theretrieving and returning of the list of courses which are offered by the givenuniversity. The retrieving of the list of courses needs the following steps: firstthe input of the database-adapter is assigned. This is the given universityid. The next step is invoking the database-adapter which will return a list ofcourses that are offered by the given university. Then the list is converted tothe CourseList data-type by using a business object map-activity. The list hasnow the needed elements and the required data-type. The elements are lackingthe name of the courses. So for every element of the list, the course-name needsto 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 course-name. 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 courseis retrieved by invoking the database-adapter. A last assignment is needed toactually 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 idand the name of each course.


Fig. B.6: BPEL-implementation of RetrieveStudentRegistration

B.6 RetrieveStudentRegistration Operation

The operation is defined as follows:Type Name Data-typeinput StudentId integeroutput University Universityfault fault string

University is described in section B.2.This operation will return the university where the given student is regis-

tered. A fault is generated if the given student does not exist or is not registeredat 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 givenstudent. First the input for the database-adapter is assigned using an assign-activity. Then the id of the university where the student is registered, is retrievedusing the database-adapter. The third activity is also an assignment and againassigns the input of the database-adapter. The fourth activity is the invocationof the database-adapter which retrieves the name of university. Now the id andthe name of the home-university of the given student are known and in the fifthactivity assigned to the output of the RetrieveStudentRegistration-operation.


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-typeinput ExternalRegistration ExternalRegistrationLogoutput dummy string

Data-type ExternalRegistrationLog :Field Data-type DescriptionStudentId integer id of the studentUniversityId integer id of the universityCourseId integer id of the coursePaymentId integer id of the payment

This operation will log the external registration that was created by thestudent-made system.

The implementation (figure B.7) only contains the logging of the event thatan external registration was made.

B.8 LogPayment Operation

The operation is defined as follows:Type Name Data-typeinput PaymentId integeroutput dummy string


Fig. B.9: BPEL-implementation of RetrieveStudentName

This operation will log the payment that was fulfilled in the student-madesystem.

The implementation (figure B.8) only contains the logging of the event thata payment was fulfilled.

B.9 RetrieveStudentName Operation

The operation is defined as follows:Type Name Data-typeinput StudentId integeroutput StudentName stringfault fault string

This operation returns the name of the given student. A fault is generatedif the student does not exist.

The implementation (figure B.9) will now be described: first the event thatthe name of a student is retrieved, is logged by using the Student-System I/OLogger. Then the name of the student is retrieved in three steps: first theinput for the database-adapter is assigned by using an assign-activity. Thenthe database-adapter is invoked. The last step is assigning the output from thedatabase-adapter to the output of RetrieveStudentName. Then the student-name is returned.

B.10 RetrieveUniversityName Operation

The operation is defined as follows:Type Name Data-typeinput UniversityId integeroutput UniversityName stringfault fault string


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 generatedif the university does not exist.

The implementation (figure B.10) will now be described: first the eventthat 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 outputfrom the database-adapter to the output of RetrieveUniversityName. Then theuniversity-name is returned.


B.11 RetrieveCourseName Operation

The operation is defined as follows:Type Name Data-typeinput CourseId integeroutput CourseName stringfault fault string

This operation returns the name of the given course. A fault is generated ifthe course does not exist.

The implementation (figure B.11) will now be described: first the eventthat the name of a course is retrieved, is logged by using the Student-SystemI/O Logger. Then the name of the course is retrieved in three steps: first theinput for the database-adapter is assigned by using an assign-activity. Thenthe database-adapter is invoked. The last step is assigning the output from thedatabase-adapter to the output of RetrieveCourseName. Then the course-nameis returned.

C. DETAILED DESCRIPTION OF THETESTCASEGENERATION 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 exe-cuted. A loop has been constructed to fit this purpose. This loop loops as manytimes 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 beconstructed and assigned to each field of the test-case input. A loop (whichis nested in the TestCaseAmount loop) is constructed for that purpose. Thisloop loops as many times as a complex data-type has fields. In this loop wehave a case-statement which makes a distinction on the type of field. This isthe Type-field in the FieldData data-type. Depending on the data-type a valueis chosen, if the field has a simple data-type, or constructed, if the field has acomplex data-type. If the variable has type 0, this means that the test-caseinput field has data-type string and that it gets its value randomly chosen fromthe StringList field of FieldData.

If the field has type 1, this means that the test-case input field has data-typeinteger and that it gets its value randomly chosen from the IntegerList field ofFieldData.

If the field has type 2, this means that the test-case input field has data-typeinteger and that it gets its value randomly chosen from an integer domain whichis bound by a lower bound and upper bound which are defined by the FieldDatafields LowerBound and UpperBound.

If the field has type 3, this means that the test-case input field has data-typeboolean 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 complexdata-type and that a complex-typed value must be constructed. ComplexType-List contains a list with elements that contain data for the construction ofcomplex-typed values. One of these elements is randomly selected and given tothe Java function createComplexType (section 6.1.3.3). This function returns aDataObject which is assigned to the test-case input field. The implementationof createComplexType is similar to TestCaseGeneration.

If the field has type 5, this means that the test-case input field has data-typelist of string. Field StringLists contains a list of string lists. One of these string

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 theseinteger 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-typelist of boolean. Field BooleanLists contains a list of boolean lists. One of theseboolean 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 data-type a list of complex-typed elements. Field ComplexTypeLists contains a listof lists of data that can be used to generate complex-typed values. The functionselectComplexTypeList takes a randomly chosen list out of ComplexTypeLists asinput and returns a DataObject which is a list of complex-typed elements. ThisDataObject is assigned to the test-case input field. selectComplexTypeList usesthe function createComplexType to construct a complex-typed value from eachelement from the list it gets as input.

If the field has type 9, this means that the test-case input field has as data-type a list of strings. The function buildStringList takes as input parametersStringList and listSize. buildStringlist generates and returns a DataObjectwhich contains a list of string values with the list having size listSize. Thislist is assigned to the test-case input field.

If the field has type 10, this means that the test-case input field has as data-type a list of integers. The function buildIntegerList takes as input parametersthe values of the fields IntegerList and listSize. buildIntegerlist generates andreturns a DataObject which contains a list of integer values with the list havingsize 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 data-type a list of integers. Again the function buildIntegerList is used. This functionis overloaded to also take as parameters the values of the fields LowerBound,UpperBound and listSize. buildIntegerList returns a DataObject which containsa list of integer values which are in the integer domain specified by LowerBoundand UpperBound and has size listSize. This list is assigned to the test-case inputfield.

If the field has type 12, this means that the test-case input field has as data-type a list of booleans. The function buildBooleanList is used. buildBooleanListtakes as input listSize and returns a DataObject which contains a list of booleanelements 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 asdata-type a list of complex-typed values. The function buildComplexTypeList isused. buildComplexTypeList takes as input the values from the fields Complex-TypeList and listSize. It returns a DataObject which contains a list of complextyped elements with the list having size listSize. buildComplexTypeList uses thefunction 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 thestudent-made system’s input a value is constructed and assigned, this input isready to be used as test-case input. First the test-case input is logged using

C. Detailed Description of the TestCaseGeneration operation 134

the LogInput function. Then the student-made system is invoked with theconstructed test-case input. The output produced by the student-made systemis logged by using the LogOutput function.

This is done as many times as the number of test-cases required (this isspecified by the variable TestCaseAmount).

D. DETAILED DESCRIPTIONS OF SCOPES USED IN THEUNIVERSITY COMPONENT

In this chapter, detailed descriptions are given of scopes that are used in theBPEL-implementation of the University component. University is a componentthat 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 checkwhether the university offers the course. First the central register (operationRetrieveCourseOffers) is used to retrieve the courses that are offered by thisuniversity. This is done by using an invoke-activity. An assignment is usedto assign the input of this invocation which is the identifier of the university.This assignment also sets a boolean variable named CourseIsAvailable, to falsewhich will later be used in a foreach-structure to remember whether the coursewhich was in the external registration-request, is offered by the university. A listof course-offers is returned by the invocation of the central register’s Retrieve-CourseOffers-operation. Next comes a foreach-structure which loops throughthe course-offers that are in the list returned by the central register. For eachcourse-offer is executed the following activities: An assign-activity picks the cur-rent course-offer out of the list and assigns it to a temporary variable. Then ina choice-structure is checked whether the identifier of the current course-offer isequal 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 Cour-seIsAvailable. This completes the body of the foreach-structure. What remainsis a choice-structure that checks whether the course in the external registration-request was not in the course-offer-list (CourseIsAvailable is false). If this is thecase, a fault is returned and the process terminates. Otherwise the process goesto the next scope.

D.1.2 CheckStudentRegistration-scope

The CheckStudentRegistration-scope (figure D.2) checks the registrations of thestudent that requests an external registration. First the registration is retrievedby invoking the central register (operation RetrieveStudentRegistration). Theinput for this invocation is the student-identifier and assigned to the input of

D. Detailed Descriptions of Scopes used in the University Component 136

Fig. D.1: Contents of the CheckCourseAvailability-scope


Fig. D.2: Contents of the CheckStudentRegistration-scope

the invoke-activity by using an assign-activity. The output of this invocationis the identifier of the home-university of the student. The next step is anassignment which assigns the input for the invocation of the database-adapterOUSDB 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 theredoes not exist an exact same external registration and the boolean-variableExistsExternalRegistration is assigned false. Then a choice-structure checks fortwo cases. The first case checks whether the home-university of the studentthat requests an external registration, is equal to the university at which thestudents wants an external registration. If this is the case, it means the studentsrequests an external registration at his own university and the process returns afault and terminates. In the second case is checked whether the boolean-variableExistsExternalRegistration is true. If this is the case, it means that the externalregistration already exists and the process returns a fault and terminates. Ifboth 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 prior-knowledge of the student that is requesting the external-registration, is sufficientfor the course in the external registration-request. First the prior-knowledgethat is required for the course, is retrieved by invoking the central register


Fig. D.3: Contents of the CheckStudentsPriorKnowledge-scope

(operation RetrievePriorKnowledge). An assignment assigns the input for thisinvocation which is the identifier of the course. A list of courses is returnedby the central register in case there is prior-knowledge required. In case thereis no prior-knowledge required, the check is skipped and the scope ends. Aforeach-structure loops through the courses in the list returned by the centralregister. For each course in the list, an invocation of the database-adapterOUSDB is executed to see if the database contains a result of the student forthat particular course in the prior-knowledge-list that has a positive grade. Theinput for this invocation is assigned by an assign-activity. In case the databasecontains no positive result for the needed course, it means the student lacksprior-knowledge and the process returns a fault and terminates. If the foreach-structure successfully loops through all the courses, it means that the studenthas 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 pre-vious results of the students which requested the external registration and showsthese to the examinations committee which will decide whether the external reg-istration is accepted. First the results of the student are retrieved by invokingthe OUSDB. An assignment is used to assign the input for the invocation ofOUSDB. Now a variable named StudentFile with data-type StudentFile is in-stantiated in a snippet-activity (appendix A.4.2.6). StudentFile will contain allthe results obtained by the student. The data-type StudentFile is defined asfollows:

Field Data-typeStudentName stringCourseHistory list of CourseResult

Data-type CourseResult :


Fig. D.4: Contents of the ExaminationsCommitteeCheck -scope


Field Data-typeCourseName stringGrade integer

Next is a foreach-structure that loops through the list of results. For eachresult in the list retrieved by invoking OUSDB, is retrieved the name of thecourse, because the results only contain the identifier of the course. The nameof the course is retrieved by invoking the RetrieveCourseName-operation of thecentral register. The input for central register is the identifier of the course ofthe 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 resultis added to the StudentFile in a snippet-activity. This snippet contains fivestatements:

statement 1: A temporary variable (named TempCourseResult) with data-typeCourseResult, is instantiated;

statement 2: The course name that was just retrieved is assigned to TempCours-eResult ;

statement 3: The current result is retrieved from the list and assigned to atemporary variable;

statement 4: The grade in the temporary variable is assigned to the grade inTempCourseResult ;

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 whichthe student wants an external registration is retrieved. This is done by using theRetrieveCourseName-operation of the central register. Then the Examination-sCommittee component is invoked with as input the studentfile of the studentand the name of the student and the name of the course which the studentwants to follow. The ExaminationsCommittee component will return an outputwhich is an boolean that tells whether the external registration is accepted ordenied. A choice-structure with a case that is executed if the external regis-tration was denied, will return a fault and terminate the process. In case theexternal registration was accepted no cases in the choice-structure will evaluateto true and the examinations committee-check is passed.

Now all checks are passed which were necessary to accept the external reg-istration.

D.1.5 RequestPayment-scope

The next scope (figure D.5) will request a payment at the bank. RequestPaymentinvokes the RegisterPayment-operation of the Bank component. The input forthis operation is assigned in an assignment before the invocation. The outputof this invocation is an identifier of a payment which is stored with the externalregistration.


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 inthe database using the database-adapter. This is done by assigning the input forthe invocation and invoking the OUSDB component which stores the externalregistration in the database. Then the central register is invoked using theLogExternalRegistration-operation to log the event that an external registrationwas created.

Then all the scopes are executed. What remains, is assigning the outputwhich is the identifier of the payment. Then the output is returned. That com-pletes the description of the CourseRegistrationRequest-operation of the Uni-versity 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 anassignment which assigns true to a boolean-variable named ExistsExternalRegis-tration and it assigns the input for the invocation of the database-adapter. Thenthe invocation of the OUSDB is executed. It retrieves the external registration ifit exists. If it does not exist, the invocation returns a fault and false is assigned tothe boolean-variable ExistsExternalRegistration. This boolean-variable is used


Fig. D.7: Contents of the CheckRegistrationKind-scope

Fig. D.8: Contents of the CheckPayment-scope

in the choice-structure that is placed after the CheckRegisterKind -scope, to de-cide whether there exists an external registration.

D.2.2 CheckPayment-scope

The CheckPayment-scope (figure D.8) is executed if an external registrationexists. The external registration retrieved in the CheckRegisterKind -scope con-tains a boolean-variable named paymentfulfilled which is false if the payment forthe external registration has not been completed. This is checked in the choice-structure in the CheckPayment-scope. If the payment has not been completed,it means the examination can not be executed and a fault is returned and theprocess terminates.

D.2.3 CheckRegistration-scope

The CheckRegistration-scope (figure D.9) is in the branch of the choice-structurethat is executed if there is no external registration. If there is no externalregistration present, it is still possible that the student has the right to do an


Fig. D.9: Contents of the CheckRegistration-scope

examination. This is the case if the student is trying to do an examination athis home-university. First there is an assignment which assigns the input forthe invocation of the central register’s RetrieveStudentRegistration-operation.Then this invocation is executed by an invoke-activity. The central registercan return a fault if there is no registration for the student. In that case theprocess returns a fault and returns. If a registration exists the central registerreturns it. In a choice-structure is checked whether the identifier of the home-university of the student is not equal to the identifier of the university where theexamination is requested. If this is the case the examination cannot be executedand the process returns a fault and terminates. If the student has requestedan examination on his home-university, no cases in the choice-structure will beexecuted and the registration check is passed. This also ends the scope.

D.2.4 CheckStudentsPriorKnowledge-scope

The next check that is necessary is done in the CheckStudentsPriorKnowledge-scope. It checks whether the prior-knowledge of the student is sufficient to do anexamination for the course. This scope is equal to the scope with the same namethat is present in the CourseRegistrationRequest-operation of the university. Fora description in detail, see the description of the CheckStudentsPriorKnowledge-scope for the CourseRegistrationRequest-operation.


Fig. D.10: Contents of the TeacherEvaluatesDeliverable-scope

D.2.5 CheckCourseAvailability-scope

The next check that is necessary is also the last and is done in the Check-CourseAvailability-scope. It checks whether the course for which the studentrequested an examination is offered by the university at which the student re-quested the examination. This scope is equal to the scope with the same namethat is present in the CourseRegistrationRequest-operation of the university. Fora description in detail, see the description of the CheckCourseAvailability-scopefor the CourseRegistrationRequest-operation.

D.2.6 TeacherEvaluatesDeliverable-scope

In the TeacherEvaluatesDeliverable-scope (figure D.10) the Teacher componentis invoked to get a grade for the deliverable that is send in by the student. Firstis the name retrieved of the course for which an examination is requested. Thescope has three activities. First the input is assigned for the invocation of thecentral register’s RetrieveCourseName-operation. This input is the identifierof the course for which an examination is requested. Then the central registeris invoked and the course-name is retrieved. Then the Teacher component isinvoked with as input the name of the course and the deliverable. A grade willbe returned by the Teacher component. This ends the scope.

D.2.7 RegisterResult-scope

The RegisterResult-scope (figure D.11) stores the result. Again the differenceis made between requesting an examination on the home-university and havingan external registration. This is done in a choice-structure as was done before.If there exists an external registration, there are two major steps. The firststep is storing the grade in the external registration. The second step is re-questing a result-transfer. The first step is now described in more detail: thereis a choice-structure with a case that has the condition that the grade givenfor the deliverable is greater than the grade currently stored in the externalregistration or the external registration does not contain a grade yet. If this


Fig. D.11: Contents of the RegisterResult-scope

condition is true, the three activities in the choice-structure for that case areexecuted. The first activity is an assignment which assigns the input for theinvocation of the database-adapter. The second activity is a snippet which setsthe boolean-variable successful in the external registration to true which meansthat the course was successfully completed by the student. Then the database-adapter OUSDB is invoked to update the external registration in the database.The second part is also a choice-structure. This choice contains a case with acondition that is true if the grade is greater or equal to six, which means thatthe course is successfully completed. There are two activities that will be exe-cuted if the condition is true. The first is an assignment which assigns the inputnecessary to invoke the CourseResultTransfer -operation of the home-universityof the student. The second activity is the actual invocation.

If the student has requested an examination on his home-university, theresult registration is less complicated. This is the otherwise part of the choice-structure in the RegisterResult-scope. It contains three activities. The firstactivity is an assignment of the input for the invocation of the OUSDB to storethe result. The second activity is a snippet which decides whether the grade isgreater or equal to six. If that is true the successful -variable of the result is setto true. Otherwise it is set to false. The third activity invokes the OUSDB andstores the result in the database.

E. JAVA CODE OF THEGENERATOR/COLLECTOR-COMPONENT

import commonj . sdo . DataObject ;import s tudentsoa lab . i npu tou tpu t l o gg e r i n t e r f a c e . InputOutputLoggerInter face ;import com . ibm . websphere . sca . Se rv i c e ;import com . ibm . websphere . sca . ServiceManager ;import com . ibm . websphere . bo . BOFactory ;import java . u t i l . L i s t ;import java . u t i l .Random ;import java . u t i l . Date ;import java . text . SimpleDateFormat ;

public c lass GeneratorCol l ector Impl {ServiceManager serviceManager = new ServiceManager ( ) ;

BOFactory bof = (BOFactory ) serviceManager. l o c a t e S e r v i c e ( ”com/ibm/websphere/bo/BOFactory” ) ;

/∗∗∗ D e f a u l t c o n s t r u c t o r .∗/

public GeneratorCol l ector Impl ( ) {super ( ) ;

}

/∗∗∗ @param minBound∗ @param maxBound∗ @r e t u r n minBound <= Random I n t e g e r < maxBound∗/

public In t ege r Randomize ( In t ege r minBound , In t ege r maxBound) {Random generator = new Random ( ) ;

return generator . nextInt (maxBound − minBound) + minBound ;}

public void LogInput ( DataObject InputData , St r ing StudentGroupName ) {InputOutputLoggerInter face InputOutputLogger = loca teSe rv i c e InputOutputLogge r In te r f acePar tne r ( ) ;DataObject input = bof . c r ea t e ( ”http :// StudentSOALabLib” ,

”LogInputDatatype” ) ;SimpleDateFormat formatter = new SimpleDateFormat ( ”dd−MM−yyyy HH:mm: s s ” ) ;

input . s e t S t r i n g ( ”Data” , ParseDataObject ( InputData ) ) ;input . s e t S t r i n g ( ”TimeStamp” , formatter . format (new Date ( ) ) ) ;input . s e t S t r i n g ( ”StudentGroupName” , StudentGroupName ) ;

InputOutputLogger . LogInput ( input ) ;}

public void LogOutput ( St r ing OutputData ) {InputOutputLoggerInter face InputOutputLogger = loca teSe rv i c e InputOutputLogge r In te r f acePar tne r ( ) ;DataObject output = bof . c r ea t e ( ”http :// StudentSOALabLib” ,

”LogOutputDatatype” ) ;SimpleDateFormat formatter = new SimpleDateFormat ( ”dd−MM−yyyy HH:mm: s s ” ) ;

output . s e t S t r i n g ( ”Data” , OutputData ) ;output . s e t S t r i n g ( ”SourceComponent” , ” GeneratorCo l l ec tor ” ) ;output . s e t S t r i n g ( ”TimeStamp” , formatter . format (new Date ( ) ) ) ;

InputOutputLogger . LogOutput ( output ) ;}

public void LogOutput ( DataObject OutputData ) {InputOutputLoggerInter face InputOutputLogger = loca teSe rv i c e InputOutputLogge r In te r f acePar tne r ( ) ;DataObject output = bof . c r ea t e ( ”http :// StudentSOALabLib” ,

”LogOutputDatatype” ) ;SimpleDateFormat formatter = new SimpleDateFormat ( ”dd−MM−yyyy HH:mm: s s ” ) ;S t r ing OutputString ;

output . s e t S t r i n g ( ”Data” , ParseDataObject (OutputData ) ) ;output . s e t S t r i n g ( ”SourceComponent” , ” GeneratorCo l l ec tor ” ) ;output . s e t S t r i n g ( ”TimeStamp” , formatter . format (new Date ( ) ) ) ;

E. Java Code of the Generator/Collector-Component 147

InputOutputLogger . LogOutput ( output ) ;}

public Str ing ParseDataObject ( DataObject DO) {Str ing OutputString = DO. toSt r ing ( ) ;

for ( int i = 0 ; i < DO. getType ( ) . g e tPrope r t i e s ( ) . s i z e ( ) ; i++) {try {

OutputString = OutputString + ” ”+ ParseDataObject (DO. getDataObject ( i ) ) ;

} catch ( Exception e ) {}

}return OutputString ;

}

/∗∗∗ Re t u r n a r e f e r e n c e t o t h e c omponen t s e r v i c e i n s t a n c e f o r t h i s∗ i m p l e m e n t a t i o n c l a s s . T h i s me t hod s h o u l d b e u s e d when p a s s i n g t h i s∗ s e r v i c e t o a p a r t n e r r e f e r e n c e o r i f you wan t t o i n v o k e t h i s c omponen t∗ s e r v i c e a s y n c h r o n o u s l y .∗∗ @g e n e r a t e d ( com . ibm . w b i t . j a v a )∗/

@SuppressWarnings ( ”unused” )private Object getMyService ( ) {

return ( Object ) ServiceManager . INSTANCE. l o c a t e S e r v i c e ( ” s e l f ” ) ;}

/∗∗∗ Th i s me t hod i s u s e d t o l o c a t e t h e s e r v i c e f o r t h e r e f e r e n c e named∗ ” I n p u t O u t p u t L o g g e r I n t e r f a c e P a r t n e r ” . T h i s w i l l r e t u r n an i n s t a n c e o f∗ {@ l i n k I n p u t O u t p u t L o g g e r I n t e r f a c e } . I f you wo u l d l i k e t o u s e t h i s∗ s e r v i c e a s y n c h r o n o u s l y t h e n you w i l l n e e d t o c a s t t h e r e s u l t t o∗ {@ l i n k I n p u t O u t p u t L o g g e r I n t e r f a c e A s y n c } .∗∗ @g e n e r a t e d ( com . ibm . w b i t . j a v a )∗∗ @r e t u r n I n p u t O u t p u t L o g g e r I n t e r f a c e∗/

public InputOutputLoggerInter face l oca teSe rv i c e InputOutputLogge r In te r f acePar tne r ( ) {return ( InputOutputLoggerInter face ) ServiceManager . INSTANCE

. l o c a t e S e r v i c e ( ” InputOutputLoggerInter facePartner ” ) ;}

/∗∗∗ Method g e n e r a t e d t o s u p p o r t i m p l e m e n t i o n o f o p e r a t i o n ” T e s tCa s eManu a l ”∗ d e f i n e d f o r WSDL p o r t t y p e named ” G e n e r a t o r C o l l e c t o r ” .∗∗ The p r e s e n c e o f commonj . s d o . D a t a O b j e c t a s t h e r e t u r n t y p e and / o r a s a∗ p a r am e t e r t y p e c o n v e y s t h a t i t s a c omp l e x t y p e . P l e a s e r e f e r t o t h e WSDL∗ D e f i n i t i o n f o r more i n f o r m a t i o n on t h e t y p e o f i n p u t , o u t p u t and∗ f a u l t ( s ) .∗/

public void TestCaseManual ( DataObject input ) {// C r e a t e s e r v i c e o b j e c t f o r t h e s t u d e n t−made s y s t em .Se rv i c e StudentSystem = ( Se rv i c e ) ServiceManager . INSTANCE

. l o c a t e S e r v i c e ( input . g e tS t r ing ( ”StudentSystemPartner ” ) ) ;// D e c l a r e o b j e c t o u t p u t w h i c h w i l l c o n t a i n t h e o u t p u t p r o d u c e d b y t h e// s t u d e n t−made s y s t em .DataObject output ;// Loop t h r o u g h a l l t h e e l e m e n t s i n t h e l i s t o f t e s t c a s e s .for ( int i = 0 ; i < input . g e tL i s t (

”TestCases /” + input . g e tS t r ing ( ”TestCasesListName” ) ) . s i z e ( ) ; i++) {// Log t h e t e s t c a s e i n p u t r e t r i e v e d f r om t h e l i s t o f t e s t c a s e s .LogInput ( input . getDataObject ( ”TestCases /”

+ input . g e tS t r ing ( ”TestCasesListName” ) + ” . ” + i ) , input. g e tS t r ing ( ”StudentGroupName” ) ) ;

try {// I n v o k e t h e s t u d e n t−made s y s t em and s t o r e t h e o u t p u t i n a// v a r i a b l e .output = ( DataObject ) StudentSystem . invoke ( input

. g e tS t r ing ( ”OperationName” ) , input

. getDataObject ( ”TestCases /”+ input . g e tS t r ing ( ”TestCasesListName” ) + ” . ”+ i ) ) ;

// Log t h e o u t p u t p r o d u c e d b y t h e s t u d e n t−made s y s t em .LogOutput ( output . getDataObject ( input . g e tS t r ing ( ”OutputName” ) ) ) ;

} catch ( Exception e ) {// In c a s e t h e s t u d e n t−made s y s t em t h r o w s an e x c e p t i o n , l o g t h e// e x c e p t i o n m e s s a g e .LogOutput ( e . getMessage ( ) ) ;

}}

}

/∗∗∗ Method g e n e r a t e d t o s u p p o r t i m p l e m e n t i o n o f o p e r a t i o n∗ ” T e s t C a s e G e n e r a t i o n ” d e f i n e d f o r WSDL p o r t t y p e named


∗ ” G e n e r a t o r C o l l e c t o r ” .∗∗ The p r e s e n c e o f commonj . s d o . D a t a O b j e c t a s t h e r e t u r n t y p e and / o r a s a∗ p a r am e t e r t y p e c o n v e y s t h a t i t s a c omp l e x t y p e . P l e a s e r e f e r t o t h e WSDL∗ D e f i n i t i o n f o r more i n f o r m a t i o n on t h e t y p e o f i n p u t , o u t p u t and∗ f a u l t ( s ) .∗/

public void TestCaseGeneration ( DataObject input ) {Se rv i c e StudentSystemPartner = ( Se rv i c e ) ServiceManager . INSTANCE

. l o c a t e S e r v i c e ( input . g e tS t r ing ( ”StudentSystemPartner ” ) ) ;S t r ing Operation = input . g e tS t r ing ( ”OperationName” ) ;In t ege r RandomNumber ;DataObject StudentSystemInput ;DataObject StudentSystemOutput ;

for ( int i = 0 ; i < input . g e t In t ( ”TestCaseAmount” ) ; i++) {StudentSystemInput = bof . c r ea t e ( input . g e tS t r ing ( ”NamespaceType” ) ,

input . g e tS t r ing ( ”NameType” ) ) ;for ( int j = 0 ; j < input . g e tL i s t ( ”TestCaseData/ Fie ldDataLis t ” )

. s i z e ( ) ; j++) {switch ( input . g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/Type” ) ) {case 0 : // S e l e c t s t r i n g f r om ’ S t r i n g L i s t ’

RandomNumber = Randomize (0 , input . g e tL i s t (”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/ S t r i n gL i s t / S t r i n gL i s t ” ) . s i z e ( ) ) ;StudentSystemInput

. s e t S t r i n g ( input. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ”

+ j + ”/Name” ) , input. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ”

+ j + ”/ S t r i n gL i s t / S t r i n gL i s t . ”+ RandomNumber ) ) ;

break ;case 1 : // S e l e c t i n t e g e r f r om ’ I n t e g e r L i s t ’


+ ”/ In t e g e rL i s t / I n t e g e rL i s t ” ) . s i z e ( ) ) ;StudentSystemInput . s e t I n t ( input

. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/Name, ” ) , input

. g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/ In t e g e rL i s t / I n t e g e rL i s t . ”+ RandomNumber ) ) ;

break ;case 2 : // S e l e c t i n t e g e r f r om i n t e g e r domain ( ’ LowerBound ’ and

// ’ UpperBound ’ )RandomNumber = Randomize ( input

. g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/LowerBound” ) , input

. g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/UpperBound” ) ) ;

StudentSystemInput . s e t I n t ( input. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/Name” ) , RandomNumber ) ;break ;

case 3 : // S e l e c t b o o l e a nRandomNumber = Randomize (0 , 2 ) ;i f (RandomNumber == 0)

StudentSystemInput . setBoolean ( input. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/Name” ) , f a l s e ) ;else

StudentSystemInput . setBoolean ( input. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/Name” ) , true ) ;break ;

case 4 : // S e l e c t c omp l e x t y p e f r om ’ C omp l e x T y p e L i s t ’RandomNumber = Randomize (0 , input . g e tL i s t (

”TestCaseData/ Fie ldDataLis t . ” + j+ ”/ComplexTypeList/ComplexTypeList” )

. s i z e ( ) ) ;StudentSystemInput . s e t ( input

. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/Name” ) , createComplexType ( input

. getDataObject ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/ComplexTypeList/ComplexTypeList . ”+ RandomNumber ) ) ) ;

break ;case 5 : // S e l e c t s t r i n g l i s t f r om ’ S t r i n g L i s t s ’

RandomNumber = Randomize (0 , input . g e tL i s t (”TestCaseData/ Fie ldDataLis t . ” + j + ”/ S t r i n gL i s t s ” ). s i z e ( ) ) ;

StudentSystemInput . s e t ( input. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/Name” ) , input. get ( ”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/ S t r i n gL i s t s . ” + RandomNumber+ ”/ S t r i n gL i s t ” ) ) ;

break ;case 6 : // S e l e c t i n t e g e r l i s t f r om ’ I n t e g e r L i s t s ’


RandomNumber = Randomize (0 , input. g e tL i s t (

”TestCaseData/ Fie ldDataLis t . ” + j+ ”/ I n t e g e rL i s t s ” ) . s i z e ( ) ) ;



+ ”/ I n t e g e rL i s t s . ” + RandomNumber+ ”/ In t e g e rL i s t ” ) ) ;

break ;case 7 : // S e l e c t b o o l e a n l i s t f r om ’ B o o l e a n L i s t s ’

RandomNumber = Randomize (0 , input. g e tL i s t (

”TestCaseData/ Fie ldDataLis t . ” + j+ ”/ Boo leanLis t s ” ) . s i z e ( ) ) ;



+ ”/ Boo leanLis t s . ” + RandomNumber+ ”/BooleanList ” ) ) ;

break ;case 8 : // S e l e c t c o m p l e x t y p e l i s t f r om ’ C o m p l e x T y p e L i s t s ’


+ ”/ComplexTypeLists” ) . s i z e ( ) ) ;StudentSystemInput . s e t ( input

. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/Name” ) , se lectComplexTypeList ( input

. getDataObject ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/ComplexTypeLists . ” + RandomNumber+ ”/ComplexTypeList” ) ) ) ;

break ;case 9 : // b u i l d s t r i n g l i s t ( w i t h s i z e ’ L i s t S i z e ’ ) f r om

// ’ S t r i n g L i s t ’StudentSystemInput . s e t ( input

. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/Name” ) , bu i l dS t r i n gL i s t (

input . getDataObject ( ”TestCaseData/ Fie ldDataLis t . ”+ j + ”/ S t r i n gL i s t ” ) ,

input . g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/ L i s t S i z e ” ) ) . get ( ” S t r i n gL i s t ” ) ) ;

break ;case 10 : // b u i l d i n t e g e r l i s t ( w i t h s i z e ’ L i s t S i z e ’ ) f r om

// ’ I n t e g e r L i s t ’StudentSystemInput . s e t ( input

. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/Name” ) , bu i l d I n t e g e rL i s t (

input . getDataObject ( ”TestCaseData/ Fie ldDataLis t . ”+ j + ”/ In t e g e rL i s t ” ) ,

input . g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/ L i s t S i z e ” ) ) . get ( ” I n t e g e rL i s t ” ) ) ;

break ;case 11 : // b u i l d i n t e g e r l i s t ( w i t h s i z e ’ L i s t S i z e ’ ) f r om i n t e g e r

// domain// ( ’ LowerBound ’ and ’ UpperBound ’ )StudentSystemInput . s e t ( input

. g e tS t r ing ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/Name” ) , bu i l d I n t e g e rL i s t (

input . g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/LowerBound” ) ,

input . g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/UpperBound” ) ,

input . g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j+ ”/ L i s t S i z e ” ) ) . get ( ” I n t e g e rL i s t ” ) ) ;

break ;case 12 : // b u i l d b o o l e a n l i s t ( w i t h s i z e ’ L i s t S i z e ’ )


+ ”/Name” ) , bu i ldBoo leanLi s t (input . g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/ L i s t S i z e ” ) ) . get ( ”BooleanList ” ) ) ;break ;

case 13 : // b u i l d c o m p l e x t y p e l i s t ( w i t h s i z e ’ L i s t S i z e ’ ) f r om// ’ C omp l e x T y p e L i s t ’


+ ”/Name” ) , buildComplexTypeList ( input. getDataObject ( ”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/ComplexTypeList/ComplexTypeList” ) ,input . g e t In t ( ”TestCaseData/ Fie ldDataLis t . ” + j

+ ”/ L i s t S i z e ” ) ) ) ;break ;

default :System . out . p r i n t l n ( ” Inva l i d Type” ) ;break ;

}}

LogInput ( StudentSystemInput , input . g e tS t r ing ( ”StudentGroupName” ) ) ;


try {StudentSystemOutput = ( DataObject ) StudentSystemPartner . invoke (

Operation , StudentSystemInput ) ;LogOutput ( StudentSystemOutput . getDataObject ( input

. g e tS t r ing ( ”OutputName” ) ) ) ;} catch ( Exception e ) {

LogOutput ( e . getMessage ( ) ) ;}

}}

public DataObject selectComplexTypeList ( DataObject ComplexTypeList ) {DataObject r e s u l t = bof . c r ea t e ( ComplexTypeList . getDataObject (0)

. g e tS t r ing ( ”NamespaceComplexType” ) , ComplexTypeList

. getDataObject ( 0 ) . g e tS t r ing ( ”NameComplexType” ) ) ;

for ( int i = 0 ; i < ( ( L i s t ) ComplexTypeList ) . s i z e ( ) ; i++) {r e s u l t . s e t ( i , createComplexType ( ComplexTypeList . getDataObject ( i ) ) ) ;

}

return r e s u l t ;}

public DataObject bu i l dS t r i n gL i s t ( DataObject S t r ingL i s t , int L i s t S i z e ) {DataObject r e s u l t = bof . c r ea t e ( ”http :// StudentSOALab” , ” S t r i n gL i s t ” ) ;In t ege r RandomNumber ;

for ( int i = 0 ; i < L i s t S i z e ; i++) {RandomNumber = Randomize (0 , S t r i n gL i s t . g e tL i s t ( ” S t r i n gL i s t ” ) . s i z e ( ) ) ;r e s u l t . g e tL i s t ( ” S t r i n gL i s t ” ) . add (

S t r i n gL i s t . g e tS t r ing ( ” S t r i n gL i s t . ” + RandomNumber ) ) ;}


public DataObject bu i l d I n t e g e rL i s t ( DataObject In t ege rL i s t , int L i s t S i z e ) {DataObject r e s u l t = bof . c r ea t e ( ”http :// StudentSOALab” , ” I n t e g e rL i s t ” ) ;In t ege r RandomNumber ;

for ( int i = 0 ; i < L i s t S i z e ; i++) {RandomNumber = Randomize (0 , I n t e g e rL i s t . g e tL i s t ( ” I n t e g e rL i s t ” )

. s i z e ( ) ) ;r e s u l t . g e tL i s t ( ” I n t e g e rL i s t ” ) . add (

new In t ege r ( I n t e g e rL i s t . g e t In t ( ” I n t e g e rL i s t . ”+ RandomNumber ) ) ) ;

}


public DataObject bu i l d I n t e g e rL i s t ( int LowerBound , int UpperBound ,int L i s t S i z e ) {

DataObject r e s u l t = bof . c r ea t e ( ”http :// StudentSOALab” , ” I n t e g e rL i s t ” ) ;In t ege r RandomNumber ;

for ( int i = 0 ; i < L i s t S i z e ; i++) {RandomNumber = Randomize (LowerBound , UpperBound ) ;r e s u l t . g e tL i s t ( ” I n t e g e rL i s t ” ) . add (RandomNumber ) ;

}


public DataObject bu i ldBoo leanLi s t ( int L i s t S i z e ) {DataObject r e s u l t = bof . c r ea t e ( ”http :// StudentSOALab” , ”BooleanList ” ) ;In t ege r RandomNumber ;

for ( int i = 0 ; i < L i s t S i z e ; i++) {RandomNumber = Randomize (0 , 2 ) ;i f (RandomNumber == 0)

r e s u l t . g e tL i s t ( ”BooleanList ” ) . add (new Boolean ( f a l s e ) ) ;else

r e s u l t . g e tL i s t ( ”BooleanList ” ) . add (new Boolean ( true ) ) ;}


public DataObject buildComplexTypeList ( DataObject ComplexTypeList ,int L i s t S i z e ) {

DataObject r e s u l t = bof . c r ea t e ( ComplexTypeList . getDataObject (0). g e tS t r ing ( ”NamespaceComplexType” ) , ComplexTypeList. getDataObject ( 0 ) . g e tS t r ing ( ”NameComplexType” ) ) ;

In t ege r RandomNumber ;

for ( int i = 0 ; i < L i s t S i z e ; i++) {RandomNumber = Randomize (0 , ( ( L i s t ) ComplexTypeList ) . s i z e ( ) ) ;r e s u l t . s e t ( i , createComplexType ( ComplexTypeList

. getDataObject (RandomNumber ) ) ) ;}



public DataObject createComplexType ( DataObject ComplexType ) {DataObject r e s u l t = bof . c r ea t e (ComplexType

. g e tS t r ing ( ”NamespaceComplexType” ) , ComplexType

. g e tS t r ing ( ”NameComplexType” ) ) ;In t ege r RandomNumber ;

for ( int i = 0 ; i < ComplexType . g e tL i s t ( ” F i e l dL i s t ” ) . s i z e ( ) ; i++) {switch (ComplexType . ge t In t ( ” F i e l dL i s t . ” + i + ”/Type” ) ) {case 0 : // S e l e c t s t r i n g f r om ’ S t r i n g L i s t ’

RandomNumber = Randomize (0 , ComplexType . g e tL i s t (” F i e l dL i s t . ” + i + ”/ S t r i n gL i s t / S t r i n gL i s t ” ) . s i z e ( ) ) ;

r e s u l t . s e t S t r i n g (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i+ ”/Name” ) , ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i+ ”/ S t r i n gL i s t / S t r i n gL i s t . ” + RandomNumber ) ) ;

break ;case 1 : // S e l e c t i n t e g e r f r om ’ I n t e g e r L i s t ’

RandomNumber = Randomize (0 , ComplexType . g e tL i s t (” F i e l dL i s t . ” + i + ”/ In t e g e rL i s t / I n t e g e rL i s t ” ) . s i z e ( ) ) ;

r e s u l t . s e t I n t (ComplexType. g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name, ” ) , ComplexType. ge t In t ( ” f i e l d L i s t . ” + i + ”/ In t e g e rL i s t / I n t e g e rL i s t . ”

+ RandomNumber ) ) ;break ;

case 2 : // S e l e c t i n t e g e r f r om i n t e g e r domain ( ’ LowerBound ’ and// ’ UpperBound ’ )

RandomNumber = Randomize (ComplexType . ge t In t ( ” F i e l dL i s t . ” + i+ ”/LowerBound” ) , ComplexType . ge t In t ( ” F i e l dL i s t . ” + i+ ”/UpperBound” ) ) ;

r e s u l t . s e t I n t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,RandomNumber ) ;

break ;case 3 : // S e l e c t b o o l e a n

RandomNumber = Randomize (0 , 2 ) ;i f (RandomNumber == 0)

r e s u l t . setBoolean (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i+ ”/Name” ) , f a l s e ) ;

elser e s u l t . setBoolean (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i

+ ”/Name” ) , true ) ;break ;

case 4 : // S e l e c t c omp l e x t y p e f r om ’ C omp l e x T y p e L i s t ’RandomNumber = Randomize (0 , ComplexType . g e tL i s t (

” F i e l dL i s t . ” + i + ”/ComplexTypeList/ComplexTypeList” ). s i z e ( ) ) ;

r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,createComplexType (ComplexType

. getDataObject ( ” F i e l dL i s t . ” + i+ ”/ComplexTypeList/ComplexTypeList . ”+ RandomNumber ) ) ) ;

break ;case 5 : // S e l e c t s t r i n g l i s t f r om ’ S t r i n g L i s t s ’

RandomNumber = Randomize (0 , ComplexType . g e tL i s t (” F i e l dL i s t . ” + i + ”/ S t r i n gL i s t s ” ) . s i z e ( ) ) ;

r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,ComplexType . get ( ” F i e l dL i s t . ” + i + ”/ S t r i n gL i s t s . ”

+ RandomNumber + ”/ S t r i n gL i s t ” ) ) ;break ;

case 6 : // S e l e c t i n t e g e r l i s t f r om ’ I n t e g e r L i s t s ’RandomNumber = Randomize (0 , ComplexType . g e tL i s t (

” F i e l dL i s t . ” + i + ”/ I n t e g e rL i s t s ” ) . s i z e ( ) ) ;r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,

ComplexType . get ( ” F i e l dL i s t . ” + i + ”/ I n t e g e rL i s t s . ”+ RandomNumber + ”/ In t e g e rL i s t ” ) ) ;

break ;case 7 : // S e l e c t b o o l e a n l i s t f r om ’ B o o l e a n L i s t s ’

RandomNumber = Randomize (0 , ComplexType . g e tL i s t (” F i e l dL i s t . ” + i + ”/Boo leanLis t s ” ) . s i z e ( ) ) ;

r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,ComplexType . get ( ” F i e l dL i s t . ” + i + ”/Boo leanLis t s . ”

+ RandomNumber + ”/BooleanList ” ) ) ;break ;

case 8 : // S e l e c t c o m p l e x t y p e l i s t f r om ’ C o m p l e x T y p e L i s t s ’RandomNumber = Randomize (0 , ComplexType . g e tL i s t (

” F i e l dL i s t . ” + i + ”/ComplexTypeLists” ) . s i z e ( ) ) ;r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,

se lectComplexTypeList (ComplexType. getDataObject ( ” F i e l dL i s t . ” + i

+ ”/ComplexTypeLists . ” + RandomNumber+ ”/ComplexTypeList” ) ) ) ;

break ;case 9 : // b u i l d s t r i n g l i s t ( w i t h s i z e ’ L i s t S i z e ’ ) f r om ’ S t r i n g L i s t ’

r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,bu i l dS t r i n gL i s t (

ComplexType . getDataObject ( ” F i e l dL i s t . ” + i+ ”/ S t r i n gL i s t ” ) ,

ComplexType . ge t In t ( ” F i e l dL i s t . ” + i


+ ”/ L i s t S i z e ” ) ) . get ( ” S t r i n gL i s t ” ) ) ;break ;

case 10 : // b u i l d i n t e g e r l i s t ( w i t h s i z e ’ L i s t S i z e ’ ) f r om// ’ I n t e g e r L i s t ’

r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,bu i l d I n t e g e rL i s t (

ComplexType . getDataObject ( ” F i e l dL i s t . ” + i+ ”/ In t e g e rL i s t ” ) ,

ComplexType . ge t In t ( ” F i e l dL i s t . ” + i+ ”/ L i s t S i z e ” ) ) . get ( ” I n t e g e rL i s t ” ) ) ;

break ;case 11 : // b u i l d i n t e g e r l i s t ( w i t h s i z e ’ L i s t S i z e ’ ) f r om i n t e g e r

// domain ( ’ LowerBound ’ and ’ UpperBound ’ )r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,

bu i l d I n t e g e rL i s t (ComplexType . ge t In t ( ” F i e l dL i s t . ” + i

+ ”/LowerBound” ) ,ComplexType . ge t In t ( ” F i e l dL i s t . ” + i

+ ”/UpperBound” ) ,ComplexType . ge t In t ( ” F i e l dL i s t . ” + i

+ ”/ L i s t S i z e ” ) ) . get ( ” I n t e g e rL i s t ” ) ) ;break ;

case 12 : // b u i l d b o o l e a n l i s t ( w i t h s i z e ’ L i s t S i z e ’ )r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,

bu i ldBoo leanLi s t (ComplexType . ge t In t ( ” F i e l dL i s t . ” + i

+ ”/ L i s t S i z e ” ) ) . get ( ”BooleanList ” ) ) ;break ;

case 13 : // b u i l d c o m p l e x t y p e l i s t ( w i t h s i z e ’ L i s t S i z e ’ ) f r om// ’ C omp l e x T y p e L i s t ’

r e s u l t . s e t (ComplexType . g e tS t r ing ( ” F i e l dL i s t . ” + i + ”/Name” ) ,buildComplexTypeList (ComplexType

. getDataObject ( ” F i e l dL i s t . ” + i+ ”/ComplexTypeList/ComplexTypeList” ) ,

ComplexType . ge t In t ( ” F i e l dL i s t . ” + i+ ”/ L i s t S i z e ” ) ) ) ;

break ;default :

System . out . p r i n t l n ( ” Inva l i d Type” ) ;break ;

}}


}

F. JAVA CODE OF THEEXECUTIONTRACELOGGER-COMPONENT

import com . ibm . websphere . sca . ServiceManager ;import javax . naming . I n i t i a lCon t ex t ;import com . ibm . events . a c c e s s . EventAccess ;import com . ibm . events . a c c e s s . EventAccessHome ;import javax . rmi . PortableRemoteObject ;import org . e c l i p s e . hyades . l ogg ing . events . cbe . CommonBaseEvent ;import java . u t i l . ArrayList ;import org . jdom . Document ;import org . jdom . input . SAXBuilder ;import org . jdom . xpath . XPath ;import org . jdom . Text ;import org . jdom . Element ;import org . jdom . output . XMLOutputter ;import java . i o . Str ingReader ;import java . s q l . DriverManager ;import java . s q l . Resul tSet ;import java . s q l . Statement ;import java . s q l . Connection ;

public c lass ExecutionTraceLoggerImpl {/∗∗∗ D e f a u l t c o n s t r u c t o r .∗/

public ExecutionTraceLoggerImpl ( ) {super ( ) ;

}




/∗∗∗ Method g e n e r a t e d t o s u p p o r t i m p l e m e n t i o n o f o p e r a t i o n∗ ” C l e a r CE ID a t a s o u r c e ” d e f i n e d f o r WSDL p o r t t y p e named∗ ” E x e c u t i o n T r a c e L o g g e r I n t e r f a c e ” .∗∗ P l e a s e r e f e r t o t h e WSDL D e f i n i t i o n f o r more i n f o r m a t i o n on t h e t y p e o f∗ i n p u t , o u t p u t and f a u l t ( s ) .∗/

public In t ege r ClearCEIDatasource ( St r ing input ) {try {

I n i t i a lCon t ex t context = new I n i t i a lCon t ex t ( ) ;Object eventAccessHomeObj = context

. lookup ( ” e jb /com/ibm/ events / acce s s /EventAccess ” ) ;EventAccessHome eventAccessHome = (EventAccessHome ) PortableRemoteObject

. narrow ( eventAccessHomeObj , EventAccessHome . c lass ) ;EventAccess eventAccess = eventAccessHome . c r ea t e ( ) ;i f ( eventAccess . eventEx i s t s ( ”Al l events ” , null ) ) {

eventAccess . purgeEvents ( ”Al l events ” , null ,EventAccess .DEFAULT PURGE TRANSACTION SIZE) ;

}context . c l o s e ( ) ;

} catch ( Exception e ) {e . pr intStackTrace ( ) ;

}return 0 ;

}

/∗∗∗ Method g e n e r a t e d t o s u p p o r t i m p l e m e n t i o n o f o p e r a t i o n ” R e t r i e v e E v e n t s ”∗ d e f i n e d f o r WSDL p o r t t y p e named ” E x e c u t i o n T r a c e L o g g e r I n t e r f a c e ” .∗

F. Java Code of the ExecutionTraceLogger-Component 154

∗ P l e a s e r e f e r t o t h e WSDL D e f i n i t i o n f o r more i n f o r m a t i o n on t h e t y p e o f∗ i n p u t , o u t p u t and f a u l t ( s ) .∗/

public In t ege r Retr ieveEvents ( St r ing UID) {try {

I n i t i a lCon t ex t context = new I n i t i a lCon t ex t ( ) ;Object eventAccessHomeObj = context

. lookup ( ” e jb /com/ibm/ events / acce s s /EventAccess ” ) ;EventAccessHome eventAccessHome = (EventAccessHome ) PortableRemoteObject

. narrow ( eventAccessHomeObj , EventAccessHome . c lass ) ;EventAccess eventAccess = eventAccessHome . c r ea t e ( ) ;

i f ( eventAccess . eventEx i s t s ( ”Al l events ” , null ) ) {ArrayList<Process> proc e s s e s = new ArrayList<Process >(0);SAXBuilder bu i l d e r = new SAXBuilder ( ) ;XMLOutputter outputter = new XMLOutputter ( ) ;Document doc ;

St r ing currentProcessName ;St r ing cur r en t In s tance Id ;Process proce s s ;Ins tance in s tance = new Ins tance ( ”Error ” ) ;BPELEvent bpelEvent ;SCAEvent scaEvent ;boolean proce s sPresent ;boolean i n s tancePre sent ;S t r ing eventNature ;

XPath processNameXPression = XPath. newInstance ( ”/wbi : event /wbi : eventPointData /bpc : processTemplateName/ text ( ) ” ) ;

XPath instance IdXPress ion1 = XPath. newInstance ( ”/wbi : event /wbi : eventHeaderData/wbi : ECSParentID/ text ( ) ” ) ;

XPath instance IdXPress ion2 = XPath. newInstance ( ”/wbi : event /wbi : eventHeaderData/wbi : ECSCurrentID/ text ( ) ” ) ;

XPath act iv i tyKindXPress ion = XPath. newInstance ( ”/wbi : event /wbi : eventPointData /bpc : ac t iv i tyKind / text ( ) ” ) ;

XPath activityNameXPression = XPath. newInstance ( ”/wbi : event /wbi : eventPointData /bpc : activityTemplateName/ text ( ) ” ) ;

XPath appl icat ionDataXPress ion = XPath. newInstance ( ”/wbi : event /wbi : app l i cat ionData /wbi : content /wbi : value ” ) ;

XPath operat ionXPress ion = XPath. newInstance ( ”/wbi : event /wbi : eventPointData /bpc : operat ion / text ( ) ” ) ;

XPath fa i lu reMessageXPress ion = XPath. newInstance ( ”/wbi : event /wbi : eventPointData /bpc : a c t i v i t yFa i l edExcep t i on / text ( ) ” ) ;

XPath sourceComponentXPression = XPath. newInstance ( ”/wbi : event /wbi : eventPointData / sca :SOURCE COMPONENT/ text ( ) ” ) ;

XPath sour ce In t e r f a c eXPre s s i on = XPath. newInstance ( ”/wbi : event /wbi : eventPointData / sca :SOURCE INTERFACE/ text ( ) ” ) ;

XPath sourceOperat ionXPress ion = XPath. newInstance ( ”/wbi : event /wbi : eventPointData / sca :SOURCE METHOD/ text ( ) ” ) ;

XPath sourceModuleXPression = XPath. newInstance ( ”/wbi : event /wbi : eventPointData / sca :SOURCE MODULE/ text ( ) ” ) ;

XPath targetComponentXPression = XPath. newInstance ( ”/wbi : event /wbi : eventPointData / sca :TARGET COMPONENT/ text ( ) ” ) ;

XPath ta rg e t In t e r f a c eXPre s s i on = XPath. newInstance ( ”/wbi : event /wbi : eventPointData / sca :TARGET INTERFACE/ text ( ) ” ) ;

XPath targetOperat ionXPress ion = XPath. newInstance ( ”/wbi : event /wbi : eventPointData / sca :TARGET METHOD/ text ( ) ” ) ;

XPath targetModuleXPression = XPath. newInstance ( ”/wbi : event /wbi : eventPointData / sca :TARGET MODULE/ text ( ) ” ) ;

XPath eventNatureXPression = XPath. newInstance ( ”/wbi : event /wbi : eventPointData /wbi : eventNature / text ( ) ” ) ;

CommonBaseEvent [ ] eventL i s t = eventAccess. queryEventsByEventGroup ( ”Al l events ” , null , true , 500 ) ;

for ( int i = 0 ; i < eventL i s t . l ength ; i++) {// S y s t em . o u t . p r i n t l n ( i + ” ” +// e v e n t L i s t [ i ] . g e t E x t e n s i o nN am e ( ) ) ;

doc = bu i l d e r . bu i ld (new Str ingReader ( ( St r ing ) eventL i s t [ i ]. getAny ( ) . get ( 0 ) ) ) ;

eventNature = (( Text ) eventNatureXPression. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

i f ( eventL i s t [ i ] . getExtensionName ( ) . equa l s IgnoreCase (”WBI.SCA. MethodInvocation .ENTRY” ) )

currentProcessName = (( Text ) sourceComponentXPression. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

else i f ( ( eventL i s t [ i ] . getExtensionName ( ) . equa l s IgnoreCase (”WBI.SCA. MethodInvocation .EXIT” ) ) | |( eventL i s t [ i ] . getExtensionName ( ) . equa l s IgnoreCase (”WBI.SCA. MethodInvocation .FAILURE” ) ) )

currentProcessName = (( Text ) targetComponentXPression. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

elsecurrentProcessName = (( Text ) processNameXPression

. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

i f ( ( eventL i s t [ i ] . getExtensionName ( ). equa l s IgnoreCase ( ”WBI.SCA. MethodInvocation .EXIT” ) )| | ( eventL i s t [ i ] . getExtensionName ( )


. equa l s IgnoreCase ( ”BPC.BFM.PROCESS.START” ) )| | ( ( eventL i s t [ i ] . getExtensionName ( )

. equa l s IgnoreCase ( ”BPC.BFM.PROCESS.STATUS” ) ) && eventNature

. equa l s IgnoreCase ( ”EXIT” ) ) )cu r r en t In s tance Id = (( Text ) instance IdXPress ion2

. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;else

cur r en t In s tance Id = (( Text ) instance IdXPress ion1. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

/∗∗ go t h r o u g h a l l t h e p r o c e s s e s . i f t h e p r o c e s s i s p r e s e n t ,∗ b l a b l a∗/

proce s sPre sent = f a l s e ;for ( int j = 0 ; j < proc e s s e s . s i z e ( ) ; j++) {

i f ( p ro c e s s e s . get ( j ) . name. equa l s IgnoreCase ( currentProcessName ) ) {

/∗∗ p r o c e s s e x i s t i n g , i n s t a n c e e x i s t a n c e unknown∗/

proce s sPresent = true ;p roce s s = proc e s s e s . get ( j ) ;

i n s tancePre sent = f a l s e ;for ( int k = 0 ; k < proc e s s e s . get ( j ) . i n s t anc e s

. s i z e ( ) ; k++) {i f ( p ro c e s s e s . get ( j ) . i n s t anc e s . get (k ) . name

. equa l s IgnoreCase ( cu r r en t In s tance Id ) ) {/∗∗ p r o c e s s and i n s t a n c e e x i s t i n g∗/

i n s tancePre sent = true ;i n s tance = proc e s s e s . get ( j ) . i n s t anc e s

. get (k ) ;break ;

}}i f ( ! i n s tancePre sent ) {

/∗∗ p r o c e s s e x i s t i n g , i n s t a n c e n o t e x i s t i n g∗/

i n s tance = new Ins tance ( cu r r en t In s tance Id ) ;p r o c e s s e s . get ( j ) . i n s t anc e s . add ( in s tance ) ;

}break ;

}}i f ( ! p roce s sPre sent ) {

/∗∗ p r o c e s s and i n s t a n c e n o t e x i s t i n g∗/

proce s s = new Process ( currentProcessName ) ;p ro c e s s e s . add ( proce s s ) ;i n s tance = new Ins tance ( cu r r en t In s tance Id ) ;p roce s s . addInstance ( in s tance ) ;

}/∗∗ p r o c e s s and i n s t a n c e o b j e c t s a r e e x i s t i n g∗/

i f ( eventL i s t [ i ] . getExtensionName ( ) . conta ins ( ”BPC.BFM” )) {bpelEvent = new BPELEvent( eventL i s t [ i ]

. g e tGloba l Ins tance Id ( ) ) ;bpelEvent . extensionName = eventL i s t [ i ]

. getExtensionName ( ) ;bpelEvent . creationTime = eventL i s t [ i ] . getCreationTime ( ) ;bpelEvent . sequenceNumber = eventL i s t [ i ]

. getSequenceNumber ( ) ;

try {bpelEvent . ac t iv i tyKind = (( Text ) act iv i tyKindXPress ion

. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;} catch ( Exception e ) {

/∗Sy s t em . o u t . p r i n t ( e v e n t L i s t [ i ] . g e t E x t e n s i o nN am e ( )

+ ” : ” ) ;S y s t em . o u t

. p r i n t l n ( ” b p e l E v e n t : a c t i v i t y K i n d n o t a v a i l a b l e ” ) ;∗/

}try {

bpelEvent . activityName = (( Text ) activityNameXPression. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

} catch ( Exception e ) {/∗Sy s t em . o u t . p r i n t ( e v e n t L i s t [ i ] . g e t E x t e n s i o nN am e ( )

+ ” : ” ) ;S y s t em . o u t

. p r i n t l n ( ” b p e l E v e n t : a c t i v i t y N a m e n o t a v a i l a b l e ” ) ;∗/


}try {

bpelEvent . app l i cat ionData = (( Text ) appl icat ionDataXPress ion. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;


+ ” : ” ) ;S y s t em . o u t

. p r i n t l n ( ” b p e l E v e n t : a p p l i c a t i o n D a t a n o t a v a i l a b l e ” ) ;∗/

}try {

bpelEvent . operat ion = (( Text ) operat ionXPress ion. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;


+ ” : ” ) ;S y s t em . o u t

. p r i n t l n ( ” b p e l E v e n t : o p e r a t i o n n o t a v a i l a b l e ” ) ;∗/

}try {

bpelEvent . f a i l u r eMes sage = (( Text ) fa i lu reMessageXPress ion. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;


+ ” : ” ) ;S y s t em . o u t

. p r i n t l n ( ” b p e l E v e n t : f a i l u r e M e s s a g e s n o t a v a i l a b l e ” ) ;∗/

}

i n s tance . addBPELEvent ( bpelEvent ) ;} else i f ( eventL i s t [ i ] . getExtensionName ( ) . conta ins (

”WBI.SCA” ) ) {scaEvent = new SCAEvent( eventL i s t [ i ]

. g e tGloba l Ins tance Id ( ) ) ;scaEvent . extensionName = eventL i s t [ i ]

. getExtensionName ( ) ;scaEvent . creationTime = eventL i s t [ i ] . getCreationTime ( ) ;scaEvent . sequenceNumber = eventL i s t [ i ]

. getSequenceNumber ( ) ;

scaEvent . sourceComponent = (( Text ) sourceComponentXPression. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

scaEvent . s ou r c e I n t e r f a c e = (( Text ) sou r c e In t e r f a c eXPre s s i on. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

scaEvent . sourceOperat ion = (( Text ) sourceOperat ionXPress ion. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

scaEvent . sourceModule = ( ( Text ) sourceModuleXPression. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

scaEvent . targetComponent = (( Text ) targetComponentXPression. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

scaEvent . t a r g e t I n t e r f a c e = (( Text ) t a r g e t In t e r f a c eXPre s s i on. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

scaEvent . targetOperat ion = (( Text ) targetOperat ionXPress ion. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

scaEvent . targetModule = ( ( Text ) targetModuleXPression. s e l e c tS ing l eNode ( doc ) ) . getText ( ) ;

try {scaEvent . app l i cat ionData = outputter . outputStr ing ( ( ( Element ) appl icat ionDataXPress ion

. s e l e c tS ing l eNode ( doc ) ) ) ;} catch ( Exception e ) {

/∗Sy s t em . o u t . p r i n t ( e v e n t L i s t [ i ] . g e t E x t e n s i o nN am e ( )

+ ” : ” ) ;S y s t em . o u t

. p r i n t l n ( ” s c a E v e n t : a p p l i c a t i o n D a t a n o t a v a i l a b l e ” ) ;∗/

}

i n s tance . addSCAEvent ( scaEvent ) ;}

}

/∗∗ S a v i n g e v e n t s t o d a t a b a s e∗/

try {Class

. forName ( ”com . mic ro so f t . s q l s e r v e r . jdbc . SQLServerDriver ” ) ;Connection con = DriverManager . getConnection (

” jdbc : s q l s e r v e r :// pcwin743 . campus . tue . n l : ”+ ” 1433; databaseName=StudentSOALabDB” ,

”Peter ” , ”nimda” ) ;Statement stmt = con . createStatement ( ) ;Resul tSet r e s u l t ;


int l a s tGeneratedProces s Id = 0 ;int l a s tGenerated Ins tance Id = 0 ;

for ( int i = 0 ; i < proc e s s e s . s i z e ( ) ; i++) {// S y s t em . o u t . p r i n t l n ( p r o c e s s e s . g e t ( i ) . name ) ;

// i n s e r t p r o c e s s d a t a i n t o d a t a b a s estmt

. executeUpdate ( ”INSERT INTO Process (Name, InputId ) VALUES ( ’ ”+ proc e s s e s . get ( i ) . name+ ” ’ , ’ ”+ UID+ ” ’ ) ; ” ) ;

// r e t r i e v e g e n e r a t e d i d f o r j u s t i n s e r t e d p r o c e s s d a t ar e s u l t = stmt

. executeQuery ( ”SELECT iden t cu r r en t ( ’ Process ’ ) AS id ; ” ) ;while ( r e s u l t . next ( ) )

la s tGeneratedProces s Id = r e s u l t . g e t In t ( ” id ” ) ;

for ( int j = 0 ; j < proc e s s e s . get ( i ) . i n s t anc e s . s i z e ( ) ; j++) {// S y s t em . o u t . p r i n t l n (”\ t ” +// p r o c e s s e s . g e t ( i ) . i n s t a n c e s . g e t ( j ) . name ) ;

// i n s e r t i n s t a n c e d a t a i n t o d a t a b a s estmt . executeUpdate ( ”INSERT INTO Instance (Name, Process Id ) VALUES ( ’ ”

+ proc e s s e s . get ( i ) . i n s t anc e s . get ( j ) . name+ ” ’ , ’ ”+ las tGeneratedProces s Id+ ” ’ ) ; ” ) ;

// r e t r i e v e g e n e r a t e d i d f o r j u s t i n s e r t e d i n s t a n c e// d a t ar e s u l t = stmt

. executeQuery ( ”SELECT iden t cu r r en t ( ’ Ins tance ’ ) AS id ; ” ) ;while ( r e s u l t . next ( ) )

l a s tGenerated Ins tance Id = r e s u l t . g e t In t ( ” id ” ) ;

for ( int k = 0 ; k < proc e s s e s . get ( i ) . i n s t anc e s. get ( j ) . BPELEvents . s i z e ( ) ; k++) {

// i n s e r t BPELEvent d a t a i n t o d a t a b a s estmt . executeUpdate ( ”INSERT INTO BPELEvent ( Global InstanceId , ” +

”ExtensionName , ”+ ”SequenceNumber , CreationTime , Ins tance Id ) ”+ ”VALUES ( ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s

. get ( j ) . BPELEvents

. get (k ) . g l oba l In s t anc e Id+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . extensionName+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . sequenceNumber+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . creationTime+ ” ’ , ’ ”+ las tGenerated Ins tance Id+ ” ’ ) ; ” ) ;

}for ( int k = 0 ; k < proc e s s e s . get ( i ) . i n s t anc e s

. get ( j ) . SCAEvents . s i z e ( ) ; k++) {// S y s t em . o u t . p r i n t l n (”\ t \ t ” +// p r o c e s s e s . g e t ( i ) . i n s t a n c e s . g e t ( j ) . SCAEven t s . g e t ( k ) . e x t e n s i o nN ame ) ;

// i n s e r t SCAEvent d a t a i n t o d a t a b a s estmt . executeUpdate ( ”INSERT INTO SCAEvent ( Global InstanceId , ” +

”ExtensionName , ”+ ”SequenceNumber , CreationTime , SourceComponent , ”+ ” Source Inte r f ace , SourceOperation , SourceModule , ” +

”TargetComponent , ”+ ” Target Inte r face , TargetOperation , TargetModule , ”+ ”ApplicationData , Ins tance Id ) VALUES ( ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s

. get ( j ) . SCAEvents

. get (k ) . g l oba l In s t anc e Id+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . extensionName+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . sequenceNumber+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s



. get (k ) . creationTime+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . sourceComponent+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . s ou r c e I n t e r f a c e+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . sourceOperat ion+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . sourceModule+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . targetComponent+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . t a r g e t I n t e r f a c e+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . targetOperat ion+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . targetModule+ ” ’ , ’ ”+ proc e s s e s . get ( i ) . i n s t anc e s


. get (k ) . app l i cat ionData+ ” ’ , ’ ”+ las tGenerated Ins tance Id+ ” ’ ) ; ” ) ;

}}

}} catch ( Exception e ) {

e . pr intStackTrace ( ) ;}

} elseSystem . out . p r i n t l n ( ”No events ! ” ) ;

context . c l o s e ( ) ;} catch ( Exception e ) {

e . pr intStackTrace ( ) ;}return 0 ;

}

public c lass Process {Str ing name ;

ArrayList<Instance> i n s t anc e s ;

public Process ( St r ing aName) {name = aName ;i n s t anc e s = new ArrayList<Instance >(0);

}

public void addInstance ( Ins tance aInstance ) {i n s t anc e s . add ( aInstance ) ;

}}

public c lass Ins tance {private Str ing name ;

private ArrayList<BPELEvent> BPELEvents ;

private ArrayList<SCAEvent> SCAEvents ;

public Ins tance ( St r ing aName) {name = aName ;BPELEvents = new ArrayList<BPELEvent>(0);SCAEvents = new ArrayList<SCAEvent >(0);

}

public void addBPELEvent (BPELEvent aBPELEvent) {BPELEvents . add (aBPELEvent ) ;

}

public void addSCAEvent (SCAEvent aSCAEvent ) {SCAEvents . add (aSCAEvent ) ;

}


}

public c lass BPELEvent {Str ing g l oba l In s t anc e Id ;

St r ing extensionName ;

long sequenceNumber ;

St r ing creationTime ;

St r ing appl i cat ionData ;

St r ing act iv i tyKind ;

St r ing activityName ;

St r ing operat ion ;

St r ing fa i l u r eMes sage ;

public BPELEvent( St r ing aGloba l InstanceId ) {g l oba l In s t anc e Id = aGloba l InstanceId ;

}}

public c lass SCAEvent {Str ing g l oba l In s t anc e Id ;

St r ing extensionName ;

long sequenceNumber ;

St r ing creationTime ;

St r ing sourceComponent ;

St r ing s ou r c e I n t e r f a c e ;

S t r ing sourceOperat ion ;

St r ing sourceModule ;

S t r ing targetComponent ;

St r ing t a r g e t I n t e r f a c e ;

S t r ing targetOperat ion ;

St r ing targetModule ;

S t r ing appl i cat ionData ;

public SCAEvent( St r ing aGloba l InstanceId ) {g l oba l In s t anc e Id = aGloba l InstanceId ;

}}

}

G. JAVA CODE OF THEGETCURRENTTIMESTAMP-COMPONENT

import com . ibm . websphere . sca . ServiceManager ;import java . u t i l . Date ;import java . text . SimpleDateFormat ;

public c lass GetCurrentTimeStringImpl {/∗∗∗ D e f a u l t c o n s t r u c t o r .∗/

public GetCurrentTimeStringImpl ( ) {super ( ) ;

}

/∗∗∗ Re t u r n a r e f e r e n c e t o t h e c omponen t s e r v i c e i n s t a n c e f o r t h i s i m p l e m e n t a t i o n∗ c l a s s . T h i s me t hod s h o u l d b e u s e d when p a s s i n g t h i s s e r v i c e t o a p a r t n e r r e f e r e n c e∗ o r i f you wan t t o i n v o k e t h i s c omponen t s e r v i c e a s y n c h r o n o u s l y .∗∗ @g e n e r a t e d ( com . ibm . w b i t . j a v a )∗/



/∗∗∗ Method g e n e r a t e d t o s u p p o r t i m p l e m e n t i o n o f o p e r a t i o n ” G e t C u r r e n t T i m e S t r i n g ” d e f i n e d f o r WSDL p o r t t y p e∗ named ” G e t C u r r e n t T i m e S t r i n g ” .∗∗ P l e a s e r e f e r t o t h e WSDL D e f i n i t i o n f o r more i n f o r m a t i o n∗ on t h e t y p e o f i n p u t , o u t p u t and f a u l t ( s ) .∗/

public Str ing GetCurrentTimeString ( St r ing input ) {// i n i t i a l i z e f o r m a t t e r w i t h t h e n e e d e d f o rm a t f o r t h e d a t e and t im eSimpleDateFormat formatter = new SimpleDateFormat ( ”dd−MM−yyyy HH:mm: s s ” ) ;// r e t u r n t h e c u r r e n t d a t e and t im e i n t h e r e q u e s t e d f o rm a treturn f o rmatter . format (new Date ( ) ) ;

}

}

H. JAVA CODE OF THEINPUTUIDRETRIEVER-COMPONENT

import com . ibm . websphere . sca . ServiceManager ;import java . s q l . Statement ;import java . s q l . Connection ;import java . s q l . Resul tSet ;import java . s q l . DriverManager ;

public c lass InputUIDRetrieverImpl {/∗∗∗ D e f a u l t c o n s t r u c t o r .∗/

public InputUIDRetrieverImpl ( ) {super ( ) ;

}




/∗∗∗ Method g e n e r a t e d t o s u p p o r t i m p l e m e n t i o n o f o p e r a t i o n ” R e t r i e v eU ID ”∗ d e f i n e d f o r WSDL p o r t t y p e named ” I n p u t U I D R e t r i e v e r I n t e r f a c e ” .∗∗ P l e a s e r e f e r t o t h e WSDL D e f i n i t i o n f o r more i n f o r m a t i o n on t h e t y p e o f∗ i n p u t , o u t p u t and f a u l t ( s ) .∗/

public In t ege r RetrieveUID ( St r ing input ) {try {

// i n i t i a l i z e c o n n e c t i o n f o r t h e MS SQL S e r v e rClass . forName ( ”com . mic ro so f t . s q l s e r v e r . jdbc . SQLServerDriver ” ) ;Connection con = DriverManager

. getConnection (” jdbc : s q l s e r v e r :// pcwin743 . campus . tue . n l : 1 4 33 ; databaseName=StudentSOALabDB” ,”Peter ” , ”∗Password∗” ) ;

// I n i t i a l i z e s t a t e m e n tStatement stmt = con . createStatement ( ) ;// E x e c u t e s t a t e m e n t w h i c h w i l l r e t r i e v e t h e i d e n t i f i e r o f t h e n e w e s t r e c o r d i n t h e I n p u t t a b l eResultSet r e s u l t = stmt

. executeQuery ( ” Se l e c t i d en t cu r r en t ( ’ Input ’ ) as id ; ” ) ;//−1 w i l l b e r e t u r n e d i n c a s e o f an e r r o rint s = −1;// R e t r i e v e t h e i n t e g e r f r om t h e co l umn named i d o f t h e f i r s t r e c o r d f r om t h e r e s u l t s e twhile ( r e s u l t . next ( ) ) {

s = r e s u l t . g e t In t ( ” id ” ) ;}// r e t u r n t h e i d e n t i f i e rreturn s ;

} catch ( Exception e ) {e . pr intStackTrace ( ) ;return new java . lang . In t ege r (−1);

}}

}

BIBLIOGRAPHY

[1] http://www.ibm.com/developerworks/java/library/j-sdo/.

[2] http://www.opengroup.org/projects/soa/doc.tpl?gdid=10632.

[3] http://www.peach3.nl.

[4] http://www.sis.pitt.edu/ taler/.

[5] http://www.sis.pitt.edu/ taler/quizpack.html.

[6] Albert Chung Qian Li Jin Gregorio Patino Lakshminarayanan SreenivasanSaida Davies, William Moore. WebSphere Adapter Development. IBM, 2006.

[7] Tom Verhoeff. Peach 3: Verification system for programming education andcontest hosting, 2007.

Eindhoven University of Technology MASTER Student … Student SOA Lab is used in the realization of...

Documents

Transcript of Eindhoven University of Technology MASTER Student … Student SOA Lab is used in the realization of...