Service Learning and Teaching Foundry: A

Virtual SOA/BPM Learning and TeachingCommunity

Hye-Young Paik1, Fethi A. Rabhi1,Boualem Benatallah1, and Joseph Davis2

1 School of Computer Science and Engineering,University of New South Wales, Australia

{hpaik,fethir,boualem}@cse.unsw.edu.au2 School of Information Technologies,

University of Sydney, Australiajoseph.davis@sydney.edu.au

Abstract. With the growing presence of BPM and SOA in the IT indus-try, their impact on the IT education will be profound. Many institutionsare becoming aware of the acute need of developing learning and teachingresource frameworks for the BPM and SOA. In this paper, we presentpart of such an effort from a team at the University of New South Wales,currently developing Service Learning and Teaching Foundry as a dedi-cated virtual teaching and learning space for BPM/SOA. We present themotivation, design and current implementation of the foundry, as well asa curriculum design of a Service Technologies module which is used topilot the foundry system.

1 Introduction

BPM (Business Process Management) and SOA (Service Oriented Architecture)are fast becoming an integral part of the way modern business organisations un-derstand their business architecture, and manage their business processes. BPMoffers a methodology and tools for organisations to model, analyse and integratebusiness processes that involve IT systems and human interaction. SOA providesthe principles of developing reusable business service and applications that col-lectively fulfil an organisation’s business processes and goals [1–3]. The tools andmethodologies from both paradigms have equipped the enterprises with cross-platform compatibility, agility and cost-efficiency for continual improvements intheir core operations [4].

With the growing popularity of BPM and SOA in the IT industry, their impacton the IT education will be profound. Many already anticipate that one of themost important skills for an IT graduate today is to be able to understand therole of BPM and SOA in different contexts and to articulate the motivationbehind service-based technologies and their practical implications in terms ofengineering complex software systems and automating business processes [5–7].

M. zur Muehlen and J. Su (Eds.): BPM 2010 Workshops, LNBIP 66, pp. 790–805, 2011.c© Springer-Verlag Berlin Heidelberg 2011

Service Learning and Teaching Foundry 791

In 2008, a consortium of leading universities in Australia was awarded anAustralian Learning and Teaching Council (ALTC) grant to investigate thedevelopment of industry relevant curriculum modules and other educational re-sources. The context of the investigation is inline with the SSME (Service Sci-ence Management and Engineering) movement [8, 9] which is gathering supportfrom leading IT companies and higher education sectors worldwide1, especiallythe institutions associated with SOA and BPM are active participants of themovement2.

As part of the investigation, the University of New South Wales team areproposing two modules: Engineering Service Systems and Service Technologies,under which the core theoretical concepts and practical tools and skills of SOAand BPM are discussed. An innovative part of the proposed modules is Ser-vice Learning and Teaching foundry which is a dedicated virtual teaching andlearning space for SOA/BPM. The foundry provides an open and collaborativeenvironment for teaching resources to be created, shared and re-used, all in thecontext of educating SOA/BPM.

In this paper, we present the detail of one of the two modules: Service Tech-nologies, and the foundry. In particular, we explain how the foundry underpinsthe design and delivery of the module.

2 The SSME Curriculum Renewal Project

One of the first-stage outcomes the SSME project is an interim report fromfocus group discussions [10]. This section gives an overview of the focus groupdiscussions and the key themes identified as a result.

2.1 SSME Focus Group Discussions

The focus groups consisted of various stakeholders in industry, recent graduatesand academic staff members. The report frames the information gathered fromthe discussions to give in-depth description about key knowledge and skill setsrequired in the workplace and the challenges faced by the industry due to therecent development in technologies (e.g., Services, Web 2.0, Cloud Computing).

As an industry trends report suggests3, business process modelling and mid-dleware/SOA were named number one and three skills that are in demand. TheSSME project interim report also confirms such trends in Australia, where com-panies are looking into offering their traditional software package products asservices (Software as a Service), dealing with the challenges of carrying the oldtechnology environment, which was never designed to be open and shared, intothe new environment.

