.Net, web browsers and Android should be certified Java Kernel platforms

So I saw Why Microsoft Loves Google's Android (via Stefan) and I couldn't help thinking of the complete opposite position.

Imagine something totally different for a second. You're working at a software house making business applications for your users. You want your stuff to run everywhere, so you use Java on the server. Though you need to do some Office hackery, or maybe you wanna do some Windows specific Silverlight stuff or you've bought in to the MS hype about any day now the words really gonna go Rich Client so you better ditch Java and do .Net or else. So the .Net platform gets more tempting as a development platform to get all the MS crack.

So what do you do? Use Java and .Net and hire both .Net guys and Java guys then deal with rewriting code on both languages/platforms and training your folks on both stuff? Or have two different teams? Or just pick one standard language/platform/IDE etc. The temptation might be to go with more and more .Net - maybe even just .Net. And you know what - thats what MS want! To tempt you with all this Office / Windows / Silverlight crack so you stray from your nice open Java platform to be locked into this Windows / Office monopoly. They want you to leave the Java ecosystem and move over to the dark side.

However there's this thing called IKVM which is awesome - it effectively turns .Net into a Java Platform. Yes you read that right. You can take any Java bytecode and turn it into a normal .Net assembly of IL stuff and it runs like any other .Net thing. With .Net glasses on it looks just like .Net. However with your Java glasses on, its still standard Java code and it looks just like a Java platform. What IKVM does is take Java bytecode and translate it into .Net IL. For years its been able to run ActiveMQ (via Christopher Steen back in 2004!), Tomcat and yes, even Eclipse (think of all that native stuff in there for JFace, SWT).

Indeed with a bit of work (and particularly if Harmony and IKVM got together), .Net could actually get certified as a Java platform! Imagine that for a second. One of the main monopolies trying to tempt developers away from Java to lock them in to their proprietary windows/office platform could actually be a certified Java platform!

What would be really cool is if someone started to build open source APIs to abstract all the Windows / Office stuff using interfaces; so you could deploy on native .Net and use the real MS goodies - but folks could implement those APIs using open source or open alternatives like OpenOffice or Google Docs / Sheet or whatnot. i.e. remove the lock-in and reasons for switching to .Net.

I remember having a bit of a heated discussion with Graham Hamilton on this point at the first Sun Dynamic Language conference; his oppinion was that Java should remain 100% pure and be a single certified platform. I certainly see the value in this.

However another perspective to think of is the developer; and extending the Java platform to as many environments as is possible so that developers never have to leave the Java ecosystem even if they wish to develop on some platform which is not 100% pure and certified to run the "entire Java platform" - e.g. say you don't need AWT, Swing, RMI and CORBA. (Though now I work for IONA I now realise - CORBA rocks! :-)

As a developer in the Java platform ecosystem, its awesome to be able to use a Java IDE and tooling (with other languages for the JVM too like Groovy & Ruby etc) then deploy that same Java code on any certified Java platform plus these other huge platforms:-

• .Net via IKVM which also means inside Office / WCF etc
  
• inside any modern web browser without a JVM via JavaScript using GWT
• as a C library using gcj so folks in unix/c land can use your stuff
• on a mobile phone via Android on a platform optimised for phones
  

In each case today, these different platforms are huge and extremely useful. They extend the reach of the Java ecosystem (basically the bytecode) to run all over the place and avoid lock in by folks like MS to their proprietary platforms. They extend the reach of what it means to "write once and run everywhere" to more and more places including .Net, JavaScript browsers, mobile phones and shared libraries for C hackers. In each case, they take Java code written to a subset of the Java Platform and translate the code to run on another platform.

However today none of these are certified Java platforms.

Now lets talk a little bit about the "Java Platform"; its got a ton of stuff in there that noone really cares about any more. e.g. AWT / Swing is of no value to any of these 4 platforms I just mentioned. (I personally see GWT as a long term replacement for AWT / Swing / SWT)

The Java ecosystem is huge and diverse. IMHO core of Java (java.lang and java.util) should be separated out and made easily certifiable - say called the Java Kernel to indicate its the core language / VM only and not stuff on top like AWT/Swing/RMI/CORBA (that few folks care about any more).

Then we could say that any web browser with JavaScript, the .Net platform, C libraries and Android & mobile phones are all certified Java Kernel platforms; so there's not really any fragmentation like Richard thinks - and its a win-win for the Java ecosystem, extending the reach of the ecosystem to more and more places and further reducing the chances of fragmenting the Java ecosystems (since its not really a fork as Richard thinks - its just a smaller subset).

