Lessons Learned from an Enterprise RCP Application

aniseedsplashΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 3 μήνες)

259 εμφανίσεις

Redistribution and other use of this material is covered by EPL.

PR0006
-

2008
-
01
-
28

Lessons Learned from an Enterprise RCP Application

During the implementation of a major financial application for a large
financial institution, we learned a lot about how to use Eclipse RCP as
an application platform and especially some of the short
-
comings of the
current platform.


This long talk goes through some of the lessons we learned and
discusses some of the changes that could be made to Eclipse RCP to get
a better platform for enterprise applications.

PR0006
-

2008
-
01
-
28

2

Agenda


The Application


Lesson 1: All end
-
users are not engineers


Lesson 2: All windows are not equal


Lesson 3: Editors are no good


Lesson 4: Views are only a little better


Lesson 5: Update must be dynamic


Lesson 6: Security is King


Lesson 7: Some frameworks are still missing

PR0006
-

2008
-
01
-
28

3

The Application


Nordea is one of primary financial institutions in the Nordic countries
with branches in Denmark, Sweden, Norway and Finland


The business includes banking, pensions and insurance


The long
-
term aim of the project is to replace all the existing banking
applications in one common integrated desktop


Customer management


Teller


Product Provisioning (loans, credit cards, pensions, insurances,…)


End
-
users are all branch and call center personnel (clerks and managers)


Organized in a number of levels with different working areas


First version will cover provisioning of non
-
collateral loans, credit cards
and other types of short
-
term loans

PR0006
-

2008
-
01
-
28

4

The Business Case


The business cases is based two advantages:


One client instead of 4
-
5 clients


Higher productivity


1 minute saved per case equals 30 extra resources

DK

SE

NO

FI

ESB

...

Branches

CC

BPM

Clients

internet

Intranet

Stock

CMS

Teller

PSD

A & A

PR0006
-

2008
-
01
-
28

5

The Requirements


Business requirements


Provide process support


Show/hold all functionality and information in one place


Seamlessly integration between the functional areas


Data re
-
use


External peripherals


High usability


Follow the OS


Standard keyboard navigation, icon, help, drag & drop


High performance


IT/Project requirements



Parallel development


No hard decencies to the other projects


Different release dates for the a functional area (projects)


Different dependencies to the back
-
end


Nordea is a bank,
-

not a major IT product company


Mature and well tested framework


Go out and buy the funtionality

PR0006
-

2008
-
01
-
28

6

The Process


Project started in 2006 with an evaluation


Several different frameworks were evaluated


Portal based


Eclipse RCP


NetBeans Platform


Several Eclipse RCP frameworks were evaluated


Major part of the evaluation was a fully functional prototype


Access to ”real” data


Divided into functional areas as a number of independent plug
-
ins

Now

Start (early 2006)

Business req

Evaluation

Platform components

Prototyping/testing

First project

Decision (late 2007)

PR0006
-

2008
-
01
-
28

7

Nordea Banking Desktop (prototype)

PR0006
-

2008
-
01
-
28

8

Main Idea behind Application


One primary window


the ”banking desktop” with access to all primary
input sources


Secure mail received via home banking


Activities forwarded by other clerks or created by a BPE


Meetings created by other clerks on your behalf


Perspectives used for each functional area:


Mail


Search


News


General information such as account rates, product details


A secondary window for each ”open” customer


Perspectives for each type of engagement


Ordinary accounts, loans, credit cards, etc


Pensions


Insurences


End
-
users can work on many concurrent tasks


but only one per
customer


End
-
users are often interrupted by other work or phone calls

PR0006
-

2008
-
01
-
28

9

Lesson 1: All End
-
Users are not Engineers


Not an obvious lesson!


The end
-
users of an entreprise application can be divided into
two groups


The specialists


often a very small group of the organisation


Very much like engineers in the mindset


The rest (

)


normally 95% of the end
-
users


Sometimes no formal education


e.g. in tele
-
marketing










Our Solution:


Avoid all workbench configuration

The specialists

The ”ordinary” users

Work controlled by

Creativity


often very few
formalized processes

Processes


often based
on law

Number of end
-
users

Few

Many

Task lengh

1
-
5 days

10
-
60 minutes

