Andi Egloff's Weblog

Podcasts on Fuji and Open ESB from the Jazoon GlassFish Day

Alexis recorded the session I presented at the GlassFish day in Zuerich and split it into 2 GlassFish podcasts. Sound quality is a little crackly in the beginning, it gets a little better after that :)

Episode 13 covers Open ESB v2 and what we're doing with the current production version of this platform (which is included in Java CAPS 6 and will form the basis of GlassFish ESB v2 later this year)

Episode 14 gives a quick introduction to the future platform research we're doing with Project Fuji - including OSGi, JBI and domain specific languages (DSL)

And here is the presentation as a pdf: Open ESB v2, Open ESB.next and Project Fuji

Posted at 07:08PM Jul 15, 2008 by Andreas Egloff in SOA  |  Comments[0]

Open ESB and Fuji go to Jazoon and "JavaOne afterglow"

Next week I'll be showing off Open ESB and Project Fuji in good ol' Switzerland and Belgium. Handy Jazoon is 15 minutes from where I grew up, so I will also get to see old friends and family! And no I'm not calling you "old" :). I also used to live and work in Belgium, so I'll be sure to toast a beer or two to good old times!

GlassFish community day 2008 at Jazoon
It's free, just register. Find the schedule here

Monday June 23rd 2008

When	What	Where	Site
11:00 - 11:45	Open ESB v2, and Open ESB.next, Project Fuji	Arena 7

Wednesday, June 25th 2008

When	What	Where	Site
14:00 - 14:50	Integration Profile for GlassFish v3	Arena 9

Posted at 07:29PM Jun 19, 2008 by Andreas Egloff in Java  |  Comments[2]

Open ESB joins the GlassFish community!

Open ESB and all its sub-projects are now under the GlassFish community! So what does that mean? It means we are sharing the same light weight governance model and strive to achieve or surpass the same level of transparency and community involvement in those projects. Come participate on our mailing lists or contribute to our components!

GlassFish, thanks for having us :)

Posted at 07:13PM Jun 09, 2008 by Andreas Egloff in SOA  |  Comments[0]

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

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[4]

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]

Ajax and Web 2.0 vulnerabilities

As the new world order is forming around AJAX and the (terribly overloaded term) Web 2.0 a lot of new pain points are surfacing or are being amplified. As adoption becomes more wide spread and the applications move out of research labs into serious applications the motivation increases to address these new challenges.

One of these is security of AJAX and Web 2.0; and there is a lot of basic information out there; but is it enough to just give that a glance? Ignorance is only bliss until it bites you.

I personally found that looking at what you're doing purely from a vulnerabilities perspective is an incredible eye opener. And I invite you to take that journey as well, this is the link to a very well written and detailed view into this world of security:

Attacking AJAX Web Applications

It doesn't stop at just covering the basics of attacks at different levels (such as JSON, XML, JavaScript, XMLHttpRequest, XSS etc), it then applies these to an analysis of some popular frameworks includig DWR, GWT and Atlas.

Tags: ajax web2.0 security vulnerabilities XMLHttpRequest JSON JavaScript XSS attack application

Posted at 01:32AM Jan 12, 2007 by Andreas Egloff in Software Architecture  |  Comments[0]

Five things most people don’t know about me

Mark White just got me in a game of blog tag. Ehmm… thanks? Actually unlike a traditional chain letter I must admit I enjoyed the ability to explore my tag ancestor’s replies to “five things most people don’t know about me”, so I feel compelled to participate in this one.

So here are five things most people may not know about me

1. At age 17 a friend and I took trains from Switzerland down to Northern Africa - Morocco. We rented a dirt bike in Marrakesh to travel over the Atlas Mountains and into the Sahara desert. The way we chose Morocco as the destination? It was the furthest south you could go with an InterRail pass - a pass to travel Europe by train.

2. It may not be a big secret that I'm a car nut, but few may know that I can blame my dad for part of it. For example as a learner driver he let me practice on a 1948 Allard L Type, and I enjoy the hands-on experience of driving a 1929 Packard roadster with its unsynchronized gearbox. So you can’t just get me going about what the best driver's car is at the moment - or what parts would get your Evo moving – but I also have a soft spot for vintage cars.

3. As a kid I thought using computers purely for business tasks constituted computer abuse. Not surprisingly I was a big supporter of the Commodore 64/128 and Amiga - which I still own.

4. I was trained as a machine gunner and driver in the Swiss army. At age 16 the government gave me the first fully automatic rifle to take home - and I didn't think it was strange at the time. To take a job in the US (and other countries) I had to apply for leave.

5. In Nepal I learned how to bathe an Elephant in the river without falling off when he lies down

Now on to tag 5 others – you’re “it”: Jean-Francois, Binod, Arun, Harold, Todd

Posted at 09:37AM Jan 05, 2007 by Andreas Egloff in Personal  |  Comments[1]