The traditional role of an IT person is changing, in the sense that the personshould have understanding of the ‘end-to-end’ business, client perspectives and1 IBM SSME Portal, http://www.ibm.com/developerworks/spaces/ssme2 https://www.ibm.com/developerworks/wikis/display/ssme/Universities3 http://www.networkworld.com/news/2009/040609-10-tech-skills.html

792 H.-Y. Paik et al.

the complete life cycle of services. This requires a clear overview of how varioustechnologies fit into different areas in the business and how they are reused whennecessary [11, 12].

The focus group discussion also highlighted that the real challenge is to equipgraduates, not only with technical competency, but also with an appreciationof the global, collaborative nature of modern software development. In this as-pect, two important aspects of software development skill sets are identified: theability to work in a virtual (distributed) team and competency in using onlinecollaboration tools.

2.2 SSME Key Modules Overview

We identified the following major themes from the focus groups discussions.Figure 1 depicts the key modules planned for the SSME project, some of which

Fig. 1. SSME modules and their relationships

are already being designed and delivered on a trial basis, others are in initialdiscussion stage. The outcomes will collectively make up the SSME modulesand would form the basis for the renewal of IT curriculum for participatinginstitutions and also inform the wider education community [13].

The diagram shows the diverse nature of the disciplines involved. With regardsto the SOA and BPM topics, the implicitly expressed view here is that the twoareas are intrinsically linked. As [3, 7] point out, the industries are leading theconsolidation of SOA and BPM. The evolution of standards, such as WSDL (WebService Description Language), BPEL (Business Process Execution Language),BPMN (Business Process Modelling Notation), allow the smooth integration ofcompatible SOA-based tools and business processes across heterogeneous de-ployment environments.

It is noted that the “Engineering Service Systems” and “Service Technologies”modules focus on systems and technologies aspect of SOA and BPM, i.e., Web

Service Learning and Teaching Foundry 793

services and Service-Oriented Architectures (SOAs) are discussed as underlyingtechnical operating systems for BPMS (Business Process Management Systems),especially in the context of enterprise application integration architectures.

3 Motivations

In this section, we present the motivations which inform our vision and approachfor SOA/BPM education.

3.1 Student Feedback

The authors have been involved in the design and delivery of courses in the area ofService-Oriented Architectures and Business Process Modelling and Engineeringfor a number of years. Initially started as ‘WS-*’ services and Web applicationengineering course in 2005, in the last couple of years, the syllabus of the coursegradually changed. We included related subject matters that are emerging andbecoming increasingly important to IT students [6, 14, 15]: understanding ofservice-orientation, enterprise systems and application integration, business pro-cess modelling, automation, and alternate ways to model and implement servicessuch as REST (Representational State Transfer) based architecture.

To accommodate the need for opportunities to practice the technical skills,we increased the number of activities in labs and assignments in the course. Wealso streamlined the design of the activities with the weekly lecture topics (asshown in Table 1).

The direction was chosen based on the feedback from students (both formaland informal) and received positive responses such as “Very useful for gradu-ates’ future”, “the course teaches emerging and new technologies”, “the courseintroduces various and useful tools for real world problems”4, etc.

3.2 Building the Community of SOA/BPM Learning and Teaching

Another strong influence is our aspiration for working towards building a com-munity of learners and teachers who share common interests and passion forSOA/BPM education. There are many online teaching resource sharing Websites and portals (e.g., Blackboard, Moodle). However, most portals are mainlydesigned for limited types of users (e.g., students and teachers from the samefaculty/institution) and coordinating cross-institutional collaboration, or cross-student-groups (e.g., year 3 students and year 2 students) is not straightforward.

We have not yet seen a complete teaching environment designed with a longterm vision of underpinning a virtual community of learners and teachers of thistopic, especially in terms of crossing physical, time, and discipline boundaries.

Figure 2 presents an online portal environment in which open, but well-organised teaching materials are created, shared and reused by multiple institu-tions. The vision is to create a meaningful repository of community knowledge4 Direct quotes from student evaluation forms, 2008, UNSW.

794 H.-Y. Paik et al.

Fig. 2. Service Learning and Teaching Online Portal Environment

