Modular Java EE in the Cloud

Post on 25-May-2015

1.729 views 0 download

Tags:

description

Java EE 6 is an awesome platform, but how do you design a system that can evolve for many years in production? And how do we run this stuff in the cloud? Designing a system that can evolve without creating a maintenance nightmare is far from trivial. A service oriented, modular architecture will help a lot to replace parts of a system without breaking others. The only mature modularity approach for Java is OSGi - a framework that enables low-level modularity and services, but you still need APIs to create web applications, use transactions, access data sources etc. Without these APIs you will have a hard time building applications. Unfortunately OSGi and Java EE did not interoperate well in the past; But what if we want modularity in our architecture but also the ease-of-use of Java EE 6? In this university you will: 1. Understand the benefits of a modular code base 2. Learn how to mix OSGi and Java EE 3. Manage modular cloud deployments using Apache ACE ..and of course there will be lots of live coding!

Transcript of Modular Java EE in the Cloud

Modular Java EE in the cloud

A practical guide to mixing java EE and OSGi

Bert ErtmanFellow at Luminis in the NetherlandsJUG Leader for NLJUG and a Java Champion

Paul BakkerArchitect at Luminis Technologies

@bertertman

@pbakkerA presentation for

Trend

Applications tend to grow bigger and

more complex

Agile development and refactoring

have become more common

This leads to a number of challenges :

Maintenance (long term)

VersioningDependency

Management

Deployment

Cloud challenges require non-trivial non-functional requirements

Zero-downtime deploymentsModular deploymentsCustomer specific extensions (SaaS)

Apps are moving to the cloud

Modularityis the answer

But... what exactly is modularity?

Prevent (tight)

coupling

What we learned about OO design in university :

Promote cohesion

coupling

cohesion

How to prevent coupling in a code

base?

How to prevent coupling in a code

base?

interfaces

But how to make sure nobody

accidentally uses implementation

classes?

But how to make sure nobody

accidentally uses implementation

classes?

imp lemen tation

hi di ng

Modules

Ok, but how to create an instance of a hidden

class?

MyInterface myI = new MyImplementation();

Service Lookups

Design time modularity

Divide and conquerForces separation of concernsPrevents spaghetti

The jar file is the unit of

runtime modularity on the Java platform

What about classpath

hell?

Runtime dynamics

Module versioningUpdating single modules

Intra-module dependency management

How to deal with

Wha

t do

we

need

?

design

consequences

High-level enterprise APIs

Architectural focus on

modularity

Runtime dynamic module

framework

Right now, OSGi is the only option

let’s not reinvent the

wheel

OSGi is the de-facto standard module system for Java

OSGi != modularity

What about Jigsaw?

OSGi is the de-facto standard module system for Java

OSGi != modularity

What about Jigsaw?

remember!Modularity is

an architectural principle

OSGi is the de-facto standard module system for Java

OSGi != modularity

What about Jigsaw?

remember!Modularity is

an architectural principle

Modularity does not come for free with a

framework

Demo

OSGi vs. Java EE

Java EE:high level

APIs

OSGi vs. Java EE : opposite ends?

OSGi:low-level, mix

and match yourself

Java EE:high level

APIs

OSGi vs. Java EE : opposite ends?

OSGi:low-level, mix

and match yourself

They don’t have to be either / or

How? - 3 options

OSGi a la carte

#3Hybrid solution

using an injection bridge

OSGi as core

architecture with

EE APIs published

as services

#1#2

Option 1 - OSGi in Java EE App Servers

Java EE APIs available from within bundles

OSGi bundles as

your core

programming

model

use app server capabilities like clustering, data

sources, etc.

the (near) future!

Web Application Bundle (WAB)

WAR with a manifest

Easy registration of Servlets

and JAX-RS components

Enterprise OSGi

standard

Web Application Bundle (WAB)

/myweb/index.html/myweb/agenda

manifest.mf

Bundle-Name: agenda.web.ui

Web-ContextPath: /myweb

Import-Package: javax.servlet

mywab.jar

META-INF/manifest.mfindex.htmlWEB-INF/classes/MyResource.classWEB-INF/faces-config.xmlWEB-INF/web.xml

EJB Bundles

Not a standard yet!

Publish EJBs as OSGi services

Use transactions and JPA like you normally would

EJB Bundles

manifest.mf

Export-EJB: ALL

Bundle-Name: agenda.storage.ejb

Use CDI within

bundles

OSGi CDI integration

Prototyped in WELD

RFP 146

Use CDI to produce / consume services

How are the app servers doing?

App server Deploy bundles

WAB support EJB/JPA support

GlassfishWebSphereWebLogicJBoss AS

Option 2 : Hybrid solution

Best of both worlds?

Your app is effectively split into two parts:‘Adminstrative’ enterprise part -> Java EE‘Dynamic’ part where services can be replaced without downtime -> OSGi

Glue the two together using an ‘injection bridge’

Example

Option 3 - OSGi a la carte

Demo

What about deployment?

What about deployment?

ApacheAce

- demo -

Apache ACE

Wrap up

What have we learned?

You’ve seen the future of enterprise development ;-)Why modularity is important (in the cloud)Practical solution for doing modularity now

Want to try this yourself?

Tomorrow 9.30 amHands-on Lab:

Building Modular Enterprise Applications

Room: BOF 2

Recommended reading

Cloud provisioning

http://ace.apache.org/

Eclipse OSGi pluginhttp://bndtools.org/

That’s ushttp://luminis.eu/

Bert Ertmanbert.ertman@luminis.eu

@BertErtman

Cloud OSGi services

http://www.amdatu.org/

Amdatu

Paul Bakkerpaul.bakker@luminis.eu

@pbakker

Q&A