So I'm all for different platforms which might not support all of J2SE - but do support java.lang and java.util and the Java bytecodes - and I fail to see how tempting more and more folks to stick inside the Java ecosystem, whether its JRuby on Rails, Grails, Android, GWT or whatnot - is nothing but a good thing for the Java ecosystem and a very bad thing for the MS lock-in strategy.

While I'm on a long ramble - I thought I'd mention another of my long term irritations with this 100% pure approach. The Java platform (or Java Kernel platform :) should have amazing C integration for those rare cases when you really need it. There's a ton of great stuff available in native libraries only thats a total PITA to work with in the Java ecosystem. Platforms like Python, Ruby and .NET are still leagues ahead of the Java ecosystem at working with native libraries and sometimes you really need to. Of course we try to stick to 100% pure when we can but you know, sometimes the real world jumps in and we need to step outside the 100% pure mantra.

So in summary - I salute IKVM, gcj, GWT and Android - I hope more and more people figure out neat ways of expanding the reach so the same Java bytecode can run in more and more places than we previously thought possible.

Prism rocks! (Create desktop apps for web apps)

Many thanks to Dejan who blogged about this - but Prism rocks. I can now use Expose / Tab to switch between Gmail windows and other FireFox/Safari windows. I've been using it for a day so far and am really liking it. I've often got a ton of windows open in safari/firefox and frequently just wanna switch back to GMail.

Changes I'd like to see

• support multiple Prism executables to run concurrently. e.g. GMail, GoogleReader, GCal, JIRA could all be apps
• allow the icons to be easily customized for when switching with TAB or adding things to the dock.

But so far, its looking good!

Update - many thanks to Dave Brondsema who mentioned in the comments that you can have multiple webapps running with custom icons using the provided bundes from http://wiki.mozilla.org/Prism#Bundles
Though I tried them and they didn't wor for me too well on the Mac (I've not upgraded to Leopard yet :)

ActiveMQ webinar archive available

Our previously announced webinar on ActiveMQ is now available on IONA's webinar and screencast archive. You can view it here.

Nicer iPhone URLs for google stuff...

I still prefer reading email via the web client for gmail on my iphone; for fellow iphoners, you might wanna try the optimised gmail client for mobiles. There's also a nice Google Reader specialised for mobile browsers.

More thoughts on RESTful Message Queues

Just a small follow up on my previous Pure RESTful API to ActiveMQ via AtomPub. AtomPub rocks and all - I was thinking whats the easiest possible RESTful client to subscribe to a message queue.

GET queues/foo.bar?user=myUniqueId&timeout=5000

This would activate my subscription to the queue foo.bar (or help to keep it alive) and return my own list of messages as an Atom feed that I am allowed to view and DELETE when I have consumed them.

This operation is idempotent and would work great with proxies and caches (assuming the right HTTP headers / ETags stuff) letting clients to keep GETing as often as they like. Though if you don't use the subscription for period of time, your subscription can go stale and timeout; any messages in your message collection could be removed.

The slightly smelly thing here is we need to either use cookies (such as for HTTP session handling with servlets) or use a custom session ID header in the URL to uniquely differentiate the subscriptions. Anyone got a better idea?

I guess we could demand that clients PUT/POST to get a new Location URL on which to GET their subscriptions; but this would require a custom REST client.

Feedback on my Camel talk at the IJTC conference

Thanks to John for the great feedback on my Camel talk (and other talks too). I started to write a huge reply and figured I'd post it here instead then link to it as its easier to reply to different parts.

Camel itself is not an ESB per-se, it is a component of an ESB

Agreed. The idea is Camel does the routing and Enterprise Integration Patterns - you can then use it inside a web service stack like Apache CXF, a message broker like Apache ActiveMQ or an ESB like Apache ServiceMix

1. One of the key messages that came out of the session was how Java-centric the Camel solution is - Strachan went so far as to articulate the view that coding in XML was a fundamentally bad idea.

Maybe being the author of Jelly and hating writing XSLT has made me a bit too sensitive to the idea of programming by XML. Quite a few customers I talk with report frustration of too much XML hacking with Spring (which is being addressed in Guice and Spring 2.5). But heck if you like programming in XML be my guest :)

He went on to cast aspersions on graphical tools also. His clear preference was that integration logic should be written in Java. Given that I have worked with highly skilled Java developers for many years now I was not too surprised to hear this - many good developers shy away from tooling, seeing it as compromising their style or the power of the underlying framework - hence the longevity of vi and emacs I suppose.