for educating the students and instructors in the area. The portal will provide,not only a repository of document-based resources (e.g., reference processes, an-notated bibliographies), but also a hosting environment for many SOA and BPMrelated tools (e.g., BPMN modeller, WSDL inspector, Apache Axis runtime).

We strongly believe that the teaching and research discipline we are in givesus an opportunity to create an innovative and interesting learning and teachingcommunity that uniquely represents what we do.

For example, take the concept of consuming a service designed by someone elsein SOA. One group of students can develop a service in a class that is consumedby another group of students from a different class as learning resources. Thesame service can be reused in different learning contexts depending on the learn-ing objective (e.g., exposing WSDL view or BPEL view). The same service canbe re-engineered by one class and its design process can be debated in a differentclass as a case study. The process of developing and administering an assignmentitself can provide an experience of business processes - a concept students couldeasily relate to. Of course, the experiences can be shared amongst multiple in-stitutions to create interesting BPM case studies. In our opinion, the possibilityof applying our own discipline principles to the portal vision is endless.

Based on the vision depicted in Figure 2, our work starts with implementingand contributing to realising the concrete building blocks of the portal. In par-ticular, the rest of the paper focuses on the development of a Service Learningand Teaching Foundry

3.3 Service Learning and Teaching Foundry

Service Learning and Teaching Foundry, or the foundry for short, is the first con-crete step towards realising the type of unique learning and teaching

Service Learning and Teaching Foundry 795

community we mentioned earlier in Section 3.2. We believe it could potentiallyenable us, IT educators, to re-think the way the core business of IT, systemsdesign, implementation and re-engineering, are taught.

The foundry aims to provide an open, collaborative, continuously evolvingand growing virtual space for students to learn the concepts of SOA/BPM, andpractice their skills using real-world examples. The collaborative nature of thefoundry means that it enables the students to interact with groups of studentsat many different levels: across classes in the same institution, across institutionsor across different disciplines (e.g., Computer Science students interacting withBusiness Administration students). The continuously growing side of the foundrymeans that it will become a rich repository of services and processes designedand built over time by students. It will be an important resource for training thevery concept SOA/BPM preaches on services and business processes: identify,define, capture, store, reuse and optimize [1].

Also, we see that the foundry, once matured, will become an effective teach-ing and experimentation tool for learning the lifecycle management aspects ofSOA/BPM. That is, the foundry can provide a real-world example of case studieson studying an impact of retiring a service, updating a service or analysing thedependencies between the services in the repository and process implementation.

4 The Foundry Design and Implementation

In this section, we explain in more detail the design, architecture and currentimplementation of the foundry.

4.1 Domain of the Foundry

Central to the foundry design is the belief that it should contain a sufficientnumber of properly designed and well-documented services that interoperatewith each other. For this reason, the foundry services are built around the re-quirements of a small number of application domains. The current domain ofthe foundry is in finance trading.

The field of financial trading has seen an unprecedented increase in the num-ber of participants and the volumes of trades conducted via electronic markets,high frequency data has become increasingly available for historical analysis byresearchers in fields like econometrics, finance and accounting. The foundry in-cludes basic material that describes basic concepts of finance, market structuresand microeconomics. It includes information on the trading lifecycle, the differ-ent types of computer systems involved and how trading data is captured fromexchanges and distributed by third party providers. It also explains the differenttypes of analysis that can be performed on the data.

4.2 Design of the Foundry

The main purpose of the foundry is to act as a repository of Web services toenable the development of practical assignments and projects which are part of

796 H.-Y. Paik et al.

some of the Curriculum Modules. For example, a technically-oriented modulecould require students to contribute services to the foundry whereas a morebusiness-oriented module could involve students developing their own mash-upsof services to satisfy a business objective.

Figure 3 depicts the overall architecture of the foundry. The figure shows thatthe Foundry Core contains information specific to the target application do-main. Besides background documentation and material, it includes a data modelthat concretely represents business entities in this domain and a data repositorythat contains instances of the data model (e.g. sample files and databases). Inaddition, the core contains tools and services for manipulating (i.e. accessing,creating and modifying) instances of the data model together with their APIdocumentation.

