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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. Demo time