refactoring j2ee application for a jbi-based esb

13th IEEE International EDOC Enterprise Computing Conference

A division of Data Access Technologies, Inc.

Refactoring J2EE Applications for a JBI-based ESB: A Case StudyWen Zhu & Walt Melo

4 Sept 2009

Model Driven Solutions

Background

• Work was performed at a large US federal agency that acts as an intermediary in the federal supply chain

• Model Driven Solutions is a leading provider of professional services and products that leverage Enterprise Service Oriented Architecture (SOA), Model Driven Architecture (MDA) and the Semantic Web techniques and standards.

4 Sept 2009


Agenda

• Motivation

• Technology Background

• Case Study

• Future Work

4 Sept 2009


Motivation: Address Business and Technical Challenges

• Business Challenges

– Improve the way its Suppliers, Vendors, and Consumers publish and discover services

– Enhance Enterprise Architecture Maturity

– Improve SOA Governance to better manage its service portfolio

– Respond better and faster to change

– Improve the enforcement of government policies

– Low TCO and High ROI

• Technical Challenges – Improve integration of new services

and legacy applications

– Improve the visibility of planned and existing services

– Better manage the impact of change

– Improve the life-cycle management of SOA assets, e.g., service descriptions

– Enhance its understanding of all its services

• Purpose and behavior / Business processes

• Service level agreements

• Dependencies

4 Sept 2009


Agency SOA Reference Architecture

Motivation: Alignment with Agency’s SOA Version

OASIS

SOA-RM

Conceptual Reference Architecture

Concrete Reference Architecture Platform

Service Oriented Architecture Implementations

Service Interaction Requirements

Web Service Interaction Profile

Identity Management

Authentication and Authentication

Message Integrity

Message Confidentially

Message Addressing

Reliability

Transaction Support

Service Metadata

Registry

Service Modeling

Service Contract

Service Policy

Service Collaboration

ESB

JBI

BPMS

Our Focus

4 Sept 2009


Agenda

• Motivation


• Case Study

• Future Works

4 Sept 2009


Java Business Integration (JBI)

• JBI– Defined with in Java Community Process (JCP)

as JSR 208

– JBI Specification 1.0 published in 2005

– Standard basis for a Java EE based ESB

• ESB– A pattern of middleware that unifies and connects

services, applications and resources

• SOA– An architectural style for a community of

providers and consumers of services to achieve mutual value

SOA

ESB

JBI

Is a Standard for

Is an Architectural Pattern for

4 Sept 2009


Java Business Integration (JBI)

source: Apache

• Apache ServiceMix– Deployed: IONA Fuse ESB Version 3.3.1.1

• OpenESB– Deployed: Sun Java Application Server 9.1 Update 2

http://www.apache.org/

4 Sept 2009


Supply Chain

Customer

Other Agency

Why JBI?

• Reusability

• Interoperability / Portability

The Agency

ESB

Services

Service Service

Service

Vendor

ESB

Services

Supplier

ESB

Services

ESB

Service

Services

Services

Services

Services

NMR

Normalized Message Router

NMRFederation Federation

Service Services

4 Sept 2009


Why JBI?

• Reusability

– Reuse existing business service implementation:

• Service engines support standard programming models:

EJB, JAX-WS, XSLT, BPEL, etc.

– Reuse ESB component:

• Standardized component interface: Based on WSDL 2.0

• No vendor lock-in. No open source community lock-in either

• Loosely Coupled Services

– Message oriented: Normalized Message defined by JBI

– Contract driven: Interfaces described using WSDL

• Interoperability

– ESB Federation via standard protocol such as HTTP

• Agility

– Enable continuous business process improvement

• Maintainability

– Metadata driven

JBI Exclusive!

JBI Exclusive!

JBI Exclusive!

•Standard-based approach

•Commercially supported open source

•Foster reuse of FAS solutions and components

•Lower TCO

•Higher ROI

4 Sept 2009


Agenda

• Motivation


• Case Study

• Future Works

4 Sept 2009


Scope

• Focus on Java EE 5 and JBI infrastructures– Open source, open standard based ESB

• Glassfish ESB

• Apache ServiceMix (IONA FUSE ESB)

• Products selected by OCIO

– Refactor existing application (J2EE/WS) for JEE5/JBI

– Open Source JBI platform comparison and assessment

• Outcomes– Principles and patterns for reuse, interoperability, and agility– Alignment with SOA Reference Architecture– Elaborate the relationship of ESB and BPMS

4 Sept 2009


The Federal Agency Under Study

J2EE Enterprise Application

Web Container

As-is J2EE Application

Legacy J2EE Application

Customer

Customer

1. HTML/HTTP

2. SOAP/HTTPS

3.JDBC

4 Sept 2009


Approach: Separating Infrastructure Concerns