The Foundry Core is one of the salient features of the foundry design. It is thesource of the common data model, services, ample test data and documentation.Because of the core, all learning activities of the students can be designed arounda single application domain.

Fig. 3. The Architecture of the Foundry

There are five types of Foundry L&T Resources built on top of the core:

– Use Cases describe in detail user requirements around the application do-main(s) of interest. They should be written in a way that students can seelinks with the underlying data model and the sample Web services provided.

– Sample Web services (complete with their code) are provided to underpinthe material contained in the tutorials, assignments and projects.

– Tutorials introduce a particular topic (e.g. securing Web services).– Assignments are “hands-on” tasks given to students with a particular learn-

ing objective (e.g. developing a simple WSDL interface). Such assignmentswill be set according to the learning objectives of particular modules but itis expected that some assignments will be shared by several modules.

– Non-trivial programming exercises will require students to undertake projectwork at different levels of difficulty (e.g. extend the SOA with new services).

Service Learning and Teaching Foundry 797

Resources on the foundry can be accessed in two ways: direct user interface (i.e.,Web-based GUI) and APIs (i.e. programmable interfaces)5. Therefore, access tothese resources is possible for students with different levels of technical skills. Italso expected that the foundry will include a separate area for demonstrationsand testing.

4.3 Current Implementation

The implementation of the foundry described in this paper revolves around thearea of financial market data analysis. This application domain was selected forthree reasons:

– it is a non-trivial domain in which most IT students have no prior knowledge.This encourages them to undertake a significant effort in acquiring suchknowledge

– our team was granted access to vast amounts of Reuters financial market databy SIRCA6. This provides second-to-none opportunities for the students toexplore and experience with real world data.

– there are many analysis scenarios which involve generic techniques (e.g. re-gression analysis). Therefore, the scope of defining services and businessprocesses is very large. This provides many opportunities for collaborativeprojects with industry as well as reusing such knowledge in other applicationdomains (e.g. business intelligence).

The current foundry is at http://soc.cse.unsw.edu.au/teachingfoundry/.It is not yet open for general public contributions. We will soon officially launchthe foundry with collaboration features. In the rest of this section, we explainthe main elements of our implementation in more detail.

Data Model. The data model allows uniform representation of financial marketdata. It is based on the following essential entities:

– Event source: This is the primary source of high frequency data. Sourcescan be log files, databases, web services, information portals, etc. The mainevent source in this implementation is SIRCA’s TRTH system [16].

– Event: An event is the base entity from which other types of event entities arederived. The most important attributes in an event are the timestamp andthe financial product concerned by the event. In our case study, the threetypes of events are Trade (representing the occurrence of a trade), Quote(representing the broadcast of a quote) or Measure (representing a snapshotof one of the market measures like volume-weighted average price (VWAP)).

– Product: A product (tradable or non-tradable) is uniquely identified throughsome identification code. In this implementation, products are named usingthe Reuters Identification Code (RIC).

5 The API to the foundry itself is not yet available.6 www.sirca.org.au

798 H.-Y. Paik et al.

The proposed event-based data model makes it possible for several services toprocess data in a consistent way by sharing a common data reference model.Additional details of the model can be found in [17].

Data Repository. This implementation is based on the Thomson ReutersTick History (TRTH) system [16]. TRTH allows access to intra-day trade andquote information for over 244 exchanges and Over The Counter (OTC) marketsaround the world. Datasets are stored in a format suitable for viewing as aspreadsheet. A row corresponds to a time-stamped piece of information suchas the occurrence of a trade, a variation in an instrument’s quoted price oran index, the publication of a news story or a market announcement etc. Thesample repository consists of files from different types of markets (e.g. equitiesand options) as well as geographic areas (e.g. USA, Europe and Australia). Anumber of tools are also available for converting files from their native formatinto data model compliant instances.

Use Cases. There is a wide range of possible analysis business processes thatcan be defined around financial market data. Most of them start by aggregatingdata in some way to build financial time series. Such timeseries can be visu-alised or compared with each other using a number of techniques (e.g. statistics,machine learning). In this implementation, the main use case defined involvesdetecting price jumps in the time series data (e.g. identifying abnormal returnsfor a particular stock).