I didn't mean to cast aspersions on graphical tools; more that pretty much all developers understand Java these days, its pretty universal - whereas most complex graphical tools require a fair amount of learning to get used to them.

Personally I totally prefer writing in Java rather than XML or using visual tooling but one of the main requirements of Camel is that you can configure and specify routes in any way you like - via a graphical IDE (e.g. Cimero) or via XML or Java or Groovy or Ruby or one day hopefully a real DSL. Using XML is quite useful as you can just drop your routing rules inside a spring XML file such as inside the Apache ActiveMQ.

So we're working hard to allow folks to specify routing rules however they like - despite what I prefer :). Irrespective of how you write your routing rules, we can visualise them so anyone can easily understand them.

However it is important to note that all developers are not middleware experts and have no wish to be. Indeed the enterprises they work for want their developers to spend as little time and effort as possible on middleware plumbing. They need and demand tools which will enable them to get at least 80% of patterns done without having to understand the middleware architecture, it's threading model,

Thats one of the main things we're trying to attempt with Camel - letting folks who are not middleware experts easily use the Enterprise Integration Patterns using a single line of Java code - using any transport or component with minimal configuration required.

it's support for configurable expression languages etc.

I find it hard to understand how any tool can be usable by folks without some kind of expression language that they understand - whether its Java or SQL or XPath/XQuery or whatnot. Even a visual query definer is a language that users need to know.

Most people express their requirements in a declarative way- I have data at A that needs to get to B, on it's way I need to perform transformation, validation, logging etc. (indeed the EIP book itself does this) . However Camel has taken a very Java centric approach and I think this increases it's complexity unnecessarily.

We are actually trying to be as declarative as possible - don't let the fact that you can use Java as the DSL confuse you. e.g. here's what you just described in Camel using a single line of Java code...

from(a).
to("xsd:org/cheese/something.xsd").
to("xslt:com/acme/mytransform.xsl").
to("log:com.acme.MyLogger").
to(b);

Its hard to be more concise than that in Java code. But sure - you could use some other language or XML or UI tool etc

2. Camel presents transports as nice-simple looking endpoint URIs in Java. However configuration of these transports may not be as simple as it seems. There appears to me to be a potential disconnection between the Camel processors and the Camel Components in terms of configuration.

You can always configure anything in Camel via Java or Spring; a component, endpoint, processor etc. The URI is just a shorthand notation for configurating things; which tends to work well with endpoints as usually all the smart configuration is in the component.

In the presentation processors use endpoints which can be configured using Spring within Camel. However it would appear that many of the component implementations are inherited from ServiceMix and these properties will need to be set presumably within the ServiceMix container configuration?

Not so - all the components are configured in Spring via Camel. If you want to talk to ServiceMix components and endpoints you can use the NMR and the JBI endpoint.

When you have multiple XML configurations to use a transport then the pretty looking URI is hiding a lot of complexity under the hood.

I hear you. We've tried very hard to make things as easy as is possible with minimal configuration; for example most configuration tends to be on the Component rather than the Endpoint. But you can configure things however you like in Java code or Guice or Spring.

3. Some of the pattern implementations look a little short on credibility - take the aggregator pattern for example the "aggregator" pattern does not seem to have the concept of a store - so in essence one must have access to all of the messages which require aggregation or must hold aggregations in memory for the configurable timeout period. This will clearly not work in a scalable way. Likewise as regards clustering - if you are looking to aggregate 2 messages and they turn up on different servers you gotta problem.

You're right I purposely missed out some of the detail on a few slides (such as specifying some kind of persistence store or strategy for aggregator or for idempotent consumer) but that is easily done via a pluggable strategies Spring beans. However just because I missed out some detail on some slides (its kinda hard in an hour to present all the detail in all the patterns as well as the rest of Camel) please don't think that somehow Camel isn't short on capabilities.

To summarise Camel is clearly a worthy set of widgets and they will work for very simple applications without Enterprise requirements.

Ouch :). We've actually lots of customers using Camel today in production with very Enterprise requirements. Apache ActiveMQ 5.0 actually ships fully integrated with Camel so we've tons of users in production using Camel today.

I hope I've managed to straighten out some misunderstandings on Camel; its definitely a great fit for enterprise requirements. Thanks for your great feedback - I'll definitely take it on board on future presentations and try and avoid confusing other folks :).

webcast today on Apache ActiveMQ

