FUSE-ESB4 An open-source OSGi based platform for EAI and SOA

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 Extensible to support additional component models like ejbs

Introduction to FUSE-ESB4 dard OSGi container adding very useful features for dealing with OSGi bundles the technology layer provides different set of technologies implementing different component model JBI 1.0 JBI 2.0 JAX-WS JMS Spring JEE JAX-RS Console Logging Deployer Provisioning Admin Spring DM OSGi Kernel

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, Tomcat, OSGi)

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. Security framework based on JAAS

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) Camel: FUSE-ESB can be used as a Camel container: Camel routes can be deployed, started and stopped (http://activemq.apache.org/camel)

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. URL: http://www.osgi.org

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 Preferences.

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 environments

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 during execution

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 It's a sort of SOA in a VM

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 ServiceMix/FUSE-ESB is built on Apache Felix But can be deployed on other OSGi implementations.

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 FUSE-ESB4 and OSGi 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: FUSE-ESB4 and OSGi 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 EAI with FUSE-ESB4 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.

Camel 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: <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 Camel

A Camel route can be deployed: As an OSGi bundle: Camel and FUSE-ESB4 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

Camel and FUSE-ESB4 This can be deployed directly into FUSE-ESB: <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>

Camel and FUSE-ESB4 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 SOA with FUSE-ESB4 CXF

SOA with FUSE-ESB4 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:reference id="myserviceref" interface="com.acme.services.myservice"/ >

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"/> Inside FUSE-ESB4 all this stuff is OSGi enabled

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"> </osgi:service>

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 The component/services can be developed in insulation

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 It's the natural choice when you need a powerful container for very popular Apache projects, like: Camel, CXF and ActiveMQ