Sample Web services. The Web services provided in this implementation aredesigned to interoperate with each other using the producer-consumer modelof interactions. The basic unit being transmitted between services are eventstreams. There are three types of services:

– Event Sources: produce event streams from some kind of data set of anon-line source of information.

– Event Transformers: transform one or more streams of events into one ormore streams of events

– Event Sinks: consume events to produce some kind of results

The sample services provided in this implementation (Figure 4) are intended toimplement the main use case. They can be briefly described as follows:

– TRTH Import Service: builds an event dataset from market data files. Thesefiles will be preloaded from TRTH system into the data repository.

– Timeseries Building Service: will aggregate events according to regular timeintervals. This is a prerequisite to most time-series analysis

– Merge Service: will merge different streams of data into one, for example itcan be used to relate trade prices with index prices.

– Price Jump Service: will detect “price jumps” in the timeseries data accord-ing to some reference timeseries (e.g. index data).

Service Learning and Teaching Foundry 799

Fig. 4. Sample Web services in the Foundry L&T Resources

– Download Service: will allow events to be downloaded into a format suitablefor viewing or further processing by the user (only CSV is supported in thesample implementation).

– Visualisation Service: will allow events to be visualised in the form graphs.

These services were initially developed as part of the ADAGE Project [17, 18].The idea is that each service illustrates a particular building block and can beused in several use cases. Assignments and projects can be defined by using,modifying, composing or extending these sample services. A sample of assign-ments specific to the learning outcomes of the Services Technologies module willbe illustrated in the next section.

5 Syllabus of Service Technologies

This year, the early prototype of the foundry implementation is being used indelivering the course in Service Technologies. The course syllabus7 has beenrevised to utilise the services provided by the foundry. This revision is also partof the Curriculum Modules design and development effort which is underway inthe SSME project (cf. Figure 2).

In this section, we present the overview of the course outline and its relation-ship with the foundry.

5.1 Background/Assumed Knowledge

The course is offered to advanced undergraduate and postgraduate students andattracts around 40-50 students every semester. As the course is technical in na-ture, students will need to have completed at least one programming language

7 The concrete name at our university is COMP9322: Service Oriented Architectures.

800 H.-Y. Paik et al.

course, database course and a Web application development course. For BPMtopics, students will also need to have some basic understanding of XML lan-guages and UML (Unified Modelling Language).

5.2 Learning Outcomes

The expected learning outcomes of the course are at two levels: broad outcomesand specific knowledge/skills.

Broad outcomes:

– Describe architectural design styles in enterprise application integration,– Apply the concept of business processes in a concrete setting and be compe-

tent in developing solutions using SOA and related technologies,– Learn to work as a team and be efficient in managing collaboration. Be

competent in choosing and utilising online collaboration tools.

Specific knowledge/skills outcomes:

– Identify the communication and integration patterns in enterprise systems,– Discuss the role of various XML technologies in Web Services,– Be competent users of Web services and BPM (both traditional and emerg-

ing) technology such as WS-* standards, BPEL, BPMN and process mod-elling methods, Data access services and RESTful services.

5.3 Assessment

The assessment consists of the following components. Besides the formal andpractical parts of the assessment, we also emphasise teamwork managementand use of various collaboration tools (such as Google Sites or open-sourceproject/issue management software). This helps the students keep track of theircollaboration trails and have hands-on experience with using collaborative soft-ware in a project setting.

– 40% formal written exam: this component is going to assess the various facts-and-knowledge level learning outcomes. The exam is a mixture of multiplechoice questions and written answer questions.

– 50% on laboratory work: this component assesses the practical-skills-and-tools level learning outcomes. The assessment activities include five pro-gramming assignments. Each assignment is designed for students to explorea important technology. Labs are released every two weeks to encouragestudents to progressively develop their skills.

– 10% on the management of teamwork: this component assesses the level ofcoordination and management of group work. It evaluates how effectivelythe students use a (online) collaboration tool and peer-assessment of teammembers in a team on the level of collaboration and participation in thegroup work.

