A Service Oriented Architecture for the Finance Case Study http://www Claudio Guidi, Fabrizio Montesi, Ivan Lanese Department of Computer Science, University of Bologna

General view The Finance Case Study SOA can be seen as the composition of several SOAs An Account SOA for user authentication A Bank system SOA Finance SOA implements the specification workflow A customer app Finance Case Study SOA Finance SOA Customer Account SOA Bank SOA

The customer application Performs a login on the Account SOA and receives a sessionID Performs a credit request, sending all the needed data Waits for a response from the Finance SOA May modify the input data, if requested by the Finance SOA

The Account and the Bank system A simple service wrapping a mysql database which stores all the users Can be improved by considering federation among different account SOAs Security features can be added The Bank system Is exploited for checking customer balances Is the same Bank system of the automotive case study

The Finance SOA Request Registry To the Account SOA 3. setRequest 1.Auth Process SOA Orchestrator 4. processRequest From the customer - login - supplyInfo 2. checkAvailability 5. - dataChange - rejection - acceptance To the Bank System SOA

The Finance SOA: the orchestrator Receives a login request from the customer and authenticates it to the Account service Checks all the balances inserted by the customer by invoking the related bank services If the balances are valid, stores into the Request Registry all the data of the new request The Request Registry is a repository of the active requests Calls the Process SOA for processing the new request

Selection Employee Policy Service The process SOA Select the employee depending on the operation to perform: check securities, rating, making offer, validate Selection Employee Policy Service B. Register the employee Employee Clients Process Service Calls the employee service Metaservice A. Load its Employee Service The metaservice collects all the Employee services which are active into the SOA. INTERESTING ARCHITECTURAL PATTERN Employee Service

The Process SOA: starting up Employee clients may be just browsers that performs requests instead of services An Employee service receives requests from an Employee client and acts as a proxy for it When a client is started, it dynamically loads its own Employee service into the metaservice which returns a specific resource name for that service The client then registers itself into the Select Employee Policy

The process SOA:dynamic employee selection Thanks to the Select Employee Policy Service, employees can be dynamically selected Selection policies can be changed dynamically Employees are selected depending on the task they are enabled to perform (checking securities, rating, making an offer, superior validation ) The Select Employee Policy Service, when invoked, returns an employee’s username and its related Employee Service reference into the metaservice

The process SOA: Process Service Receives a credit request to process Retrieves all the request information from the RequestRegistry Selects an employee for checking securities and waits for its response Selects an employee for rating the request and waits for its response Selects an employee for making an offer and waits for its response Asks a superior for validation If the superior accepts, the request is carried on If requested, a request to change the data is sent to the customer

Conclusions The proposed architecture is fully service-oriented The management of employees is dynamic Employees can be added at any time Employees selection policy can be changed at runtime Possible improvements: Build graphical interfaces for services both as a stand alone application and as a browser interface Add more details to the process

Demo time