• Save
IJTC   ServiceMix 4
Upcoming SlideShare
Loading in...5
×
 

IJTC ServiceMix 4

on

  • 1,933 views

 

Statistics

Views

Total Views
1,933
Views on SlideShare
1,930
Embed Views
3

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 3

http://www.linkedin.com 2
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • JBI is a Java based standard for building an integration systems by using plug-in components which interoperate through mediated message exchanges. The message exchange model is based on the WSDL 2.0 spec. The figure at the top shows a high level concept of JBI of the plug-in framework. The JBI environment provides interfaces to be used by plug-in components, while the components provides interfaces used by the JBI environment. Components do not interact with each other directly. Instead, as shown in the bottom figure, JBI acts as an intermediary to route messages between components. This separation is the key to decoupling between service providers and consumers, which is one of the goal of service oriented architectures. In addition, it provides a key point for message processing and monitoring. In this WSDL-based, service-oriented model, JBI plug-in components are responsible for providing and consuming services. By providing a service, a component is making available a function or functions that can be consumed by other components (or even itself). Such functions are modeled as WSDL 2.0 operations, which involve the exchange of one or more messages. A set of four WSDL-defined, basic message exchange patterns (MEPs) crisply defines the sequence of messages allowed during execution of an operation. This shared understanding, between consumer and provider components, of the message exchange pattern is the foundation of interoperability of such components in JBI. The services provided by components (if any) are described to JBI by the component, using WSDL 1.1 or 2.0. This provides an abstract, technology-neutral model of services using XML-based message exchanges. WSDL also provides a mechanism for declaring additional service metadata of interest to service consumers and JBI itself. Components can query JBI for the for the WSDL describing available services.
  • This picture describes the architecture of the JBI system. The JBI environment provides deployment, control & monitoring features through JMX based administration tools The Normalized Message Router or NMR, which provides the mediated message exchange infrastructure Components (in white rectangles) Components are divided in two categories: Service Engines (on top) provides business logic and transformation services and also consumes such services. Binding Components provide connectivity to services external to the JBI environment. Service engines and binding components can function as service providers, consumers, or both. Note that the distinction between SEs and BCs is purely pragmatic, but the separation of business logic from communications logic reduces complexity and increases flexibility. The JBI environment, in addition to the messaging system, defines a management structure based on JMX which provides standard mechanisms for: Installing components Managing a component’s life cycle (start / stop) Deploying service artifacts to components JBI components often function as a type of container to which artifacts can be deployed to add new service or provider logic. For example, a service engine that provides XSLT-based transformation services would have XSLT style sheets deployed to it, in order to add new transformation operations. This process of adding such component-specific artifacts to an installed component is called deployment , to distinguish it from component installation. Such an artifact is called a service unit , while collection of deployment artifacts and associated metadata is called a service assembly . The core message exchange concept implements WSDL messaging. Service requests are generated by consumer components, routed by the NMR, and delivered to a provider component. For example, the BPEL SE may generate a request, which happens to be provided by the external service provider connected to the WS-I BC. The NMR will route the request to the WS-I binding. The SE in this case is a service consumer, and the BC a provider.
  • Let’s take a brief look at some lessons we’ve learned in using JBI 1.0. The JBI specification covers several areas including message passing between components, packaging, deployment and installation of JBI artifacts, lifecycle management and more. In our view, the central piece is the concept of Normalized Message Exchanges and the Normalized Message Router. Normalized Exchanges allow different components to interact with each other without any knowledge of each other, and the Normalized Message Router, being the only mean of communications between components, is the key to loose coupling between services. In short, we see JBI 1.0 as the only way to plug in existing third party components. We’ve also learned that normalizing on XML alone can be problematic because handling non-XML messages as attachments to a normalized message is not always easy. The JBI packaging and the JBI classloading architecture was also not flexible enough – and JBI shared libraries are not a good enough answer. Also, creating components is too complex due to restrictions and requirements of the JBI spec. Another problem is related to some Java specification like JAX-WS and JAX-RS which do not fit well inside a JBI world, mainly because they tie the service to the protocol using annotations. JBI strongly Decouples the business logic from the protocol, which is a good thing, but JAX-WS and JAX-RS have a much simpler approach. Many of these lessons have caused ServiceMix 3 to go beyond the specification requirements to provide additional features. Additionally, the ServiceMix 4 design works to accommodate these lessons directly into it’s design and architecture.
  • The ServiceMix 4 architecture is quite different from the ServiceMix 3 architecture. Most notably, the core of ServiceMix 4 is based on OSGi instead of JBI. The reason for this is simple and can be described with a single word – flexibility. As shown by the diagram, ServiceMix 4 can more easily accommodate the integration of various technologies through the OSGi underpinnings and the NMR and JBI simply become one of the supported services. The OSGi implementation used by ServiceMix 4 is Apache Felix, but the goal is to be able to deploy on top of any OSGi container. Using OSGi as the base of the ServiceMix 4 Kernel provides the best runtime platform for Java. The OSGi modularity provides a superior classloading architecture, many container level services and a registry for services and what are known as bundles in OSGi parlance – jar files with enhanced metadata. Now let’s take a closer look at some of these container level services.
  • The ServiceMix 4 architecture is quite different from the ServiceMix 3 architecture. Most notably, the core of ServiceMix 4 is based on OSGi instead of JBI. The reason for this is simple and can be described with a single word – flexibility. As shown by the diagram, ServiceMix 4 can more easily accommodate the integration of various technologies through the OSGi underpinnings and the NMR and JBI simply become one of the supported services. The OSGi implementation used by ServiceMix 4 is Apache Felix, but the goal is to be able to deploy on top of any OSGi container. Using OSGi as the base of the ServiceMix 4 Kernel provides the best runtime platform for Java. The OSGi modularity provides a superior classloading architecture, many container level services and a registry for services and what are known as bundles in OSGi parlance – jar files with enhanced metadata. Now let’s take a closer look at some of these container level services.
  • The ServiceMix 4 architecture is quite different from the ServiceMix 3 architecture. Most notably, the core of ServiceMix 4 is based on OSGi instead of JBI. The reason for this is simple and can be described with a single word – flexibility. As shown by the diagram, ServiceMix 4 can more easily accommodate the integration of various technologies through the OSGi underpinnings and the NMR and JBI simply become one of the supported services. The OSGi implementation used by ServiceMix 4 is Apache Felix, but the goal is to be able to deploy on top of any OSGi container. Using OSGi as the base of the ServiceMix 4 Kernel provides the best runtime platform for Java. The OSGi modularity provides a superior classloading architecture, many container level services and a registry for services and what are known as bundles in OSGi parlance – jar files with enhanced metadata. Now let’s take a closer look at some of these container level services.
  • ServiceMix 4 provides a powerful console in the form of a command line shell for access to the ServiceMix runtime. This command shell is extensible and has the ability to spawn sub-shells such as separate shells for OSGi, for the OSGi bundle repository, for ActiveMQ, for certain utilities, etc. The console also provides remote access via the command line to the ServiceMix runtime. Creating new commands for the console is actually pretty easy as commands are just annotated Java classes. The shell currently supports a command history, pipes and some utility functions like cat and grep which combined together are really helpful when developing or using the ServiceMix Kernel.
  • ServiceMix Kernel comes with a file based deployer to provide advanced deployment capabilities. In addition to being able to hot-deploy OSGi bundles, the deployer can also handle other types of Artifacts, such as JBI artifacts, plain WARs or Spring xml configuration files. The deployer also supports exploded artifacts which is quite handy at development time so that you don’t have to repackage and redeploy your application. Support for non OSGi artifacts is achieved by implementing deployment listeners, registered in the OSGi registry. These deployment listeners also register URL handlers which can be used together with the other URL handlers provided by the Kernel, such as a maven URL handler and an OBR (Object Bunde Repository) to access maven and OBR repositories. For example, you can install a WAR from a maven repository in a single command line in the console. Last, the deployer also support a file based mechanism for OSGi Configuration Admin (a standard OSGi service for storing configuration which can easily be leveraged by spring application) where the configuration can be updated at runtime by simply modifying a given property file. This can be used to change the logging system configuration for example.
  • SerS
  • ServiceMix Kernel provides a simple provisioning system that you can use to easily install and uninstall your applications. Applications are defined using a very simple xml descriptor that contains a list of dependant features, a list of bundles to install and some optional configuration as a map of key value pairs. The bundles allow reusing any url available in ServiceMix Kernel and this enabled JBI artifacts deployment and reuse existing maven repositories. Available applications can be listed, installed and uninstalled in a single command line. ServiceMix Kernel can also be integrated in the operating system as a service, so that the lifecycle of ServiceMix Kernel can be tied to the OS. A few commands are also provided to manage instances (such as creating new instances, starting and stopping instances), but this is still work in progress.
  • The Normalized Message Router (referred to as the NMR) has been reworked to focus on its purpose (message passing between components) and fit nicely into the OSGi environment. The concept of a JBI component does not exist anymore at the NMR level though it is fully supported at the JBI layer level. The main reason is that the concept of endpoint is required to achieve binary compatibility for JBI artifacts, but not as a core concept for the NMR as the NMR really only knows about endpoints. In doing that, there is no packaging requirement beyond what OSGi specifies: any OSGi bundle can be used to impement the component Concept, which is not mainly about registering endpoints is the NMR. This is why we now consider endpoints as first-class citizens in ServiceMix 4. Endpoints are the same than in JBI 1.0, but they now need to implements a really simple interface which consists in two methods: one for injecting the Channel that will be used by the endpoint to communicate with the NMR, and another one to receive message exchanges sent to it. This means that the endpoint will use a push delivery rather than having the component actively poll for messages. The NMR is also available through the provisioning system and thus can be installed very easily on ServiceMix Kernel.
  • ServiceMix 4 supports JBI 1.0 through a layer developped on top of ServiceMix 4 NMR. It simply consists in a few bundles that need to be deployed, but these are provided through the provisioning system and is installed by default in ServiceMix 4. The JBI packaging is supported through the use of ServiceMix Kernel deployer that we’ve seen which also registers a URL handler to be able to install JBI artifacts from OSGi or from the provisioning system. This layer provides an easy migration path from ServiceMix 3.

