A J2EE Middleware Migration

watermelonroachdaleInternet and Web Development

Jul 30, 2012 (5 years and 2 months ago)

384 views


A J2EE middleware migration


Kristian Schjelderup

Otto Fjøsne

JavaZone 2004
-
09
-
15

2

About us


Otto Fjøsne

(Accenture)


6 years experience from Accenture


Member of ”Global Architecture and Core Technology” (GACT)


Leader of ”Authorized Java Center” in Norway



Kristian Schjelderup (Telenor)


4,5 years of experience from Accenture


2 years of experience from Telenor Networks

JavaZone 2004
-
09
-
15

3

Agenda



Background


Migration


Target architecture


Automatic build


Security


Interoperability issues


Goals not achieved


Results achieved

JavaZone 2004
-
09
-
15

4

Background

JavaZone 2004
-
09
-
15

5

Metro


Middleware platform for the fixed
-
line divisions of Telenor


Networks, Private, Business


Established early 2000


Distributed development model


Core team


HW/SW


Develop framework and guidelines


Projects


Create all business functionality


From 1 to 40 persons, with highly variable experience and knowledge


Origo is the largest project,
about half of the components

JavaZone 2004
-
09
-
15

6

Metro technical


Platform and architecture based on J2EE



Original platform


WebSphere 3.x


Visual Age for Java


IBM RS/6000 SP AIX


MQ Series 5.2


Pre
-
J2EE (J2EE 1.0)


New Platform


WebSphere 5.x


WebSphere Studio Application Developer 5.x


Fujitsu
-
Siemens Prime Power 1500


MQSeries 5.3


J2EE 1.3


JavaZone 2004
-
09
-
15

7

Architecture layers

Metro

Application Layer

System Layer

Connector Layer

Service Layer

Client systems

Back
-
end systems

JavaZone 2004
-
09
-
15

8

Migration

JavaZone 2004
-
09
-
15

9

Background


Business Drivers


IBM’s support for WebSphere 3.x was discontinued


Reduced maintenance costs


Technical Drivers


Maintainability, Quality, Stability, Usability, Performance


Many system owners


System owners have their own budgets and priorities


Maintenance/development mostly done by external consultants


Migrate without disrupting day
-
to
-
day operations


Several of the solutions are vital to the core value chains


Quite a lot of solutions..


JavaZone 2004
-
09
-
15

10

Risk willingness


Window of opportunity


Heavy refactoring in addition to platform upgrade


Broken backwards compatibility


All Java package names were changed


All exception handling changed


New security solution

JavaZone 2004
-
09
-
15

11

Solutions to be migrated

Applikasjonslaget

Tjenestelaget

Systemlaget

Connectorlaget

Eksterne systemer

Client systems

RMI/IIOP

MQ

SOAP

HTTP

JavaZone 2004
-
09
-
15

12


Overall Strategy


Phased migration


Isolated systems first


Prototyping


One step ahead of projects


Provide solutions and examples to upcoming architecture challenges


Information to system owners and developers


Half
-
day information sessions


Overview of what MUST BE done during migration


Estimating guidelines


Tight support of projects during their migration


Resource from the Core Team available to support the projects during the
migration

JavaZone 2004
-
09
-
15

13

Target Architecture

JavaZone 2004
-
09
-
15

14

The KISS Principle



Target audience for architecture


Large number of developers


Highly variable experience


Developer
-
friendly architecture


No fancy tricks

JavaZone 2004
-
09
-
15

15

Maintainability



Leverage J2EE standard services


Core Services


Use standards as far as possible


Leverage open
-
source community efforts


Wrap to simplify (JMS code)


Wrap proprietary APIs to help portability (application server specific APIs)

JavaZone 2004
-
09
-
15

16

Principle Documents



Easy
-
to
-
understand guidelines


Architecture


Core services


Integration patterns


Code examples


QA to ensure principles are followed

JavaZone 2004
-
09
-
15

17

Competency Building



Recommended reading


Set of books/articles developers should be familiar with


Entry criteria for Origo developers


Adapted to migration phase


No questions to be asked without first having understood the “entry
criteria”

JavaZone 2004
-
09
-
15

18

Automatic Build

JavaZone 2004
-
09
-
15

19