Inside JBI part I: Clarifying Lifecycles

In this series I would like to give some insights into gotchas and topics that are not immediately obvious when reading the JBI 1.0 (JSR 208) specification. I'm very lucky that I can bug the spec leads Peter and Ron - and architects and leads like Keith Babo and Mark White who work on the RI and project OpenESB when I want to get some background information on JBI. I'd like to pass on some of this information that I have acquired in the last couple of years.

When stop isn't equals stop

In JBI the components and the service unit (SU) deployments both have their own lifecycle - and in just skimming the spec one might easily presume that stop in both has the same implications. It turns out, the service unit stop might be better described as "stop consuming" - that is right, after a SU stop it can still be provisioning services, it just isn't initiating new requests.

This is different than the component "stop", which means that the whole component should stop provisioning AND consuming services.

Here is another item to be aware of: the specification does not perscribe the interaction between the component and the SU lifecycles. The RI (and project OpenESB) does call the equivalently named lifecyle operation on all SUs when the component lifecycle operations are called (e.g. stop on all SUs when the component stop is called), but that is not explicit in the specification.

When implementing the component stop, you may come accross another interesting feature of the delivery channel: there is no way to re-start message delivery once it is closed, and we only get a new delivery channel in the component initialization.

This means you can not use the delivery channel close to implement the component stop: if the user does a stop and subsequent start you could not re-start delivery on this delivery channel, the user would have to completely shutdown the component first. This makes for an interresting time in implementing the component stop; none of these options are optimal and includes approches such as interrupting the deliverychannel or using the accept on the delivery channel with a regular time-out.

With this in mind, here is my wish-list for enhancements I would like to see in future specs:

• SU stop may benefit from a different name that makes it clear that only service consumption is stopped


• That the specification would explicitly declare the relationship between the component and SU lifecycle


• That the delivery channel would have a way to stop and re-start message delivery - separate from the ultimate shutdown

Tags: jbi esb openesb soa

Posted at 11:18PM Jan 04, 2007 by Andreas Egloff in SOA  |  Comments[2]

Usability awareness - and should we share the user's pain?

Ah, my first entry in the usability category.

Being married to a Usability Engineer I'm aware of a lot of exciting items going on in the field, but I'll certainly not pretend to be an expert. I guess I'm in phase 2 of usability awareness: at least I know that I don't know.

I would like to post items I come accross that catch my eye and ideally are thought provoking.

I'll start off with one of my favorite videos, the "we share your pain (WSYP) project". Yes, it's a spoof, but it is a good one.

Watch WSYP on YouTube
Get the WSYP original

Posted at 12:17PM Nov 30, 2006 by Andreas Egloff in Usability  |  Comments[0]

Coding with attitude

Just received this funny link to The Commentator, an automatic comment generator for your code.
Well, funny in the same way Dilbert is funny if you've been there :)

Posted at 11:43AM Nov 30, 2006 by Andreas Egloff in Personal  |  Comments[2]

Non-blocking NIO sockets in the JBI HTTP Binding Component (BC)

I received some questions about the HTTP BC (part of the Java EE SDK Tools Bundle and the project OpenESB) - and what the advantages are of it supporting the processing of request-response and one-way web service invocations without blocking threads.

So I will try to give a little background on the JBI architecture, illustrate what would happen if we did block threads - and last but not least show the advantages of supporting asychronous processing.

The JBI architecture is based on an asynchronous message bus that can be thought of as similar to in-memory JMS queues. The messages are XML based – and the processing of the request and sub-sequent response are completely asynchronous – they will be handled by different threads and there is no need to block a thread anywhere in between.

This allows for an extremely scalable system that is capable of handling a huge number of concurrent requests with a minimum of resources – in an extreme case where it might be tuned for throughput rather than response times for example it could be handling 10’000s of concurrent requests with under 10 threads - environment permitting of course.

Given this architecture, it would not fit well to use an HTTP connector that blocks threads - and doesn’t have an asynchronous API. Some of the implications this would have in the HTTP BC are:

Implications of blocking

Threading

* Threat of resource starvation and dead-lock (if there are recursive calls within services they can easily exhaust the thread pool – and stop the response from getting processed which might let others progress)

Scalability

* The large number of threads needed to scale at all will consume a lot of related memory which will limit the number of threads feasible
* Because the number of requests we can handle is limited by the number of threads we can efficiently use, we are limiting scalability a lot
* Even without taking efficiency and memory into account, the JVM will ultimately limit the number of threads possible at all - and hence concurrent requests

Performance

* More threads means more context switching, hurting performance
* Limiting the number of concurrent requests we can handle means we can’t always fully utilize available CPU or network bandwidth, i.e. we might be “waiting” for a response so we can free a thread and proceed with the next request

