Project Fuji - The Next Generation of OpenESB Andreas Egloff Lead Architect SOA/BI Sun Microsystems, Inc. Fuji is in active development, features and directions subject to change

Agenda Background Features, features, features Conclusion Architecture Sneak Peek Screencast/Demo

Background

Motivation for Direction of Fuji Popularity of simple, productive solutions > A growing number of developers value high productivity and simplicity over all-encompassing but complex Increase productivity of existing users > Whilst existing GlassFish ESB v2 apps work unchanged Make it highly attractive to OEMs / ISVs > Modular tooling and runtime > Easy configuration of pre-built solutions / mediation Make it relevant to more uses and technologies > Enable web build-out, backbone for hosted and local services etc Innovate!

Fuji Goals Agility + Flexibility + Ease-Of-Use = Productivity

What Properties Make it Interesting? Convention, Configuration, Code... >... In that order for higher productivity Service based through and through > Inherent Scaling without explicit coding > Looser coupling, easier maintenance Grows with the application > Pick-and-choose only the features required, from rapid prototyping to enterprise or internet scale use cases Easy to add mediation > Cross-cutting concerns addressed outside of business code; security, auditing, logging, caching...

What Communities can Benefit? Many frameworks on the Java Platform > Java EE, OSGi, POJO, Spring – use to expose and call services REST and light-weight SOA (WOA) Developers > Leverage Jersey and Fuji to easily get back-end data to web apps SOA Developers, Integration Developers > Contemporary, productive features enrich the SOA story EDA Developers > First-class support for event routing, complex event processing Scripting developers > Leverage with any language on the Java Platform GlassFish community > Leverage the containers and services of GlassFish v3 *

Interesting Features Web-Based Composition

Web Tooling Option Service Composition with EIPs in a Browser

Web UI Features All-in-one interface for service composition > Service Definition > Service Wiring > Configuration > Deployment Extensible (services, templates, patterns) Layered on textual representation (DSL) Version control support > Portability across development environments > Develop services with appropriate tooling

Web UI Advantages No need for a full blown IDE just to (re-)use services “Get started in five minutes” now feasible, no IDE install required Appropriate tooling options for differing roles > Architect composes, developer codes Tooling options for different preferences and skills > A visual view might suit the “casual technologist” > A programmer might prefer editing in textual view, but can still visualize the flows Flexibility for Appliances, OEM / ISV, SaaS / cloud uses

Interesting Features Composition using a DSL (domain specific language)

Composition in an IDE / Text Editor A textual representation of EIPs Goals > Simple, concise syntax > Easy to type and read > Top-down design Generate service templates Concept > Used to declare and configure services, routing > Sets up services and routing at deployment time; NOT interpreted on the fly at runtime "Hello World 1" - Simple routing

Basic Concepts of the DSL Integration Flow Language Output of one filter/stage flows to input of next stage > Similar in concept to Unix Pipes "Hello World 2" - pipes-and-filters

Basic Concepts of the DSL Explicit EIP Constructs "Hello World 3" - adding EIP constructs

Complexity (Sample Scenario) A picture speaks a 1000 Words

Complexity 40 words to compose in the DSL

Domain Specific Language Advantages Designed to enable “Top-down” design Simplicity > Productive even with simple text editor, command line > Syntax highlight, code completion in multiple IDEs (NetBeans, Eclipse today) Extensible Pattern Constructs > Out of the box productivity, users can extend Matches up well with any general purpose language > Attractive to more communities on the Java Platform

Interesting Features Enterprise Integration Patterns

Integration Patterns Patterns as a first-class citizen in the architecture > Popular way to model common solutions > Available both in our visual composition and text (DSL) Existing patterns > Pipes & Filters > Broadcast > Aggregate > Content-Based Router > Scatter-Gather > Composed Message Processor > Message Filter > Split > Wire Tap > Routing Slip > Many more, Extensible...

Message Routing: Scatter-Gather ("all")

Message Routing: Scatter-Gather ("best")

Message Routing: Content-Based Router

Message Routing: Content-Based Router (dynamic) > CBR rules configured at deployment/runtime

Message Routing: Composed Message Processor

Interesting Features Interceptors and Aspects

Aspects in the Messaging Model Aspects can be added/removed/configured at runtime > Aspects are pre-built, configurable interceptors Aspects address cross-cutting concerns for message based Services Out of the box examples > Logging Aspect > Policy Aspect > Coming: Caching, Auditing... Users can write their own interceptors and aspects and enrich the community

Interesting Features Modular and Light Weight

Modularity Framework Core framework is an OSGi bundle Runs on GlassFish v3 and any OSGi R4 framework implementation (Felix, Equinox, Knopflerfish) Microkernel size > ~300 KB More flexibility in partitioning functionality and embedding for given communities and applications

Light Weight in What Way? Light weight in download, runtime footprint > Micro kernel architecture > Size to your needs, add features and components dynamically Light weight in development process > Simplified tooling options, productivity features Light weight to add mediation > Aspects to apply policy, interceptors managed at runtime Light weight in administration and maintenance > Enhanced versioning*, manage routing*

Interesting Features Topology Options

Support for > SOA style > Explicit exposing and calling of remote services > “Federated ESB” option > Transparent if consumer/provider co-lcoated or remote > Distributing the ESB at the messaging (NMR) level > Linking both of (homogenous) clusters* and (heterogeneous) instances > * Once GlassFish v3 releases cluster support Added pluggable distribution mechanism > First implementation uses the GlassFish mechanism – GMS / Project Shoal > Can plug in HTTP, JMS,...

Homogenous Cluster Glassfish Clusters

Federated Clusters or Instances Transparent Service Proxies

Conclusion

Project Fuji is... Revolutionary... > Radically light weight and modular > Simplifies for productivity at every layer > Enriches the GlassFish v3 offering > Capabilities targeted at new communities > Scripting, POJO, Spring, OSGi developers... > Leverage from Web 2.0 applications > REST and Web Oriented Architecture (WOA / ROA) Evolutionary... > Leverages and extends existing component ecosystem > Leverages existing enterprise features >... but enhances and simplifies how they are used

Architecture Sneak Peek

Fuji Architecture

Screencast / Demo

40 Thank You More info, screencasts etc: Andreas Egloff

Backup Slides

Service Composition Top-down design model IFL : Integration Flow Language > Domain-specific Language for Enterprise Integration Web-Based Composition Tool > Drag-and-drop integration

Programmatic Interface Expand the range of languages and frameworks that can interact easily with our platform Dynamic Languages > Scripting the platform > Ruby, Groovy*, JavaScript*, PHP*, etc. POJOs, Spring Framework > Spring Dynamic Modules > Beans consume and provide services

Service Artifacts Simplify user interface to service artifacts Convention, Configuration, Code... >... In that order! Maven used extensively > Quick start with archetypes > Core of tooling is portable across IDEs > NetBeans, Eclipse, IDEA, etc.

Integration Runtime Build on robust core in OpenESB v2 > Same components > V2 applications deploy directly into Fuji Interceptors Distributed Message Bus