Project Fuji (basis for OpenESB v3) Milestone 2 released

Discussions

News: Project Fuji (basis for OpenESB v3) Milestone 2 released

  1. Building on the themes from Fuji Milestone 1 with its simple but powerful way of defining and linking together services and the web based tooling option, the OpenESB community has released Milestone 2 of Project Fuji. Milestone 1 deliberately showed contemporary technologies such as RSS and XMPP, which brought up the question: how does this apply to the more classic integration scenarios? Milestone 2 shows a classic scenario to illustrate how quick and easy it is to solve these with the powerful, but simple to use capabilities in Project Fuji. A Fuji Milestone 2 Screencast is available to quickly gain an understanding of the new capabilities. The Milestone 2 Platform Download consists of a simple jar file, a step-by-step guide is available to show how to run or build the sample application from scratch. Highlights of features in this release:
    • Enhanced support for Enterprise Integration Patterns
      • Split
      • Aggregate
      • Message Filter
    • New interceptor support which allows cross-cutting concerns such as logging, auditing, and security (to name a few) to be addressed in a modular fashion. Services can be enriched with additional functionality without changing the service implementation.
    • Lots and lots of new NetBeans support to make developers more productive. Great new editing features for IFL and service configuration.
    • Introduction of a "proxy" bundle which allows the ESB to extended through a distributed message bus.
    • A new "Reactive Runtime" feature, where the platform detects application changes and automatically refreshes the deployed version of an application with updates.
    • More service types
      • Database
      • SMTP
      • FTP
      • HL7
    • IFL language enhancements
      • Nested route definitions
      • Support for inline and external configuration
      • Added EIP keywords: split, aggregate, filter
    The new Project Fuji portal helps explore and find information on the project, including additional screencasts and documentation on the platform features.
  2. Fuji looks pretty damn impressive! While I have been big fan of ServiceMix movement, I must admit OpenESB/Fuji seem much much better, at least at this abstract level. Integration with NetBeans is awesome. Obvious questions one might ask are: 1) Are we going to see global initiative in the future which will create standard Integration Flow Language (initiative similar to AMQP)? 2) or at least, are we going to see in some future releases of JBI incorporated specification of Integration Flow Engine? Hopefully someone will share insight regarding the second question.
  3. Thanks for the feedback! The plan so far in regards to Integration Flow Language is to grow it in the open source community, making sure it stays highly pragmatic and solves real world use cases. I do think it makes sense eventually to have a standard in this space - whether an official or a defacto standard. But IMO I don't think we should hand over the primary job of defining and testing out what the most productive way is to achieve these goals to a standards commitee at this point, it should be driven by the community. In regards to JBI specification, yes I think from the point of view "can this work in any JBI compliant runtime going forward" the answer will be "yes", but in terms of implementation we're probably coming at it from a slightly different angle. I'll first diverge a little: the IFL can be seen as a way to declare and configure how services interact. In Fuji for example the language is not interpreted at runtime when messages flow through the system, the message flow declared through IFL is used up front to set up all the required services and their connections. So what this means is that as long as the JBI runtimes support the underlying capabilities that IFL uses to link together and configure services you should be able to run an application developed using IFL in any JBI compliant runtime - and it doesn't require an IFL service engine. In other words, the next JBI specification doesn't have to say anything about IFL directly, but specify additional core runtime capabilities such as interceptors which can more easily model enterprise integration patterns. Hope that helps and isn't too confusing. Andi
  4. Thanks for the update Andi. Hopefully we will get more updates on TSS about OpenESB/JBI development efforts in the future. Cheers