Andi Egloff's Weblog

Fuji GUI sneak peek: Fingers too tired to type DSLs?
How about Enterprise Integration in a browser?

The last few weeks we've been showing how easy it can be to compose services and route messages to create integration applications with the domain specific language in Project Fuji, check out the original Fuji screencast if you haven't already.

The natural question that came up regularly after showing the demo was: are you working on any visual tooling on top of the DSL? Well, the answer is a resounding YES; one goal of keeping the artifacts simple to start with is that adding tooling on top is much simpler.

I've been working with Kirill in St. Petersburg to experiment with web based tooling for Fuji. So here is a little sneak peek screencast showing how to build the same scenario as in the Fuji screencast using visual tools in a browser.

Hot off the developer's desk, so no fancy voice overs yet :) but I think it speaks for itself.

The technologies used? It's just CSS layers and canvases, no plug-ins to install. We're still working on integrating this with the OSGi and JBI based Fuji runtime; so stay tuned! Also remember that whilst the demo shows an RSS feed, we have over 30 adapters and containers already that can be leveraged, ranging from legacy systems to modern protocols. Have ideas of how this can be improved? Join Project Fuji!

Does this mean that we're moving away from full blown IDEs? Not at all, for doing the heavy lifting of writing services a fully featured IDE is the tool of choice; for composing services however and maybe simple scripting a low overhead approach looks promising. Actually I would also like to push some boundaries here to see whether JWebPane could bring the two closer together...

Posted at 11:20PM May 29, 2008 by Andreas Egloff in SOA  |  Comments[3]

Why is OSGi on everyone's tongue
- or why you should take the red pill

In a JBoss blog on "OSGi - The placebo that will rejuvenate this industry (just ask your vendor)" Sacha paints a picture of everyone just following the latest buzz-word and (at least in title) not much substance.

So is that really the end of the story?

Hold on, wouldn't that be a really strange story for Sun which had quite a mixed and turbulent affair with OSGi in the past? And now we (as in Sun) are barrelling ahead with native OSGi support in GlassFish v3 as well as Open ESB with Project Fuji... Doesn't seem to make sense that they'd just change their minds for a cheap thrill of name dropping...

I'll admit it now. before digging into it I was very skeptical of OSGi; not that I didn't like the premise of abolishing classpath hell, but oftentimes enterprise quality features come at a large cost of complexity. Also the worry was if the "API" based services of OSGi would mesh well with the message-based, mediated services architecture we require for our SOA / integration platform with lofty goals and a lot to live up to. Project Fuji is all about looking at every aspect of our platform and making it more approachable and flexible, so if a technology doesn't add enough there is no way I'm going to add it.

Now, I'm completely sold. It turns out the OSGi spec does its core job very well and in a very stable fashion; plus it actually is surprisingly straight forward for our platform to take advantage of without being overly intrusive. In fact to start with it only required one minor enhancement (adding some additional entries in the jar's manifest.mf) to make our existing adapters, containters as well as applications run in OSGi enabled environments.

Also it turns out that the current standard for message based, mediated exchanges - Java Business Integration (JBI) - sits very well on top of OSGi and in fact our experiences so far in Project Fuji indicate that the specs add features to each other that really have the potential to bring out the best in both. We simply made our JBI framework implementation an OSGi bundle which then can listen for bundle deployments it should service..

What we gain from OSGi in Fuji

• Take control of classpath hell - by being very explicit about what "services" (interfaces) to expose from a jar (bundle) and in turn declaring exactly what external services and their versions we consume from other bundles it creates a very robust way of managing dependencies and easily allows for multiple versions without conflct
  
• Sizes to fit your problem. Only installs the containers / adapters needed, no need to add complexity or overhead with parts of the system you don't need
  
• Easy to dynamically add features to the platform. We leverage a whiteboard pattern for example to add interceptors within the message routing.
  
• Trivial to create a stand-alone distribution that can be zipped up and installed anywhere. The well defined dependencies of your application and the OSGi enabled pieces allow us to easily find and package all the required pieces for a given application with one command/click.
  
• Allows us to focus on the real value of the platform and leaves the lower level grunt work of a component model to a very robust solution with multiple implementation choices. The core runtime implementation of Fuji on top of OSGi is currently under 300K!
  
• The ability to safely exchange optimized payload representations (such as POJOs) between loosely coupled services becomes a reality
  
• More deployment options, easy to run on any OSGi enabled runtime, small size allows flexibility to embed even in platforms wtihout OSGi out of the box

And we're only scratching the surface here, we're planning to leverage more features of OSGi!

Some of what OSGi currently gains with Fuji

• Mediated model allows for easily adding platform value-add such as auditing, security, routing features ...
  
• A message based, very loosely coupled service layer can make for more stable production system with lower maintenance; it also meshes well with other SOA systems.
  
• Inherent scalability without explicit coding of a SEDA based architecture; threads are not tied to specific requests, components choose the optimal way to process the messages
  
