FUSE-ESB4
An open-source OSGi based platform for
EAI and SOA
Introduction to FUSE-ESB4
It's a powerful OSGi based multi component container based on ServiceMix4 http://servicemix.apache.org/SMX4/index.html
Fully supported by Progress Software Corporation
http://www.fusesource.com
Based on the same Apache licensing schema: Apache 2 It supports multiple component models:
OSGi bundles JBI artifacts Servlets
Spring Beans
Camel (http://activemq.apache.org/camel) Routes CXF (http://cxf.apache.org/) based webservices
Introduction to FUSE-ESB4
The first layer, the kernel, it's based on a standard OSGi container adding very useful features for dealing with OSGi bundles
On top of the kernel it sits the technology layer, the technology layer provides different set of technologies implementing different component models and allowing different style of development
Kernel
Console Logging Deployer Provisioning Admin Spring DM OSGi
Introduction to FUSE-ESB4
The kernel is a lightweight OSGi based runtime
The following features are added to the standard
ones:
Hot deployment: just copying artifacts on a spefici directory all the supported artifacts are deployed
Dynamic configuration: the system is able to detect and propagate accordingly changes to the configuration files
Logging System: it provides a multi APIs centralized logging back end (JDK 1.4, JCL, SLF4J, Avalon,
Introduction to FUSE-ESB4
Provisioning: it provides powerful mechanisms for provisioning of libraries and/or applications. The application provisioning can be done either locally or remotely
Extensible Shell console: FUSE-ESB4 has a text console with a broad range of commands. Through the console it's possible to manage services, install new applications/bundles and manage their state Remote access: it's possible to access the console remotely either
from another FUSE-ESB instance or a lightweight client. It allows to execute the same commands remotey on top a secure and
encrypted channel.
Introduction to FUSE-ESB
FUSE-ESB4 Architecture: technology layer
The technology layer is a collection of many bundles that collectively provides different component models and supporting technologies:
JBI 1.0: FUSE-ESB can be used as a standard JBI container
Spring: FUSE-ESB allows to just deploy Spring configuration files, it provides also support for the Spring OSGi based APIs (Spring DM)
FUSE-ESB provides JMS support through the integration with ActiveMQ (
http://activemq.apache.org), one or more message brokers can be
deployed inside the container. The shell console provides commands for the message broker administration
JAX-WS: FUSE-ESB provides full support for JAX-WS 2.1 through the integration with CXF (http://cxf.apache.org)
Introduction to OSGi
OSGi stands for “Open Services Gateway initiative”
It was initially focused on the deployment of Java
application into residential gateways and small devices like mobile phones
The OSGi alliance was founded in 1999 to promote wide scale adoption of OSGi technology.
Introduction to OSGi
OSGi is a Java framework built around the concept of “bundle”
A “bundle” is just a JAR with additional meta information put into its MANIFEST
A “bundle” provides Java classes and it can optionally provide services, where a service is just a POJO
A “bundle” can use/import other Java classes exported by other bundles
The OSGi framework provides a sophisticated mechanism for managing dependnecies among bundles exporting classes and bundles importing classes
Introduction to OSGi
The OSGi OSGi Service Platform is comprised of
two parts: the OSGi framework and OSGi
standard services.
The framework is the core of the OSGi platform; it
is the runtime that implements and provides
OSGi functionality:
Dependency management Bundle Lifecycle
The standard services define reusable APIs for
common tasks, such as Logging and
Introduction to OSGi
The OSGi framework is comprised of three layers:
Modularity layer: bundle packaging and dependency management
Lifecycle layer: run-time bundle management and access to the underlying OSGi framework
Service layer: this layer is concerned with interaction and communication among bundles
Introduction to OSGi
The modularity layer defines the bundle concept
A bundle it's a jar file containing all the classes and their related resources
Using specific properties put into the jar's manifest it's possible to specify the class packages a bundle
export and the class packages a bundle import (it depends on)
It's very easy to make a bundle usable as a plain jar, in this way bundles can be also used in non OSGi
Introduction to OSGi
The lifecycle layer defines how bundles are
dynamically installed and managed in the OSGi
framework
Definition of the lifecycle operations: install, update, start, stop, uninstall
The lifecycle layer defines how your bundles gain access to their execution context
The execution context provides a way to interact with the OSGi framework and the facilities it provides
Introduction to OSGi
The service layer
Even if OSGi has been created before the SOA wave, it provides a service oriented framework
It follows the publish, find, and bind interaction pattern of SOA
A bundle can register a servic as an interface and an implementation object with some describing property, to the OSGi registry
A bundle can look up a service from the registry using a querying mechanism
Introduction to OSGi
These are a open source implementations of the OSGi spec. Apache Felix (from Apache Software Foundation)
Distributed under ASL 2.0 http://felix.apache.org/
Equinox (from Eclipse Foundation)
Distributed under the Eclipse License http://eclipse.org/equinox
Knoplerfish (knoplerfish.org)
Distributed under the Knoplerfish License http://knoplerfish.org
FUSE-ESB4 is ultimately a powerful OSGi
container, but:
It's able to deploy other kind of artifacts besides OSGi bundles
Non OSGi deployables are converted into OSGi bundles on the fly:
Spring configuration files JBI deployables
Servlets
The deployer subsystem can be extended for deploying new kind of artifacts, ex. ejbs
FUSE-ESB4 extends the OSGi kernel with powerful
provisioning mechanisms:
Maven URL schema:
It's possible to deploy an artifact directly from a maven repository
Features:
It's possible to describe an application as a set of bundles this is called feature
A feature is a XML deployment descriptor that allows to
deploy/undeploy collectively a set of bundles and recursively a set of features.
FUSE-ESB4 technology layer provides two technologies for developing EAI oriented applications:
A JBI 1.0 framework
FUSE-ESB4 can be used as a plain JBI container
The JBI components are the same regardless you are going to use either FUSE-ESB4 or FUSE-ESB3 (just a pure JBI container)
Camel
It's a powerful mediation library that allows to define
integration flows using XML or a powerful Java domain specific language
It's based on the enterprise integration patterns from the popular book.
Defining Camel integration flows (routes):
Using the DSL:
RouteBuilder builder = new RouteBuilder() { public void configure() {
from("seda:a").choice().when(header("foo") .isEqualTo("bar")).to("seda:b") .when(header("foo").isEqualTo("cheese")) .to("seda:c").otherwise().to("seda:d"); } };
Camel
Using XML:
Camel
<camelContext xmlns="http://activemq.apache.org/camel/schema/spring" > <route> <from uri="activemq:NewOrders"/> <choice> <when> <xpath>/order/product = 'widget'</xpath> <to uri="activemq:Orders.Widgets"/> </when> <when> <xpath>/order/product = 'gadget'</xpath> <to uri="activemq:Orders.Gadgets"/> </when> <otherwise> <to uri="activemq:Orders.Bad"/> </otherwise> </choice> </route> </camelContext>A route in Camel is a flow of messages from a “from” endpoint to one or more “to” endpoints.
An endpoint is described using specific URN schemas:
Camel provides a huge list of different kind of endpoints allowing to connect a route to many different
combinations of protocols/platforms: File, FTP, HTTP, IMAP, POP3, SMTP
JPA, JMS, MSMQ, TCP, UDP, COMETD, etc
See: http://activemq.apache.org/camel/components.html
A Camel route can be deployed: As an OSGi bundle:
Using the DSL, you define the routes and pack everything into an OSGi bundle
Using XML, you define a Spring configuration file and pack it together all the dependency classes into an OSGi bundle
As a Spring configuration file
Camel can be configured using Spring
You define the routes using XML and then you can just deploy the file, this will be converted on the fly into an OSGi bundle
This can be deployed directly into FUSE-ESB:
Camel and FUSE-ESB4
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://activemq.apache.org/camel/schema/osgi" xmlns:osgix="http://www.springframework.org/schema/osgi-compendium"> <osgi:camelContext xmlns="http://activemq.apache.org/camel/schema/spring"> <route> <from uri="timer://myTimer?fixedRate=true&period=2000"/> <to uri="log:ExampleRouter"/> </route> </osgi:camelContext> </beans>
Using Camel inside FUSE-ESB4 provides a powerful platform for developing complex integration platforms:
You can deploy multiple routes as separate bundles allowing activating and managing them separately You can have different versions of the same route
running at the same time (thanks OSGi!)
Camel is JMX instrumented: using any JMX console you can monitor what's going on inside your flows
FUSE-ESB4 technology layer provides two technologies for developing service oriented applications:
Spring DM CXF
In some sense OSGi is already a service oriented platform
The main concepts revolve around the service-oriented publish, find, and bind interaction pattern:
Service providers publish their services into a service registry
Service clients search the registry to find available services to use
OSGi = “SOA in a VM”
Spring DM allows using a configuration based mechanism (XML) for registering Spring Beans as OSGi services and for looking up service references
You can use the Spring dependency injection mechanisms even with OSGi services:
Service Registration
<bean name="MyService" class="com.acme.services.impl.MyServiceImpl" /> <osgi:service id="MyOsgiService" ref="MyService"
interface="com.acme.services.MyServices"> </osgi:service>
Service Lookup
SOA with FUSE-ESB4
OSGi with or without Spring Dm allows the
development of embedded service oriented
application:
The service is used as the functional decomposition unit for describing a complex application/system
A complex application can be well described as a set of service producers and service consumers interacting each other
SOA with FUSE-ESB4
The CXF technology layer inside Fuse-ESB
provides full support for CXF:
http://cxf.apache.org
CXF is a very powerful multiprotocol/multibinding
webservice stack
JAX-WS 2.1 compliant
Different transport protocols: HTTP(S), JMS, CORBA Different binding: SOAP 1.1/1.2, pure XML, JSON
SOA with FUSE-ESB4
CXF is Spring enabled:
Endpoints and proxies can be created and injected using Spring configuration files
A POJO can be accessed remotely just adding some configuration: remoting as an orthogonal concern Inside FUSE-ESB4 all this stuff is OSGi enabled
SOA with FUSE-ESB4
CXF is Spring enabled:
Endpoints and proxies can be created and injected using Spring configuration files
A POJO can be accessed remotely just adding some configuration: remoting as an orthogonal concern:
<jaxws:endpoint id="helloWorld"
implementor="org.apache.servicemix.examples.cxf.HelloWorldImpl" address="/HelloWorld"/>
SOA with FUSE-ESB4
In the webservice world the WSDL is the lingua
franca for specifying the service contract
The contract first approach is considered a good
engineering practice for specifying the service
contracts
FUSE-ESB4 allows using easily the WSDL even
for specifying the interfaces for the OSGi
services:
A service can play the role of an OSGi and/or webservice just by configuration
SOA with FUSE-ESB4
Example:
<bean name="MyService" class="com.acme.services.impl.MyServiceImpl" /> <jaxws:endpoint id="MyServiceEndpoint" implementor="#MyService” address="/MyServicePort"/> <osgi:service id="MyOsgiService" ref="MyService" interface="com.acme.services.MyServices">
SOA with FUSE-ESB4
FUSE-ESB4 provides a powerful platform for
developing service oriented architectures using a
component development approach
The system is described in terms of components exposing specific interfaces
The fact that an interface can be remotely addressable is a matter of configuration
The deployment architecture is decoupled from the development architecture
Conclusions
FUSE-ESB4 contains everything you need for
developing EAI and SOA based applications
using up to date JAVA technologies like:
OSGI, Jax-WS, JMS, JBI