Process SOAP Request

Authenticate

Partner

Validate Request

Process Request

Send SOAP Response

Persist Request

Infrastructure Concern: Transport Binding

“Can I receive the request via FTP instead?”

Infrastructure Concern: Security

“Can I use LDAP?”

“Can I share credentials among applications?”

Infrastructure Concern: Transaction Management

“What if I need to access a JMS queue and a database in the same transaction?”

“How do I pass transaction through web service?”

Infrastructure Concern: Reliable Messaging

“I got an HTTP acknowledgement. But did my client really get my response?”

Infrastructure Concern: Metadata and Policy

“How is metadata managed?”

“ Can I publish my QoS requirements in a registry?”

4 Sept 2009


Spectrum for Separation of Concerns

Concerns Handled

at Design Time

Concerns Handled at Runtime

Aspect

Weaving

Dynamic

Proxy

Composite

Applications

Concerns Handled by Application Concerns Handled by

Infrastructure

As-IsTo-Be

• The principle of separation of concerns should guide our refactoring efforts

4 Sept 2009


The Federal Agency Under Study

Refactored JBI Application

Customer

Customer

Application

1. HTML/HTTP

2. SOAP/HTTPS

Policy

Metadata

WSDL

No code changeJBI Composite Application

JBI-based ESB

Service Engine

Transactional

Service

Binding Component

Security

Reliable Messaging

WS Transaction

Service Engine

Transactional

Process Flow

Service Engine

Validation

Logic

Binding Component

File

Email

FTP

3.JDBC

4 Sept 2009


Standards Addressing Infrastructure Concerns

•JBI messaging model is based on abstract WSDL– Transport binding is specified the WSDL

•Web Service Specifications (WS-*) address many QoS concerns– WS-* support can be specified in the WSDL

– WS-* are leveraged in the refactored technical architecture

HTTP

Tra

nsp

ort

Me

ssag

ing

QoS

Me

tada

ta

JMS FTP SMTP

SOAP WS-Addressing

WS-SecurityWS-

ReliableMessagingWS-Transaction WS-Policy

WSDL

4 Sept 2009


Integration of Web Services and ESB

• ESB Relies on Integrated Web Service Stacks for Web Service Support– Exposing HTTP Endpoints

– Host JAX-WS Service Implementations

– Handle QoS Requirements• WS-*

• Web Service Stacks Examples– Metro

– Apache CXF

4 Sept 2009


OpenESB-Metro Integration• Web Service Stack In the Binding Component

• Service Hosted in the Application Server

HTTP Endpoint

Service Implementation

QoS?

source: OpenESB

4 Sept 2009


Glassfish

OpenESB Composite Application

Refactored Application on OpenESB

Oracle

Database

SOAP BC BPEL SE

(Business

Rule Validation)

Java EE SE EJB

Web ServiceJAXWSSOAP

JDBC

Service

Client

4 Sept 2009


ServiceMix-CXF Integration

• Separate Component for Hosting Service Implementation and Exposing Web Service Endpoint

HTTP Endpoint

Service Implementation

QoS?

4 Sept 2009


ServiceMix

Refactored Application on ServiceMix

Oracle

Database

CXF BC JMS BC JMS BC

(Start XA

Transaction)

Service

Client

Web Service

Implementation

POJO

JAXWS

SOAP

JDBC

JMS Queue

JMS/JCA JMS/JCA

POJO

(Business Rule

Validation)

CXF SE

4 Sept 2009


Comparing JBI Containers

Apache ODEBPEL SEBusiness Process

DROOLSBusiness Rules

Apache ActiveMQSun Java MQ (Default)JMS

Through ActiveMQ ClusteringThrough AS and Protocol ClusteringClustering

Registry

Through Apache CXFThrough MetroWeb Service

Through Glassfish ASTransaction Support

WS-Security, WS-Reliable Messaging, WS-Coordination, WS-AtomicTransaction, WS-SecureConverstation

Enterprise Integration Patterns through Camel SE

Support WS-Policy

Integrated with NetBeans IDE

OpenESB 2.0

WS-Policy support is weakPolicy Support

Enterprise Integration Patterns through EIP Engine, CamelEnterprise Integration

WS-Security, WS-NotificationWS-* Support

Fully support Maven and Spring Framework, and interceptorsTooling (Easy of use)

ServiceMix 3.3

Component Ruse

Across ESB

4 Sept 2009


Porting JBI Components

•Standardized component interface: Based on WSDL 2.0

4 Sept 2009


Service Component Architecture (SCA)

• Set of specifications describing a model for building applications and systems using a Service-Oriented Architecture– Specified: Composite Application Structure

– Not specified: Standard Integration Platform

– Evaluation of SCA not in scope of this project

• JBI Perspective– SCA for composite application