Service Learning and Teaching Foundry 801

5.4 Key Learning Resources/Materials

Overview. The key learning resources consist of three components: (i) lectureand lecture notes, (ii) lab exercises and assignments and (iii) the service learningand teaching foundry. Figure 5 illustrates how they are organised.

Fig. 5. Overview of the Module Components

The lectures introduce the theory and concepts in course. For each lecturetopic, we associate a simple lab exercise to familiarise students with the topic. Tolet them investigate further and develop deeper understanding about the topic,at the end of lab exercise, we give not-so-trivial design and implementation tasksas assignments. More details about the practical exercises and the role of foundryare presented Section 5.5.

Weekly Activity Schedule. Table 1 shows the weekly student activities. Theyare streamlined according to lectures and assessment tasks.

5.5 Foundry Support for Labs and Assignments

As illustrated in Figure 5, we design the lab exercises and assignment tasksaround the data and sample services available in the foundry. Clearly, as thefoundry matures and its links with other modules in the portal consolidate, thenumber, variety and technical levels of exercises and assignments will increase.The following lists the plan for this semester only.

– Environment setup: students are first introduced to the background docu-mentations and event data model in the foundry. The exercise will ask themto read the background materials and install software (e.g., Tomcat and Webservices libraries).

802 H.-Y. Paik et al.

Table 1. Weekly Activity Schedule

W.Lecture Topic Lab/Assignment Expected Activities

1 Enterprise ApplicationIntegration Architec-tures

Lab Zero: Setup Ex-ercise Environmentand Necessary Tools

Students install and test all necessary develop-ment tools used in the course and familiarisethemselves with the structure and concept of thefoundry.

2 Service-Oriented Ar-chitecture Foundations(I): SOA concepts andWeb Services Standards(WSDL, SOAP, UDDI)

Lab/Assignment I:on Writing a SimpleService

Students can start to describe the basic conceptsof SOA and the main Web service standards. Stu-dents are engaged in conceptual design of a simpleservice and a client, using the data and sampleservices at the foundry.

3 Service-Oriented Com-puting Foundations(II) SOA concepts andWeb Services Standards(WSDL, SOAP, UDDI)

Lab/Assignment Idue

Students can fully describe the concepts of SOAand the Web service standards. Based on the con-ceptual design, students are able to implement asimple WSDL-based service and a client program.

4 Data as Services (I):XML data access andtransformation tech-nologies

Lab/Assignment II:on Writing a SimpleService Wrapper

Students can identify XML technologies for dataaccess and manipulation for Web services. Usingthe existing domain applications available in thefoundry, students design a way to expose the func-tionality for a client as a service.

5 Data as Services (II):XML data access andtransformation tech-nologies

Lab/Assignment IIdue

Students can fully describe how XML technolo-gies are used for data access and transforma-tion in Web services. Using the foundry’s existingdomain-specific applications, students are able toexpose the functionality as a fully-fledged Webservice by writing a wrapper.

6 RESTful Services (I):REST architecture andREST-based services

Lab/Assignment III:on Writing a DataService

Students can describe REST architecture as analternative Web service development technology.Based on the foundry’s sample services, studentsdesign a data access and transformation servicefor a client using XML technology.

7 RESTful Services (II):REST architecture andREST-based services

Lab/Assignment IIIdue

Students understand the steps and knowledge in-volved in developing a REST-based service. Usingthe foundry’s sample services, students fully im-plement the data access and transformation ser-vice.

8 Business Process Man-agement

Lab/Assignment IV:on REST-based ser-vice development

Students learn the important concepts in businessprocesses and their relationships to Web services.Based on the foundry’s sample services, studentsdesign a REST-based service. for a client.

9 Business Process Execu-tion: BPEL and Webservice composition

Lab/Assignment IVdue

Students learn the important concepts in busi-ness processes automation and service composi-tion techniques. Based on the foundry’s sampleservices and the design, students fully implementthe REST-based service.

10 Advanced Topics in Webservice composition

Lab/Assignment V:on Business Pro-cesses and BPEL

Students learn more advanced concepts and openissues in service composition techniques. Based onthe foundry’s sample services, applications andpreviously built services from the assignments,students design a business process to be auto-mated.

