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.
17
PR0006 - 2008-01-28 Redistribution and other use of this material is covered by EPL. 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.
Transcript
PR0006 - 2008-01-28
Redistribution and other use of this material is covered by EPL.
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
inte
rnet
Intr
an
et
Sto
ck
CM
S
Telle
r
PS
D
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
NowStart (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
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 byCreativity – 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