– JBI for service mediation

• SCA Perspective– JBI as a SCA binding for Java platform

• Common Approaches– WS-Policy for policy management

Programming Model

http://www.oasis-opencsa.org/

http://www.osoa.org/display/Main

4 Sept 2009


Agenda

• Motivation


• Case Study

• Future Works

4 Sept 2009


Technology Independent

Challenge: Preserving IT Investments in the Face of Technology Changes

•Products Offer Complementary and Overlapping Capabilities

•Numerous Technology Choices

•How do we preserve IT investments?

– Building the Infrastructure

• “Architecture Driven Approach”

– Alternative to the “Product Driven Approach”

– Decomposing SOI capabilities

– Building the Application

• Focusing on business concerns, not technology – the “Model Driven Approach”

BPM Product

ESB Product

BPEL Engine

Security

Business

Activity Modeling

Business Rule EAI

Human TasksProcess

Modeling

Registry Transaction Messaging Transformation

Process

Service

4 Sept 2009


OpenESB

ServiceMix

Model Driven Architecture for “Technology Independent Service”

Business Concerns

Business

Services

Quality of Service

Business Rule

JBossESB

DROOLS?

Schema?

XSLT?

JAX-WS

Business Process

BPEL

Platform

Specific API

Models

TechnicalArchitecture

Platform

ExecutableArtifact

Generates

Specifies

ProvisioningTool

Enterprise Challenges In The Face Of Technology Change:

-Reusability

-Maintainability

-Interoperability

“Architecture Choice for a Changing World”

- Object Management GroupCaptures business concerns using standard tools and notations

Addresses technology concerns such as interoperability, scalability, maintainability and reusability

Generates executable artifacts for a particular technical architecture

http://www.omg.org/

4 Sept 2009


No matter which technology wins, the business requirement remains.

Which technology platform should we choose?

4 Sept 2009


SoaML and Model Driven Architecture (MDA)

Computation Independent Model

Platform Independent Model

Platform Specific Model/Implementation

Open Source eGov Reference

Architecture

As-Is Systems

Stakeholders

Business Drivers

As-Is Business Processes

Support Services Value Chains

Marketing

Development of Government-wide Policy

Shared Services Value Chains

Acquisition

I.T. Services

Financial Management Services

Human Capital Services

Plan and DesignDevelop

and DeliverProvide

After Care

Mission-Critical Value Chain

Support Services Value Chains

Marketing

Development of Government-wide Policy

Shared Services Value Chains

Acquisition

I.T. Services

Financial Management Services

Human Capital Services

Plan and DesignDevelop

and DeliverProvide

After Care

Mission-Critical Value Chain

Value ChainsService ArchitectureInformation Model

Business Context

Service Contract Data Model

<wsdl:porttype>

…

</wsdl:portype>

Web Services Components

Service Architecture

Service Provisioning

Service Interface

4 Sept 2009


SoaML: Modeling Business Services

A services architecture describes how participants work together for a purpose by providing and using

services expressed as service contracts. It is modeled as a UML collaboration.

A participant represents some party that provides and/or consumes

services. Participants may represent people, organizations or systems.

A service contract is the specification of the agreement between providers and consumers of

a service as to what information, products, assets, value and obligations will flow between them. It specifies the service without regard for

realization, capabilities or implementation.

4 Sept 2009


SoaML: Platform Independent Models

A service contract is the specification of the agreement between providers and consumers of a service as to

what information, products, assets, value and obligations will flow between them. It specifies the service without

regard for realization, capabilities or implementation. It is modeled as a UML collaboration.

A service interface defines the interface and responsibilities required for a participant to play a role in a service contract. It is the means for

specifying how a participant is to interact to provide or consume a service according to the

contract. It is modeled as a UML class.

The Information model (not part of of SoaML) specifies the data classes used by the services

4 Sept 2009


Provisioning for Technology Platforms

A components can be deployed on a specific physical tier. A tier is

modeled as a UML node.

Service connections across tiers are modeled

as UML assembly dependencies.

4 Sept 2009


Application Deploy

Platform & Tools (E.G. Eclipse/Netbeans/.NET)

ManualPlatform

ApplicationArtifacts

ModelPro (ModelDriven.org)Open Source MDA Tools

ModelPro™ Project: The Open Source Provisioning Engine

ModelProProvisioning

Engine

Implements

Use

s

SoaML Cartridge for

Java EE

Provisioning Profile

Automates

AutomatedPlatform

Application & IDEArtifacts

UsesUML Tool

Provisioning Model

Users SOAModel

Uses

OMG SoaMLUML Profile

4 Sept 2009


“Thank You”

Wen Zhu

Walt Melo

{wen-z, walt-m}@modeldriven.com

www.modeldriven.com

http://www.modeldriven.com/