11 Open Topic Lab/Assignment Vdue

An industry guest speaker or researcher in thearea of Web services may be invited to give talksabout emerging issues and visions in SOA. Basedon the design from the previous week, studentsfully implement the automated business processand its client using BPEL.

12 Revision No lab activity The final week is used to revise and reflect on thetopics taught over the weeks.

Service Learning and Teaching Foundry 803

– Lab/Assignment 1: the exercise leads students to learn top-down and bottom-up approaches to Web service design and implementation. A sample Webservice (TRTH data import and download) skeleton code and accompany-ing WSDL are provided from the foundry. In the assignment, students areasked to fully implement the TRTH data import and download service. Thefoundry provides test files directly derived from the TRTH repository.

– Lab/Assignment 2: the second lab and assignment are focused on the con-cept of designing and implementing a service which exposes some existingfunctionality in a system. The foundry provides a fully working implemen-tation of a data transformation program (written in Haskell). The studentsare asked to design appropriate interfaces and provide implementation witha view to be, later, integrated with the TRTH download/import service.

– Lab/Assignment 3: the third lab and assignment are about understandingdata services. We provide two different scenarios in business processes thateither requires extracting data from the foundry and generate RSS-feed ser-vice, or requires transformation of output message formats to the correctinput message formats expected by another service in the foundry.

– Lab/Assignment 4: the lab shows the basics steps in building a simple REST-based service. The assignment asks the students to provide an alternativeimplementation of the services introduced in assignment 1 and 2.

– Lab/Assignment 5: the final lab and assignment are about modelling andimplementing business processes. The foundry provides the fully workingsample Web services on the TRTH dataset (cf. Figure 4) for this exercise, sothat the students can focus on building a process model on top of the services.In the assignment, students use 3-4 services in the foundry to implement anend-end process of history data analysis.

6 Module and Foundry Evaluation Plan

The evaluation of this module will require a long-term approach where contin-uous feedback and response cycles are applied. The experience gained throughthe evaluation and revision cycle will inform the direction of the foundry andthe portal development overtime.

The university conducts a formal course evaluation at the end of every semester.However, the design of the evaluation process is such that only a small numberof students and academic staff members participate and the results of the surveyare often released to the lecturer-in-charge only. That is, it is difficult to consultwider audience and stakeholders.

Since it is important for us to collect meaningful and insightful feedbackthroughout the module and portal development process, we are proposing tohost a dedicated Wiki/Blog-style Web site for soliciting comments, suggestionsand self-reflective remarks about the learning activities from the students, tu-tors and colleagues. At the end of each semester, a moderator will summarisethe feedback and post an official follow-up response so that it is visible to the

804 H.-Y. Paik et al.

relevant audience how the module and portal development are progressing. Thissemester, we expect to receive feedback from 54 students and 3 tutors.

Ultimately, our experience gained through the evaluation process will con-tribute to the development of the Curriculum Evaluation Tools in the roadmap(cf. Figure 2). After initial trials, we hope to report the findings in the nextappropriate forum.

7 Conclusion and Future Work

In this paper, we described outcomes and on-going work of the SSME project.Particularly, we presented the UNSW team’s roadmap for building a communityof SOA/BPM education as a foundation for a collaborative learning and teachingenvironment. We have taken concrete steps to design and implement the ServiceTeaching and Learning Foundry using financial data analysis as a target appli-cation domain. We have revised our offering of “Service Oriented Architectures”course (i) to reflect the student feedback over the years and industry focus groupdiscussions and (ii) to utilise the foundry structure and materials.

The results from the pilot course from this semester will be a valuable sourceof information for designing the next version of the course, but also designingthe other courses in the SSME project curriculum as planned in Figure 1. Ourinterests are in extending the foundry L&T resources so that the foundry appliesto the modules beyond technical topics intended for computer science students.We will collaborate with other university team members in the SSME project tocommunicate the requirements and applications of the foundry during the othermodule developments.