”Mindset”

Somewhat anacistic

Very diciplined

Need for workbench
configuration

Like to configure
“everything”

Like the same desktop
every time

PR0006
-

2008
-
01
-
28

10

Lesson 2: All windows are not equal


The content of workbench windows can differ a lot


Our application contained four types of windows:


“Banking Desktop” window


“Customer” windows


“Search” window


“Development” window


Different content on different windows


It is very important that the data for different customers is not
mixed on the same window


Closing the “banking desktop” windows, closes the application



Our Solution:


Simple parameterization of workbench advisors


Re
-
creation of windows not trivial

PR0006
-

2008
-
01
-
28

11

Lesson 3: Editors are no good


Eclipse uses two different types of workbench parts:


Editors


Has state and a built
-
in life
-
cycle management


Menu and toolbar merged with top
-
level menu and tools


Is put in a designated ”editor area” that can only contain editors


Views


Has no state (only configuration)


Has private menu and toolbar


Is put in ”view stacks” that can only contain views


Editors and views cannot be combined in a single stack in a window!


Editors cannot be restricted to a specific perspective



In the banking desktop, it has been impossible to explain how the
above can be used in a consistent manner



Our Solution:


We decided to not use editors at all!


Happily, the editor life
-
cycle management can be emulated in views

PR0006
-

2008
-
01
-
28

12

Lesson 4: Views are only a little better


Views have their own problems though!


The menu and toolbar of a view is part of the view itself


All usability tests performed with the prototype (50 persons tested)
showed the view
-
local toolbar and menu has always ignored!


If is not possible to limit the “Show View…” command to only present a
limited set of views based on the current window and perspective


E.g. a specific view


representing a specific type of pension


should
only be presented if relevant for the customer



Our solution:


Add all view
-
local menu and toolbar actions to the main menu and
toolbar as well


We might completely remove the view
-
local actions in the future if
not used


Disable the “Show View…” command


and create all relevant views
when a customer window is shown

PR0006
-

2008
-
01
-
28

13

Lesson 5: Update must be dynamic


When problems are detected in the application, it must be possible to
provide fixes to all users


if not immediately, then very fast


Updates should be pushed


End
-
users must be able to choose when to update



Our Solution:


Simple use of the update manager


Looking forward to see if Eclipse Provisioning Project (p2) will help
on the performance

PR0006
-

2008
-
01
-
28

14

Lesson 6: Security is King


The banking desktop is a banking application, so security is paramount


Individual end
-
users have different


rather fine
-
grained


roles


Controls the access to different functional areas and actions


Can you access to the stock portfolio of a customer?


Can you request a new credit assessment for a customer?


Which types of loans and credit cards can you grant to a
customer?


How big a loan can you grant?


We need to control access to perspectives, views, commands, sections
of views, choices in views, and some sizes (e.g. amounts)



The security department is a separate entity from the development
group


Consequently it is necessary to handle security issues very late in
the development cycle


It is best be able to be able to change role definitions without
invoking the development group itself

PR0006
-

2008
-
01
-
28

15

Lesson 6: Security is King (continued)


How do you ensure all the bundles used in the application are in fact
sanctioned by the security zsars?



Our Solution:


We use activities to control access to most UI “things”


Safe as long as you keep from certain built
-
in actions such as
“Show view” and “Show perspective”


Declarations put in separate plug
-
ins


We use signing and MD5 checksums to protect the application


The solution isn’t exactly simple, so why isn’t there any
framework in place for this?


Side note: it seems there will be something present in 3.4 on both
accounts

PR0006
-

2008
-
01
-
28

16

Lesson 7: Some frameworks are still missing


During the development two frameworks was identified that could have
helped on the development:


A transformation layer between an EMF model and the WSDL of web
-
services


Support for screen
-
flows and processes in views

PR0006
-

2008
-
01
-
28

17

About Me


Founder and Owner of The RCP Company



20 years of experience in system development in major
companies


Regnecentralen (now ICL)


Digital (now HP)


Anritsu (previously NetTest)


9 years experience as the Systems Architect of an 20+ MLoC
project


5 years of experience with Eclipse and Eclipse RCP



Add
-
in Provider Member of the Eclipse Foundation


Chairman of Eclipse.dk