Fortunately this does not have to be. The HTTP BC uses the Grizzly NIO framework including the asynchronous request processing (ARP) extensions that is part of the Glassfish application server.

Not blocking threads makes for an excellent match with the JBI architecture and has these implications (Note that the HTTP BC in the appserver 9.0 currently only uses Grizzly on the server side):

Benefits of not blocking

Threading

* Because nothing blocks there is no threat of resource starvation or dead-lock
* As an example 3 threads in the BC could handle any number of concurrent requests (for higher response times we can choose to add more), e.g.
  thread 1 – Handle the incoming traffic (asynchronous Provider), normalize the message, send it to the JBI “queue” (normalized message router)
  thread 2 – Handle messages off the JBI “queue” (normalized message router), send requests via the asynchronous client API
  thread 3 – Handle responses (asynchronous client API listener), send them to the JBI “queue” (normalized message router)

Scalability

* Very limited number of threads, minimizes the memory footprint
* Because the number of concurrent requests we can process is not limited by the number of threads we can realistically use, we can scale to much larger number of concurrent requests

Performance

* Less context switching which might hurt performance
* Never “waiting” for responses to proceed means we can fully utilize available CPU and/or network bandwidth

Scalability and performance are some of the primary selling points for an integration platform - it makes sense for us to make use of the full potential of JBI.

Posted at 06:40PM Nov 28, 2006 by Andreas Egloff in SOA  |  Comments[0]

Comet Basics

There are some very good detailed technical explanations of Comet already, but it seems there is some room for a basic discussion of what it is about, what it is good for – and how it jives with AJAX.

Comet is a "made up" term - so unlike AJAX (Asynchronous JavaScript and XML) this did not originate as an acronym.

If we view AJAX as the ability to do "invisible HTTP requests" behind the scenes via javascript, coupled with some dynamic HTML - then Comet it primarily an extension or variation on how the communication over HTTP is done.

Essentially it allows to "push" or "stream" data to the web client via standard HTTP GETs instead of for example polling for updates at regular intervals.

How can it do this, considering the browser always has to initiate requests?

Well, first imagine that you do an HTTP GET request as with any old AJAX framework. The server gets the request, but instead of responding immediately with nothing if it doesn't have data, it then waits for data to arrive - for example from an event mechanism, JMS or any other asynchronous source. Only once it gets data will it actually write data into the response for the HTTP GET. It also typically does not finish the HTTP GET request at that point, but will continue to wait for further data - and write more to the response when it arrives ("stream").

So that is what is meant when people say Comet will "always keep a connection open" - it may re-establish a connection by sending another HTTP GET request when a previous one is closed for various reasons. This way there is always a "channel" already open for the server to send data to the web client.

At this point your gut may tell you - open connections and waiting sound terribly expensive - does any of this scale? Is it bad for the network or server?

Done right and used right this can be a very efficient way to send events to web clients; in fact, it can save a lot of unnecessary “polling” requests. Not only can it be more efficient, updates will get to the clients quicker (lower latency) than when polling.

The open connection itself primarily costs the server a socket it needs to allocate per client – with associated (“kernel”) memory. What you do *not* want to happen is for the server to block for example a thread per request when it waits for data to arrive – that would be Comet done in a fashion that will not scale well. Instead, use a non-blocking server – for example one that uses Java NIO non-blocking sockets and can deal with the request and the response separately, in an asynchronous fashion.

There are several products on the market already that do this efficiently; and it is moving from more specialized event driven solutions to the main stream web servers too.

For example, my Québécois pal Jeanfrancois just recently added a Comet extension and example to the NIO based http connector “Grizzly” used in the GlassFish application server. This is actually based on the same asynchronous extensions he had added during our work to support non-blocking NIO sockets for Java Business Integration (JBI) (which we presented at a BOF at this year’s JavaOne).

Unlike JBI, some technologies such as Servlets currently have a little catching up to do until such asynchronous, event driven responses are dealt with in a standardized way and fit well.

There is plenty of controversy about the term Comet too; some like to call it “hanging get” – I don’t like that term too much as the “hanging” sounds too much like blocking to me. Others call it the "slow load technique" ("slow" might be a bit misleading) or "long lived HTTP". And if have this feeling that something is odd about the term Comet - yes, Ajax and Comet are both names of cleaning products. Whatever it is called, a Comet style interaction for AJAX is a worthy concept to name. I probably picture more of a meteor shower in considering when and how the data will flow - but hey that’s just me :)

As with AJAX, Comet can be over-done and abused. Care has to be taken to only transfer relevant data at rates that can be digested by the target platform.

For more details also have a look at Alex Russell's original Comet term proposal or Greg Wilkin's white paper on Ajax, Comet and Jetty which does a very nice job of explaining why you want a server that fits this style of interaction well.

Posted at 11:08PM Oct 02, 2006 by Andreas Egloff in Software Architecture  |  Comments[1]