There are a number of teaching and learning related tools being developed atUNSW through student-led projects (e.g., online Q/A (Question/Answer) sys-tem that automatically suggests an answer based on the past Q/A data andcollaborative lecture slides authoring tool), some of which may be contributedto the portal through our foundry framework in the future. Also, we plan to in-vestigate and design a generic repository framework for hosting other innovativetools (e.g., Business process modelling tools, Multi-media education games).

Acknowledgements

This paper has been supported by Australian Learning and Teaching CouncilLtd, an initiative of the Australian Government Department of Education, Em-ployment and Workplace Relations. The views expressed in this paper do notnecessarily reflect the views of the Australian Learning and Teaching Council.We thank Lawrence Yao for his effort in the implementation, SIRCA for giv-ing the data and use cases and DEST for funding the ADAGE project. Wethank the other university participants and industry supporters of the SSMEproject.

Service Learning and Teaching Foundry 805

References

1. Goos, G., Hartmanis, J., van Leeuwen, J. (eds.): Business Process Management:Models, Techniques and Empirical Studies. LNCS, vol. 1806. Springer, Heidelberg(2000)

2. Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web Services: Concepts, Archi-tecture and Applications. Springer, Heidelberg (2003)

3. Behara, G.K.: BPM and SOA: A Strategic Alliance. BPTrends Columns (May2006), www.bptrends.com

4. Rosen, M.: Designing Service Oriented Solutions (Part I and II). BPTrendsColumns (May 2009), www.bptrends.com

5. Lopez, N., Casallas, R., Villalobos, J.: Challenges in Creating Environments forSOA Learning. In: SDSOA 2007: Proc. of the International Workshop on SystemsDevelopment in SOA Environments, IEEE CS, Washington, DC (2007)

6. Maurizio, A., Sager, J., Jones, P., Corbitt, G., Girolami, L.: Service Oriented Ar-chitecture: Challenges for Business and Academia. In: The 41st Annual HawaiiInternational Conference on System Sciences (HICSS), Hawaii, pp. 315–323 (2008)

7. Kamoun, F.: A Roadmap Towards the Convergence of Business Process Manage-ment and Service Oriented Architecture. Ubiquity, 1–8 (June 2007)

8. Spohrer, J., Maglio, P.P., Bailey, J., Gruhl, D.: Steps toward a science of servicesystems. Computer 40, 71–77 (2007)

9. Communications of the ACM: Service Science, Special Issue. ACM, New York, NY,USA, 49(7) (July 2006)

10. The University of Sydney: SSME Project - Interim report of the Focus Groupdiscussions on knowledge and skill requirements of successful service professionals(2009) Australian Learning and Teaching Council (ALTC) Project (2009)

11. Fingar, P.: Extreme Competition: The MBA is Dead, Long Live the MBI. BP-Trends Columns (December 2006), www.bptrends.com

12. Cantara, M.: Eleven Steps to Take Before Staffing Business Process ManagementProjects With Internal or External Resources. Gartner Reports (August 2008),http://www.webwire.com/ViewPressRel.asp?aId=76215

13. U. of Sydney, UNSW, U. of QLD and U. of Melbourne: Curriculum Renewal inPostgraduate Information Technology Education: a Response to Growing ServiceSector Dominance (2008-2010) Australian Learning and Teaching Council Grant

14. van Vliet, H.: Some Myths of Software Engineering Education. In: ICSE 2005:Proceedings of the 27th International Conference on Software Engineering, pp.621–622. ACM, New York (2005)

15. Recker, J., Rosemann, M.: Teaching Business Process Modelling: Experiencesand Recommendations. Communications of the Association for Information Sys-tems 25(32), 379–394 (2009)

16. Reuters, T.: Thomson Reuters Tick History (TRTH). available from the SecuritiesIndustry Research Centre of Asia-Pacific (SIRCA)

17. Rabhi, F., Guabtni, A., Yao, L.: A Data Model for Processing Financial Marketand News Data. International Journal of Electronic Finance 3(4), 387–403 (2009)

18. Guabtni, A., Kundisch, D., Rabhi, F.: A User-Driven SOA for Financial MarketData Analysis. Enterprise Modelling and Information Systems Architectures (2010)(to appear)