Sorry for the really late notice - bad James! - but I'm doing a webinar today on Apache ActiveMQ with my fellow committer Hiram Chirino. Feel free to pop by and join us - or if you're snowed you can catch the recording later on.

my slides on ActiveMQ and Camel from last weeks Dublin Conference

They are not that useful if you missed me talk, as they are low on bullet points and high on pictures :) But if you were there, here are the slides in PDF format...

• ActiveMQ-Dublin07.pdf

• Camel-Dublin07.pdf  
  

a great presentation on REST, JAX-WS and JSR 311

A great presentation from Stefan Tilkov on REST, JAX-WS and JSR 311; highly recommended.

Speaking at the Irish Java Technology Conference on Thursday and Friday

I'll be speaking this week at the Irish Java Technology Conference this week on Thursday and Friday. My talks are

• Enterprise Messaging With Apache ActiveMQ
• Easy Enterprise Integration Patterns with Apache Camel, ActiveMQ and ServiceMix

Do pop along and say hi if you're gonna be in the Dublin area this week.

s3sync rocks!

I finally got off my fat ass and setup an offsite backup of all my photos and other documents on Amazon S3. S3 is very impressive; very quick to setup and get going. I guess I'll find out in a month or so how cheap it really is :) but on paper it does look pretty cheap.

This article was a great overview of how to create backups using s3sync which is a ruby version of rsync which uses Amazon S3 under the covers. Neat! Add a little Anacron and hey presto, incremental online backups on all the macs in my house; and my wife won't kill me for loosing all the pictures of our daughter :).

(Yes I know flickr might be a better online backup for pictures; I just figured I wanted a general purpose backup mechanism that backed up anything I fancy, not just pictures).

Johnny CORBA

In case you'd missed it here's Johnny!

AtomPub services and auto-detecting the schema type of XML based collections & feeds

AtomPub rocks, its an excellent way of building RESTful services that are easy to discover, consume & they avoid the developer having to figure out for themselves a nice RESTful protocol for reliably exposing resources with all operations being idempotent etc. (Most developers miss that bit out :). I like the extra constraints AtomPub adds above REST; less mistakes for us developers to make :)

The content of Atom feeds can be text, XHTML or XML (entries can also link to arbitrary media types too). When using XML for the atom:content, it might be nice to be able to discover the schema up front - which could help tooling / UIs / frameworks.

e.g. from the AtomPub service document when looking at each collection provide an easy way to get the schema document. I've been googling to see if anyone has done such a thing; I've not yet found an obvious answer.

One idea is to use content types; something like

<collection>
<accept>application+xml; type=someSchemaURI</accept>
</collection>

another could be to add a new kind of link to the feed

<feed>
<link rel="content-schema" type="application/relax-ng-compact-syntax" href="/schemas/something.rnc">
...
</feed>

I guess a tool could always just look at the content of the feed and look at the namespaces then do some out of band google search for schemas for those namespaces :) but it might be nice to be able to make it a little easier to auto-detect the schema - particularly as AtomPub has gone to great lengths to make everything else (system, workspace, collections, entries) easily discoverable and navigable.

Anyone else figure out a neat way to expose the schema of the XML inside the content for collections or feeds?

Apache Camel 1.2 Released!

We've recently released Apache Camel 1.2, take it for a ride! The release includes 61 new features, improvements and bug fixes such as...

• Data Format to support pluggable marshalling and unmarshalling of data in various formats like JAXB, XML Beans, Serialization or Artix Data Services (ADS). Having great ADS support allows us to work natively with things like SWIFT, SEPA, FpML, TWIST, ISO 20022, CREST and FIX messages - or any binary, fixed width or delimeted file format.
  
• hugely improved CXF integration for working with JAX-WS and Apache CXF while reusing powerful Camel routing.
• improved support for Asynchronous Processing within components such as for HTTP and SEDA
• improved OSGi support with both component discovery using the OSGi registry and turning Camel into OSGi bundles.
• improved Visualisation
• support for the full WSDL Message Exchange Patterns
• more powerful Bean Integration

New Components

• iBatis for easy integration with JDBC in addition to the JPA component
• StringTemplate for template based services
• Velocity for template based services

GridGain now usable by Apache projects!

Thanks to Nikita and his team the core APIs of GridGain are now Apache Licensed, so we can build software at Apache for GridGain such as plugins in ActiveMQ, Camel or ServiceMix. Cool! BTW ServiceMix now really is top level at http://servicemix.apache.org.