How Red Hat Middleware technology can simplify your Integration Development

Charles Moulliard
EMEA Partners - 5 to 7 Oct 2015

Who

cmoulliard

Pr. Solution Architect, Fuse Expert, Apache Committer

Blog: http://cmoulliard.github.io

Twitter: @cmoulliard

Email: cmoulliard@redhat.com

Committer on Apache Camel, Karaf, Fabric8, Hawtio … & PMC
Technology evangelist
Mountain Biker, Belgian Beer Fan, Blogger

Agenda

Why integration is so hard & expensive ?
Existing solutions
How can we simplify that ?
Ideal Integration Platform
Wrap Up

Integration is so hard & expensive

Why integration is so hard ?

Many systems to integrate
Many different formats, protocols to support
Many standards, APis, languages to "inter operate" between applications, systems
Team collaboration
Many different business to interface

Why integration is so hard - cont’d

Data model & schemas not managed all
Lack of common vocabulary, grammar between integration actors
Lack of catalogue or registry to publish services, data structure, validation rules
Lack of vision OR strategy to manage common "data model", "services definition" between business units
Multi-disciplinary projects

Dev Ops

Absence of DevOps strategy (reuse some ideas developed through - CD/CI talk)

Why integration is so expensive ?

Every change will impact;
- Testing use cases
- Release Management
- Deployment procedures

Every change will require to measure impact on:
- Existing applicationS
- Business & Data Model /Services related
- Calculate risk & modifications

Existing solutions

Existing solutions

? Add a timeline with solutions

EAI
2005 → JBI & SCA emerging
Centric -→ ESB
BPEL & WebServices
REST & Web2
Distributed -→ Microservice

Centric vision

Centric vision
- XML based (inner conversion from CSV to XML or XML to CSV, …) -→ increase functional & modeling cost
- Central server where the processes are deployed and run (what about incremental updates, …)
- Long process to design/develop due to technology complexity -→ increase dvlpt time & learning curve

Integration & orchestration standards

JBI, SCA
- Proprietary implementation
- Suffer from number of components -→ will require home code (TODO: To be reviewed)
Orchestration engines
- BPEL & WebServices -→ increase learning curve & expertise level, does not fit very well huge volume processing
- Contract(s) & Services (TODO: To be reviewed)
- Not compatible

Dev Impact

Targeted to the Business User (wisiwig tool, BPEL and Web Services …) BUT
- Not for the Developer
- Complex to learn, to be used between by teams or cross projects (TODO: To be reviewed)
- Generated code
- Design & runtime platforms are different -→ Not possible to debug, to test (TODO: To be reviewed)

Slide

Not agile at all due to the usage of the Web Services, XML & XSD schema (or complex spec like WS-Atom, …) everywhere
Imposing to embed the model within the service itself (TODO: To be reviewed)

How can we simplify that ?

How can we simplify Integration Project Dev

Use agile Dev technique (scrum, …)
Adopt a design, develop, test& build "platform"

Slide

No more lock in to "proprietary" solutions

Slide

Open Source & Apache License Model is the way to go (for the reasons that we know)

Slide

Java Integration Framework easy to use

Slide

Microservice architecture
- No more centric vision
- Deployment of integration project as collection of services
- Using OSGI bundle, Docker image or Kubernetes application

Slide

Integration tooling to package, deploy

Slide

CD/CI Strategy for Dev/Ops

Slide

Container agnostic

Slide

Cloud ready

Slide

Cross Technology Support to
- Design complex logic using rules engine,
- Manage long term process using standard BPM
- Distribute workload in an sync/async way
- Manage & govern services
- Report centrally the logs & activities
- Secure endpoints and services …

Ideal Integration Platform

Ideal Integration Platform

Does it exist -→ YES
What is the technology supporting such vision -→ JBoss Fuse, JBoss A-MQ, OpenShift & emerging (Keycloak, ApiMan, Overlord, Hawtio, Fabric8, …)

Slide

Common language, grammar between actors (developer, analyst & architect)
- Correspond to DSL
- Implement EIP Patterns instead of lockin standards
Reduce Dev Time as Functional Integration diagram can be implemented directly by the Developer

Slide

Adopt Opensource Framework implementing EIP Patterns and DSL like Apache Camel
- Benefit to use well establishes patterns & practices
- Reduce functional & technical analysis & Architecture design
- Opensource community power

Slide

Use Java standards when possible (Junit), Logging (SLF4J) & Java EE standards (JPA, JTA, …)
- Reduce dvlpt cost, learning curves as such tehnology are "mastered" by Java Developers

Slide

Adopt Camel Testing model to design Integration Test
- Explain why & motivations
- Can be started, debugged and profiled locally in JBDS (no need to use Java Container)

Slide

Library of Components & Data Format support 95% of the use case without to develop

Slide

Can be extended easily (just 3-4 classes to be implemented to create a new component) + Data Format

Slide

Huge collection of processor/interceptor supporting all the EIP

Slide

Junit & Exception centric

Slide

Exception centric

Slide

Propose microservice architecture model
Split services as collection of camel routes

Slide

Support to separate Service from the model (by adoption a REST proxy layer validating the data outside of the endpoint, …)

Slide

Fuse Container
Docker & kubernetes application

Slide

Manage your services & governance
- Apiman
- Keycloak

Slide

Business Activities
- Overlord or Insight

Slide

Add a pie chart about Red Hat Middleware portfolio + emerging
JBoss Fuse, JBoss A-MQ, Fabric8 v2, Openshift v3, Apiman, Keycloak, …

Questions

questions

Twitter : @cmoulliard

More info
- www.jboss.org/products/fuse.html
- http://www.redhat.com/en/technologies/jboss-middleware