Andi Egloff's Weblog

Spring DM, Project Fuji and OSGi - thoughts on "three" peas in a pod

Just posted the below blog entry on the aquarium, pointing to the Spring DM support we have in Project Fuji (see the wiki on installing Spring DM framework bundles and the example OSGi bundle)

Sujit has published a blog entry showing a nice example of how to easily leverage Spring DM within OpenESB v3 / Project Fuji; both to either expose a service, or to call existing services on the "bus". The "bus" (a.k.a. normalized message router) adds the option of a message based, loosely coupled and asynchronous contract to an OSGi environment such as Felix or GlassFish v3. The simple API mechanism allows the (interface centric) OSGi services to implement and invoke message based services. Fuji then includes a host of advanced constructs, including the ability to route, transform and augment these messages.

If you're curious about the architecture and design of Project Fuji you might notice that there are no fancy Fuji specific extensions; it just leverages Spring DM's natural abilities to work well with OSGi services. This, as you might have guessed, is by design; Project Fuji not only leverages OSGi to implement it, but it also allows OSGi (and frameworks that build on it) as a programming model.

Now, I have seen the formation of camps on both sides, the "OSGi, it's what's for breakfast - it solves all problems" and the "YAGNI OSGi" sides. As usual, the right answer for your needs typically needs a bit more nuance, and I'll play my typical Swiss role here: OSGi is great for frameworks to give modularity and dynamism, for application programming models you may not need to use it, or not use it directly. And if you do, it probably will increase your productivity if you use a model such as iPojo or Spring DM (or even OSGi DS) on top.

There is no question that adding OSGi to your application programming model increases complexity. OSGi is an "exact science", meaning that if you know it and apply it correctly, it will do exactly what you want. If you don't have time to dive into the details, maybe your needs are simple, maybe you're rapidly prototyping, it can get in your way very quickly.

I think where a lot of rhetoric falls short is in not distinguishing between use of OSGi in the application development model; and the use of it in an underlying framework. Let's take GlassFish v3 or even Project Fuji as examples: just because it is built using OSGi, it doesn't mean you're forced to develop your applications with it. You can continue to develop Java EE apps "as is", you can write simple POJOs, JRuby, you name it; it's just that the containers that load your code now are more modular and dynamic.

Posted at 12:00PM Oct 05, 2009 by Andreas Egloff in Software Architecture  |  Comments[0]

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]

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]

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]

What's in a Buzzword?

Ahhh, a virgin blog. Let's get to it.

I just had an interesting exchange that might have me re-consider my allergies to buzzwords.

It all started innocent enough as I called another architecture meeting where I was discussing the use of Comet and AJAX. After a few explanations and examples the leads seemed happy and excited about the match to their needs.

What is so thought provoking about this? Well, I had a very similar discussion nearly 3 years ago. There I was in a room with very accomplished developers, architects, book authors on all kinds of web and java topics - and I mostly got blank stares at the explanation of how we could essentially achieve "push" for events to our web GUI. I can't read minds, but I would bet if they didn't know me beforehand some of them would have thought this guy is nuts; everyone knows you don't push to web apps.

Now I might be giving a bit too much credit to the terms themselves, but it does seem that some of them help to understand, categorize, communicate - and propagate ideas. The other part probably is that there is more infrastructure support - and more applications of the idea, but ultimately I think the "hype" about a little acronym AJAX and (what I consider an extension of that idea) Comet pushed these long-standing ideas into the limelight.

A lot of buzzwords will over-sell and under-deliver, but in time the true colors typically start to show – and apparently there is an upside to that hype too.

Posted at 03:48PM Oct 02, 2006 by Andreas Egloff in Software Architecture  |  Comments[0]