IJTC   ServiceMix 4 IJTC ServiceMix 4 Presentation Transcript

  • Guillaume Nodet January 2009 ServiceMix
  • About the presenter
    • Guillaume Nodet
      • Joined LogicBlaze in October 2005
      • LogicBlaze acquired by IONA in April 2007
      • IONA acquired by Progress in September 2008
      • PMC Chair of Apache ServiceMix
      • Apache Software Foundation Member
      • PMC member of Apache ActiveMQ, CXF, Geronimo, Ode
      • [email_address]
      • [email_address]
  • Agenda
    • Overview
    • JBI
    • Lessons learned from JBI
    • OSGi
    • ServiceMix Kernel
    • ServiceMix NMR
    • ServiceMix Components
  • Overview / History
    • Began at Codehaus in May 2005
    • Moved into the Apache Incubator in December 2005
    • Graduated as a TLP in September 2007
    • 3.0 version in September 2006
    • 4.0 version in development
  • Overview / Goals
    • ESB based on JBI
    • Services decoupled from the transport
    • Normalized exchanges
    • SOAP is one protocol supported
    • XML centric
    • Use cases: services, mediation, routing, orchestration
  • JBI 1.0: What is JBI ?
    • Integration Systems
    • Plug-in components
    • WSDL message model
    • Decoupling
    • Normalized Message Exchanges
  • JBI 1.0: Architecture
  • Lessons learned from JBI 1.0
    • Normalized Exchange and Messages
    • Normalized Message Router
    • The only way to plug in third party components
    • XML normalization can be a problem
    • Packaging and classloaders not flexible enough
    • Creating components is not easy
    • Not always the best fit for a given technology API
  • ServiceMix 4 architecture
  • OSGi Alliance
    • Formerly known as the Open Services Gateway Initiative
    • Industry consortium
    • Defines OSGi Service Platform
      • Framework specification for hosting dynamically downloadable services
      • Standard service specifications
    • Several expert groups define the specifications
      • Core Platform Expert Group (CPEG) - framework
      • Mobile Expert Group (MEG) - mobile telephony
      • Vehicle Expert Group (VEG) - automobile Enterprise
      • Expert Group (EEG) - enterprise issues
  • OSGi Architecture Overview
  • OSGi Framework (1/2)
    • Component-oriented framework
      • Bundles (i.e., modules/components)
      • Package sharing and version management
      • Life-cycle management and notification
    • Service-oriented architecture
      • Publish/find/bind intra-VM service model
    • Open remote management architecture
      • No prescribed policy or protocol
  • OSGi Framework (2/2)
    • Runs multiple applications and services
    • Single VM instance
    • Separate class loader per bundle
      • Class loader graph
      • Independent namespaces
      • Class sharing at the Java package level
    • Java Permissions to secure framework
    • Explicitly considers dynamic scenarios Run-time install, update, and uninstall of bundles
  • OSGi Framework layering
  • OSGi Momemtum
    • OSGi technology has moved beyond original target domain
    • Initial success story was Eclipse RCP (three years ago)
    • More recent success stories in enterprise scenarios
      • IBM, Spring, BEA, Oracle, Jboss, Sun …
  • ServiceMix 4 architecture
  • ServiceMix Kernel
    • Apache ServiceMix Kernel is a small OSGi based runtime which provides a lightweight container onto which various components and applications can be deployed.
  • ServiceMix Kernel: Console
    • Powerful command line shell
    • Highly extensible
    • Ability to spawn sub-shells
    • Provides remote access
  • ServiceMix Kernel: Deployer
    • OSGi bundles
    • JBI artifacts
    • WARs
    • Spring XML configs
    • Exploded archives
    • Monitor configuration files
  • ServiceMix Kernel: Logging
    • Support multiples logging APIs:
      • OSGi, JCL, JDK 1.4, Log4J, Slf4J, Avalon
    • Uses a single back-end logging framework:
      • Log4J
    • Dynamic reconfiguration
      • Using the deployer and a log4j property file
    • Shell integration
      • View last log entries, view last exception, display or change the log levels
  • ServiceMix Kernel: Provisioning and Administration
    • List, install and uninstall applications
    • Reuse of Maven repositories
      • Easy installation / uninstallation of features from Maven remote repositories
    • Easy integration with operating system
      • For basic lifecycle operations
    • Instances management
    • ServiceGrid (from Depot) to easily provision multiple agents
  • ServiceMix NMR
    • NMR as a service
    • No more components
      • Deployment / classloader is delegated to OSGi
    • Bundles as the packaging and extension mechanism
      • Leverages OSGi architecture
    • Endpoints as first-class citizens
      • Endpoint activated when registered in OSGi registry
      • Channel is now on the Endpoint
      • Endpoints use push delivery rather than polling the channel
    • NMR available through the provisioning system
  • ServiceMix 4 and JBI
    • Support provided on top of the NMR
      • A few bundles need to be deployed
      • Available through the provisioning service
    • JBI packaging supported through the deployer or URL hander
    • Easy migration path from ServiceMix 3
  • Example
    • Configuration to expose a JAX-WS service on the NMR and call it using Camel
    < camel:camelContext xmlns = &quot;http://activemq.apache.org/camel/schema/spring&quot; > < route > < from uri = &quot;timer://myTimer?fixedRate=true&amp;period=5000&amp;exchangePattern=InOut&quot; /> < bean ref = &quot;myTransform&quot; method = &quot;transform&quot; /> < to uri = &quot;nmr:{http://cxfcamel.examples.servicemix.apache.org/}MyServicePort&quot; /> < bean ref = &quot;myTransform&quot; method = &quot;display&quot; /> </ route > </ camel:camelContext > < bean id = &quot;myTransform&quot; class = &quot;org.apache.servicemix.examples.cxfcamel.MyTransform&quot; > < property name = &quot;value&quot; >< value ><![CDATA[ <soap:Envelope … ]]></ value ></ property > </ bean > < jaxws:endpoint id = &quot;helloWorld-nmr&quot; implementor = &quot;org.apache.servicemix.examples.cxfcamel.MyService&quot; address = &quot;nmr:HelloWorld&quot; />
  • Transactions
    • XA transactions
    • Transaction context store on the JBI exchange
    • The NMR is now aware of transactions
    • Transactions are handled by JBI components
  • Clustering
    • ActiveMQ network of brokers
    • ActiveMQ master / slave
    • Failover mechanism at the OSGi container level
  • JBI components
    • Binding Components
      • servicemix-http
      • servicemix-jms
      • servicemix-ftp
      • servicemix-mail
      • servicemix-file
      • servicemix-cxf-bc
    • Service Engines
      • servicemix-bean
      • servicemix-camel
      • servicemix-cxf-se
      • servicemix-drools
      • servicemix-eip
      • servicemix-osworkflow
      • servicemix-quartz
      • servicemix-saxon
      • servicemix-scripting
      • servicemix-validation
      • servicemix-wsn2005
  • FUSE ESB
    • Progress Software branded distribution of Apache ServiceMix
    • FUSE ESB 4.0 available for download
    • Progress provides support, consultancy and training for the FUSE family of products
  •