Background


Goals


Maintenance
-
free automatic build system


Not thousands of ANT configuration lines


No need for a ”build team”


Easy to use


Enforcement of strict Metro naming conventions


Common file structure across all projects



Possible solution:


Maven

JavaZone 2004
-
09
-
15

20

J2EE Application Structure

Primary goal

To compile and package the Java
code into a J2EE EAR file.


Issue

How should we organize our
source code to achieve a
simplified automatic build system?

JavaZone 2004
-
09
-
15

21

Monolitic File Structure

Lots of Ant code to crush tree

structure into modules.

1 J2EEApp = 1 CVS module = 1 IDE Project

JavaZone 2004
-
09
-
15

22

Module
-
oriented File Structure

Static Ant/Maven code

1 J2EEModule = 1 CVS module = 1 IDE Project

JavaZone 2004
-
09
-
15

23

BluePrints: EJB package strategy 3

J2EE Module

J2EE Components

“Package all related (closely
-
coupled) enterprise

beans for an application in one EJB module. (..)”

JavaZone 2004
-
09
-
15

24

Metro Naming Conventions

Application

Service

System

Connector

Invoice

Core System

Invoice

System

Customer

Invoice

Account

Customer

Customer

DB

ICanal

metro2
-
application
-
icanal
-
web

metro2
-
service
-
customer
-
ejb

metro2
-
system
-
customer
-
ejb

metro2
-
connector
-
invoice
-
conn

CVS module name = WSAD Project name = J2EE Module Name

Base Package Name = com.telenor.metro2.service.customer

= J2EE Module

= J2EE Component

= <prefix>
-
<archlayer>
-
<module>
-
<type>

E.g: metro2
-
service
-
customer
-
ejb

JavaZone 2004
-
09
-
15

25

J2EE Client File

J2EE App

Step 1: Unzip EAR

Step 2: Unzip EAR modules


(to tmp dir)

Step 3a: JAR client, common, ejb


recursive from tmp dir

Step 3b: Exclude *Bean, *Local

JavaZone 2004
-
09
-
15

26

Automatic Build Pattern


”Separate the dynamic build code from the static build code.”

Proposed pattern:

Static code:

Code for making J2EE modules based on a module
-
oriented file structure.

E.g: jar:jar, ejb:ejb, war:war, rar:rar, site:generate and so on.

Dynamic code:

These are mostly configuration files used for deployment, compile
-
time and
run
-
time classpath.

E.g: application.xml, ejb
-
jar.xml, web.xml, rar.xml, manifest.mf (runtime
classpath), and vendor
-
specific deployment and configuration settings.

JavaZone 2004
-
09
-
15

27

Module
-
oriented Development


Issues


Lots of modules to checkout from version control


Solution: Eclipse Team Project Set


Build order of separate source directories


Solution: Maven reactor tag

JavaZone 2004
-
09
-
15

28

Security

JavaZone 2004
-
09
-
15

29

Background


Two custom security solutions


3rd Party security solution for Web Site/URL protection (LDAP)


RDBMS , EJB method + data


Security context as explicit parameter in all interface methods


No use of standard J2EE (declarative) security

JavaZone 2004
-
09
-
15

30

Goals


Consolidation of existing security solutions


Reduced maintenance costs


Leverage standard J2EE Security


Reduced maintenance costs


More secure


Familiar to developers


First step towards SSO


Customer satisfaction


Reduce future cost

JavaZone 2004
-
09
-
15

31

Issues


How to split method authorization and data authorization


Redefined data authorization as business logic


Modeling a cost
-
effective LDAP structure


Users


Groups


Roles


LDAP clustering

JavaZone 2004
-
09
-
15

32

Method and data authorization

WAS

Client

Business

EJB

1) Authorize method access

Interceptor

DD

2) Secured method ?

3) Get required roles

4) Get role
-
group mappings

LDAP

5) Get groups for user and


map to roles

6) Match against required roles

Security

Manager

Back
-

end

Back
-

end

Data Security

EJB

8) Get JAAS Context

9) Authorize resource access based


on business rules

7) Authorize resource


access

10) Execute business logic

JavaZone 2004
-
09
-
15

33

LDAP structure


J2EE Roles


Functional (mostly)