• Interoperability of any component plugged into this layer; standard contract for exchanging messages without prior knowledge of the provider or consumer
  
• More choice of adapters and containers, from multiple vendors; combined with interoperability this can allow for best of breed in a unified platform
  
• A very productive way of defining routing / message flows between services using common patterns that closely match the problem domain by using the Integration flow language (IFL) - a domain specific language (DSL)

Now also throw in all the capabilities of an application server getting modularized and natively supporting OSGi; as the GlassFish team is doing with GlassFish v3, and Fuji gains even more capabilities it can leverage to add scripting, web container, ejb, comet etc... support; without having to create one huge deployable that you may only use 10% of... (hint: stay tuned for what we're cooking up with GlassFish ESB v3 as well ;) ).

Now with the above said, I don't expect all our users to rush out and learn the deepest ins and outs of OSGi. Just like JBI, I primarily see this as an enabling technology for the platform, only if you want to extend the platform itself would you typically touch it directly. As an example I'd expect users to develop simple scripts or POJOs and for example use Spring DM to consume and provide services; so you inherit the advantages of the platform without necessarily having to explicitly touch the underlying technologies.

Coming back to the original blog I am curious how easy it will be to leverage the OSGi-on-the-side story and "don't use it directly" approach JBoss seems to be talking about so far, I would personally like to see Fuji on top of JBoss with an easy way to natively leverage all it's capabilties in the near future as well :)

Posted at 05:42PM May 21, 2008 by Andreas Egloff in Software Architecture  |  Comments[5]

The power of JBI, OSGi and language oriented programming:
Screencast of Open ESB v3's Project Fuji

Wow! It's been a great week at JavaOne. I'm glad we're getting some great constructive feedback on what we're doing in Open ESB v3 with Project Fuji in making a services and integration platform much more productive and approachable.

Project Fuji is the new core integration stack at the heart of Open ESB v3 and the technlogy preview shows goodies such as a domain specific language (DSL) for integration, a JBI enabled OSGi runtime and simple yet powerful Maven enabled tooling.

We've been demoing the technology preview in our session, demo pods and to anyone who wanted to see it - and I have yet to run into someone who wasn't impressed with how quick and easy it is. Better yet, some excited souls are starting to see and think about what else could make it even more powerful.

You can see the demo for yourself in the screencast Keith recorded during JavaOne - he's using his best announcer voice :)

In a few minutes it shows how to poll from an RSS feed, run it through a JRuby filter, then send results to an instant messaging client as well as to a file.

Personally I find it very satisfying and empowering to be able to realize a scenario like this in minutes in a straight-forward fashion that is close to the way I think about the problem - rather than hours or days and potentially having to figure out how to make the tooling and technologies fit such an integration challenge.

Posted at 08:59PM May 11, 2008 by Andreas Egloff in SOA  |  Comments[6]

JavaOne 2008 - A Crazy Year for Java CAPS and Open ESB!

JavaOne 2008 is nearly upon and we've been very busy bees over the last year!

On top of the job as lead architect for Open ESB I also took on the job of lead architect for Sun Java CAPS 6 (composite application platform suite) which is slated for release this quarter.

This is Sun’s first commercial suite that includes the JBI based Open ESB runtime which brings the full power of this open source community and its partner ecosystem to our commercial offering.

The new service layer Open ESB adds to the suite is fully integrated with the rest of the suite, so it can fully leverage the new powerful annotated JSR 181 pojo model and a wide array of JCA resource adapters (RAs). It truly manages to deliver on an open, standards based platform that can take advantage of the rest of the Sun stack and its powerful features; it uses a standard Netbeans 6 and GlassFish v2 as the IDE and the integration server runtime respectively for example. All that innovation and we managed to make it evolutionary as well! Existing Java CAPS application will continue to run on the new platform.

So what else do we have in store? More Open JBI components are in the pipeline to be released on top of the upcoming release 6.

We’re also looking ahead much further and we’ll be showing off a technology preview of the core stack for Open ESB v3, called Project Fuji.

Stay tuned for a lot more content here and on the Fuji site by JavaOne and swing by our booths in the pavilion. For those interested in what we’re cooking up with Project Fuji I will be giving a technical session with Keith on Wednesday: See you there!

TS-6385 Integration Profile for GlassFish Project v3
Andreas Egloff, Keith Babo
Wednesday May 07, 09:30-10:30
Moscone Center, Esplanade 304/306

Posted at 11:57PM May 03, 2008 by Andreas Egloff in SOA  |  Comments[3]

Sun Campus Invaded!

I went up to the Santa Clara campus a few weeks ago to present some of the cool things we've been working on for JavaOne. To my surprise the campus had been overrun.... by dolphins!

Presumably Sakila and her many cousins checking out her new home...

Just hanging out!

Posted at 09:16AM May 03, 2008 by Andreas Egloff in Sun  |  Comments[0]