Using Spring Framework in HP Outsourcing Services End User Portal

Using Spring Framework in HP Outsourcing Services End User Portal Pierre Fouché [email_address]

« My IT Portal »: Provide HPO customer users with simple access to IT services

Incident management

Change management

Knowledge management

Configuration management

Desktop diagnosis

Password management

…

One single code base, but adapted to customers by configuration:

Features, systems, languages, look & feel…

150+ customers; 500,000 end users.

Timeline:

Development started in 2002.

Spring introduced in 2004.

HPO End User Portal

Architecture Presentation Layer Controller Model View Controller Model View Service Layer Canonical model Implementation Service Call Manager Incident Manager X SC Manager X Incident Manager Y Incident Manager X SC Manager X Incident Manager Data Access Layer Backend Applications Application X2 Application X1 Application Y1 Y Incident Manager X SC DAO X Incident DAO X SC DAO X Incident DAO

One global application context is not enough

Multiple beans of the same type

Unable to resolve controller dependencies

Idea:

One bean factory per backend application (called “system” bean factory)

One bean factory per customer

Transfer beans from system bean factories to customer bean factories, based on systems used by customer.

Bean management

Bean management (2) X-1 Cust-2 Main application context System bean factories Company bean factories X-2 Y-1 Cust-1 Imported beans Internal beans Exported beans S3 S3 S1 S2 S1 S2 S1 S2 S1 S2 S1 S2

Problem: A service can be provided by multiple application instances

For instance, service calls can be tracked on multiple systems.

Company bean factories can still contain multiple beans of the same type.

Idea: Use an additional resolution step, based on:

An intermediate bean factory;

Bean resolvers: Proxies that dispatch calls to different implementations, based on different “strategies”.

“ Simple Dispatcher” bean resolver

“ Location” bean resolver

“ Master/Legacy” bean resolver

Refinement 1 : Bean resolvers

Bean resolvers (2) X-1 X-2 Cust-1 Bean resolver System bean factories Company bean factory S2 S2 S1 S1 S2 S1 S1 S2 S1 S2 S1 S2

Refinement 2: Dependencies between systems

Use special post processors to “assemble” service implementations together .

Refinement 3: “Hot” reloading

Problem: Some “systems” need to be reconfigured without stopping/restarting the portal.

Idea: Use two bean factories:

A “parent” bean factory containing “destroyable” beans

A “child” bean factory containing proxies to the beans in the parent bean factory

“ Reload” operation controlled by JMX

Refinements 2 & 3

“ Hot” reloading (2) “ Child” bean factory “ Parent” bean factory Regular bean Proxy bean Target Bean 1. Reload 2. Create new parent bean factory 3. Assign new target bean 4. Delete old parent bean factory