Few



Example


Role 1


Role 2


Role 3


Role 4


Role 5


Role 6



top

groups

categories

Example app

Customers

Employees

Managers

..

..

users

Role 3

Role 4

Role 5

Role 6

Role 2

Role 1

JavaZone 2004
-
09
-
15

34

LDAP clustering

LDAP

LDAP

Replication

WAS

WAS

WAS

Bulk load

Read and update

LDIF

Network Dispatcher

JavaZone 2004
-
09
-
15

35

Interoperability Issues

JavaZone 2004
-
09
-
15

36

WAS 3.x and WAS 5.x


Issues


RMI/IIOP


JNDI lookups, change in name space structure


Securiy context propagation


Marshalling of exceptions


Solutions


Had to upgrade WAS 3.x to latest patch level to support WAS
5.x


Use of “Name space bindings” to provide JNDI interoperability


Session facades on new platform to avoid problem of security
propagation between platforms


Marshalling of exceptions could not be solved without changing the
client JDK version

JavaZone 2004
-
09
-
15

37

Different WAS/WSAD versions


Issues


Incremental updates of WAS broke interoperability


Version number inconcistencies between WAS and WSAD


Solutions


Prototyping and testing for each update


Root causes


JDK versions


SSL and certificates


RMI/IIOP object marshalling

JavaZone 2004
-
09
-
15

38

SOAP from .Net


Issues


Marshalling of Null values between WebSphere and .Net


Solutions


Use stand
-
alone Axis, not WebSphere SOAP engine


Custom marshalling code on .Net client (hack)

JavaZone 2004
-
09
-
15

39

Other platforms


Issue


CSI security interoperability between WebSphere and WebLogic



Solution


Prototyping and testing


Deployment of several pathces from vendors


(Soon to be part of standard products)

JavaZone 2004
-
09
-
15

40

Goals not achieved

JavaZone 2004
-
09
-
15

41

Some sub
-
optimal solutions left


“Stockholm syndrome”


Core resources with QA
-
responsibility working tight with migration projects


End up accepting solution to “help” project reach it’s goal


Lack of resources


QA and re
-
design meetings take time


Large number of projects in parallel


Everyone wanted to migrate :
-
)


JavaZone 2004
-
09
-
15

42

Still no domain model


Project goal was to establish a common domain model


To prepare for future integration work


Time consuming and complex


Architecture work must be done as independent project


Domain modelling must be handled cross
-
enterprise


JavaZone 2004
-
09
-
15

43

Automatic testing


Goal was to have repeatable automatic unit tests for all
solutions


This is still lacking for some solutions


Not a MUST HAVE requirement from the Core Team (should have
been)


JavaZone 2004
-
09
-
15

44

Transaction handling


Many solutions are not using J2EE declarative transaction
handling


Code originally written without J2EE transactions in mind


Handling of failed transactions part of use cases


Potential for simplified code and reduced maintenance costs

JavaZone 2004
-
09
-
15

45

Open Source contributions


Maven payback time


Have not yet contributed our Maven efforts to the community


Plugins to be contributed


Axis WSDL generation and deployment


EAR client JAR generation


WebSphere 5 plugin (contribution to existing code)


JavaZone 2004
-
09
-
15

46

Results achieved

JavaZone 2004
-
09
-
15

47

Modern middleware platform


Latest version of WebSphere


Easy
-
to
-
use architecture and components


Well
-
documented and concise


Consistent architecture across solutions


File system layout


Naming conventions

JavaZone 2004
-
09
-
15

48

Modern build system


Build all “architecture compliant” solutions without
modification


Build system and guidelines follow each other


Reduced complexity for projects


Based on standard Maven


Minimal internal maintenance for Core team


JavaZone 2004
-
09
-
15

49

Standardized security solution



Familiar to developers


Reduced maintenance


Implementation handled by application server vendor

JavaZone 2004
-
09
-
15

50

Reduced maintenance


Reduced code
-
base


Origo code base reduced to half


Correct use of core services


Use of standard “patterns” for coding

JavaZone 2004
-
09
-
15

51

Stability and performance


3
-
8 times better response times


Number of trouble tickets reduced by about 75 %

JavaZone 2004
-
09
-
15

52

Questions ?