The Apache Camel team has always strived to make complex integration challenges as easy as possible connecting pretty much all transports, protocols and middleware together easily using any of the enterprise integration patterns typically in a single line of Java code.
However our users have often said that Java is way too complex to understand. So to tackle that need we're dropping support for Java due to its complexity and instead we're switching to a combination of BPEL, WSDL and RDF XML Syntax instead (with maybe some XSLT too).
We're hopeful that a single XML document with 6 or 7 namespaces along with 2 or 3 spring ones should just about be able to route from one endpoint to another in a similar way to using a line of Java code - but using all the power of the various XML specifications; making it easy to add any WS-* specifications you fancy too!
One downside of this approach is that the XML header to define all the namespaces and their prefixes is about page or so of text but we're hoping a netbeans plugin will be completed soon that just hides the first page of your XML - making development much more agile!
We've also got a signed CLA on file so we can reuse Opera's new face gestures technologies to help typing in all those pointy brackets and XML namespaces; while giving yourself a great face workout at the same time. Agile integration and fitness in one!
More detailed design notes are available here from our new technical architect on the project.
Go Camel! :)
Wednesday, 1 April 2009
Thursday, 19 March 2009
I met James Gosling last night & more on JWebPane
James Gosling was giving a talk at BT on the future of Java (the evening was very well organised by Philip Milne - thanks for the invite & lovely curry! :) - and James is a thoroughly nice chap & much taller than he looks online :)
In the Q&A I asked, if he had a magic wand and could change anything in the Java ecosystem (platform, language etc) what would it be? His answer was getting WebKit into the Java platform via JWebPane! Awesome - go James! Along with closures in the Java language that would be mine too as I've mentioned before. Apparently work is still progressing on JWebPane - so despite the total silence for nearly a year, it may hopefully one day see the light of day. I just hope Sun releases something soon - it doesn't have to be perfect, then we can fix it in open source as a community.
I do wonder if the JWebPane guys have been a bit too ambitious for the first release (e.g. all the stuff about using Java2D and Swing JTextField widgets within a web kit pane etc). Just having a webkit panel which you can communicate with via Java & interact with the DOM via Java would be rocking! The other stuff I'm less sure on how important that is (e.g. the super tight integration of swing widgets with the DOM widgets - just being able to place swing widgets inside the DOM would be fine).
Incidentally I've been meaning to follow up from my previous post on webkit in the JVM. I got alot of great comments and feedback either privately or on the blog. Some were from Swing folks who didn't wanna touch all this new fangled web stuff with DOM/HTML/CSS/JavaScript. Thats fine - if you wanna stick to pure Swing please be my guest I didn't wanna imply we should remove anything from Swing.
For the others, they all pretty much agreed we need awesome browse integration in the JVM - it would open up a massive amount of potential for rich applications which embrace the web but work around the limitations of browsers (networking & security limitations) and above all the biggest issue with developing on the web - dealing with the zillions of ancient crappy browsers. Instead building rich applications on the JVM using a modern embedded webkit wouldn't have those issues & would make creating web apps way more fun :)
Quite a few folks replied with links to existing projects similar in scope to JWebPane which I should just mention...
In the Q&A I asked, if he had a magic wand and could change anything in the Java ecosystem (platform, language etc) what would it be? His answer was getting WebKit into the Java platform via JWebPane! Awesome - go James! Along with closures in the Java language that would be mine too as I've mentioned before. Apparently work is still progressing on JWebPane - so despite the total silence for nearly a year, it may hopefully one day see the light of day. I just hope Sun releases something soon - it doesn't have to be perfect, then we can fix it in open source as a community.
I do wonder if the JWebPane guys have been a bit too ambitious for the first release (e.g. all the stuff about using Java2D and Swing JTextField widgets within a web kit pane etc). Just having a webkit panel which you can communicate with via Java & interact with the DOM via Java would be rocking! The other stuff I'm less sure on how important that is (e.g. the super tight integration of swing widgets with the DOM widgets - just being able to place swing widgets inside the DOM would be fine).
Incidentally I've been meaning to follow up from my previous post on webkit in the JVM. I got alot of great comments and feedback either privately or on the blog. Some were from Swing folks who didn't wanna touch all this new fangled web stuff with DOM/HTML/CSS/JavaScript. Thats fine - if you wanna stick to pure Swing please be my guest I didn't wanna imply we should remove anything from Swing.
For the others, they all pretty much agreed we need awesome browse integration in the JVM - it would open up a massive amount of potential for rich applications which embrace the web but work around the limitations of browsers (networking & security limitations) and above all the biggest issue with developing on the web - dealing with the zillions of ancient crappy browsers. Instead building rich applications on the JVM using a modern embedded webkit wouldn't have those issues & would make creating web apps way more fun :)
Quite a few folks replied with links to existing projects similar in scope to JWebPane which I should just mention...
- JWebPane which hopefully will see the light of day one day, though its been eerily quiet for nearly a year...
- Qt has a WebKit component in its UI library
- SWT has a browser (FireFox) see the changelog and this eclipse con talk
- CB4J bundles Chromium WebKit in a Java widget
- Sage browser
Tuesday, 17 March 2009
JSR 299 (Contexts and Dependency Injection for Java) looks pretty good
I remember looking at an early draft of what used to be called the Web Beans JSR and it kinda looked a bit like 'hey lets try standardize Seam'. It didn't strike me as being too relevant or useful to folks typically using Spring/Guice to build their applications.
However I've just had another look at the lastest draft and its now looking pretty good. The rename to Contexts and Dependency Injection for Java certainly helps.
Dependency Injection is such a cross cutting concern throughout the Java ecosystem - its also a very well understood problem space with a small number of popular implementations. We really should have a set of standard annotations for Dependency Injection above the basics in JSR 250 so we really can write framework agnostic code that can work in more than one DI container. So far JSR 299 is the best effort I've seen to try come up with a standard.
Ironcially the annotations used in JSR 299 are almost exactly the same as those used in Guice 2 (@Produces/@Provides, @Named, @BindingAnnotation/@BindingType etc). Also Spring has started adding more and more annotation based dependency injection support of late; so the various approaches are kinda unifying a little.
So with a bit of effort it should be pretty easy to implement the dependency injection parts of JSR 299 in both Guice and Spring; so then we'd have a real, useful, dependency injection standard working across all the main DI frameworks.
I wonder if the Spring & Guice folks will put petty politics aside and really get behind JSR 299 for the good of the Java ecosystem?
However I've just had another look at the lastest draft and its now looking pretty good. The rename to Contexts and Dependency Injection for Java certainly helps.
Dependency Injection is such a cross cutting concern throughout the Java ecosystem - its also a very well understood problem space with a small number of popular implementations. We really should have a set of standard annotations for Dependency Injection above the basics in JSR 250 so we really can write framework agnostic code that can work in more than one DI container. So far JSR 299 is the best effort I've seen to try come up with a standard.
Ironcially the annotations used in JSR 299 are almost exactly the same as those used in Guice 2 (@Produces/@Provides, @Named, @BindingAnnotation/@BindingType etc). Also Spring has started adding more and more annotation based dependency injection support of late; so the various approaches are kinda unifying a little.
So with a bit of effort it should be pretty easy to implement the dependency injection parts of JSR 299 in both Guice and Spring; so then we'd have a real, useful, dependency injection standard working across all the main DI frameworks.
I wonder if the Spring & Guice folks will put petty politics aside and really get behind JSR 299 for the good of the Java ecosystem?
Wednesday, 18 February 2009
Apache Camel 1.6.0 released - 2.0 not far away!
Both Claus and Jon beat me too it, so being lazy am just gonna link to their posts. You can grab the latest Apache Camel 1.6.0 release with its 169 improvements on top of the 266 improvements from the 1.5 version.
Get it while its hot! Work is progressing well on 2.0 which will hopefully be out soon too! Great work Camel Riders!
Friday, 30 January 2009
How Sun could fix Swing and promote innovation and unification in the UI space
I saw Jonathan's post on Swing 2.0 and it was late, I'd had a nice glass of wine so I fired off a wacky idea on twitter which got some interesting feedback. I'd like to just expand on the background of the idea some more as I'm not so sure it is so wacky an idea afterall. Its feeling more and more like a no brainer and complete win win.
I'm afraid this post is gonna be quite long. (Holy crap - no blogging for ages and then two big posts in a week!) - first some background...
Programming Rich Java Applications Is Sucky
Imagine the scene. You're part of a team of Java developers; you're tasked to write a rich application. It might be a commerical app or some intranet enterprisey thing, or some rich application to improve the user experience of some web app (like the iphone versions of facebook/twitter/gmail etc) - whatever. So what do you do?
You've a mindnumbingly broad choice to choose from - here's just a few options...
Write once and run everywhere - except if your application has any kind of user interface.
This is maybe why so many Java folks like writing server side apps; as the client side in the Java ecosystem is such a mess.
Helping Swing Developers
Lets imagine you pick Swing to develop rich applications. In its day, Swing was a good piece of work by Sun. However that day was in the nineties :)
I've done a fair bit of Swing in my time and worked on Swing projects; in my experience you can spend years trying to tart up a swing app and it still looks - well like Swing. You can get a day of a good web designers time and make any web application look stunning via HTML/CSS/images. It just seems so much easier to hack up HTML/CSS to look great. Just compare some great web 2.0 applications out there to your typical Swing UI. As an end user which would you rather use?
As a developer one of the big PITAs with Swing is layouts, styling and working with images and links. The standard layout managers suck. (GridBagLayout anyone?). Yes I know there's a zillion layout manager implementations out there - all doing different things well with different results & rendering bugs - and which one do you choose?
Generalizing hugely but most of the work that goes into most data entry-ish rich applications is creating loads of screens which are full of text, images, links and some rich widgets with plenty of documentation, popup help, cheat sheets and then laying it all out and styling it nicely. Swing is lousy at these UI basics. Sure its got a good JTable and JTree, something that many a web developer will probably have been envious of at some point or other when hitting gremlins in their JavaScript table/tree - but at laying out forms, dialogs, help screens, documentation and working with links and images - well its kinda sucky.
Swing developers should be using HTML/CSS for this - its great at it. The web browser is the best layout manager we have - and HTML/CSS is the best standard for laying out widgets. With HTML/CSS there's a ton of tooling out there too for viewing/editing/styling. You can then pass the HTML/CSS to your web designer while the Java Swing hacker focusses on the business logic or the complex widgets.
Plus any time you spend hacking HTML/CSS - being a simple, standard text format used inside web browsers means you can reuse your work in web applications as well as rich applications. You don't spend your time hacking up some Swing Java code thats only useful inside a Swing application.
My Proposal
So my proposal is, in Java 7 we integrate WebKit into the JVM. Why WebKit? Well its smaller and easier to integrate than Gecko; Apple chose it for Safari & iTunes and the iPhone and Google chose it for Chrome and Android. If its good enough for a cell phone surely we can fit it into a JDK/JRE for a rich desktop application?
If Sun wanted to get clever, the browser engine could be pluggable; letting folks pick different versions of WebKit or FireFox/Opera/IE - but lets not go there right now - lets just assume a recent WebKit version is baked into the JRE/JDK.
Some would argue it should be optional; but then given the size of the JDK/JRE there's a ton of not-that-useful stuff in there; I'd rather include it by default over loads of whats there :) But then the JDK/JRE is getting more modular right - so lets leave the optional nature of WebKit for when the JDK/JRE is truly modular - right now its huge; so if a cell phone can include it, so can a JDK/JRE :)
Next we have a standard Java API for creating a BrowserPanel which can be hosted inside any AWT/Swing/SWT/JFace based UI. So a browser window becomes a standard embeddable widget in Swing and SWT/JFace/Eclipse. There should also be an API for controlling the browser (loading/saving URLs and interacting with the DOM).
Finally I'd like any AWT/Swing/SWT/JFace/JavaFX component to be usable within the DOM of WebKit. So I could create a nice HTML page with nicely formatted and CSS'd text, images, tables but then include, say, a JTable and JTree in the middle somewhere; letting the browser do the layout stuff.
This last requirement might seem complex but thats exactly what Flash and JavaFX are already; plugins which create custom UI widgets within the DOM.
For those that are aware of GWT Hosted Mode; this proposal is very similar - embedding a web brower inside the JVM as a single process. The main differences are
Swing would instantly get an awesome, standards based layout engine capable of easily rendering styled text, images and widgets while dealing with other kinds of media. Through the use of CSS Swing applications would be easily styled using all the existing HTML/CSS tooling.
Swing developers would then have the best of both worlds; their Swing widgets still working when they want to use them - but having the great power of the browser window around the widgets to make the layout easy, powerful and great looking.
Since the JVM would now have a standards based browser; and it can already run JavaScript (and pretty much all other languages) easily - any Swing application could make use of any of the current GWT or JavaScript frameworks out there. There's a ton of innovation happening in the JavaScript/GWT space right now leading to ever better UI capabilities. e.g. take a look at SmartGWT and jQuery to name but 2.
Benefits for Web Developers
So how will this move - aimed at helping Swing developers help Web developers? The common PITA for web folks is often the browser imposes restrictions (for good reason) such as
Now if you're making a public application; you're probably gonna have to deal with this (though now we're seeing custom apps for the iphone and android - maybe rich applications for public web sites are gonna be more common?). However loads of folks build web applications when they are really building internal, intranet applications.
So why not turn that web application into a desktop application making it run in a JVM? You can then package up your application with the exact, known browser you use and test with - and have access to all the features of the Java platform in your UI; whether its Java2D/3D, Swing/JFace, JavaFX or JMS/JDBC/JAX-WS etc
How this application is then made available to your users could come in different flavours; an application they install, Java Web Start (which might become cool again) or maybe even via JavaFX inside a browser?
So this could give a big safety net to folks building web applications. If you hit a browser limitation such as (say) a Canvas limitation? Just provide a Java2D version and ship a desktop application or Java WebStart it? It could end up that the JVM turns out to be the best place to host a web application reusing HotSpot?
Benefits for UI Developers
This single act of unifying the browser with Swing (and SWT/JFace) would provide a massive unification of standards based technologies for most UI development. More of the time spent building UIs would lead to creating more reusable standard artefacts (e.g. HTML and CSS) which are reusable in other contexts (e.g. transform HTML into PDFs or reuse the embedded microformats etc).
In these days of Dependency Injection; we're used to having a single code base then switching component implementations in different circumstances and environments; so we can start building more UIs which can be both web application and rich UI with each UI making the best use of its platform (zero install for web app, no limitations for desktop app).
Previously changing an application from a web application to a desktop application or vice versa was a massive undertaking (near total rewrite). Now it'll be pretty trivial to switch from one to the other as your requirements change. Applications will no longer be locked into one UI technology unable to move. UI code will become more aligned with the Write Once Run Anywhere mantra.
If folks create rich applications and web applications - there could be massive code reuse. While a web application and a Swing/JFace application are clearly going to have differences; they may use different views, components and features - there could be a huge amout of reuse of code. Even if the code reuse is only 30-50% its is big a saving; and we all need to do more with less these days. Though I can see - as UI frameworks improve, more and more chance of better code reuse across both.
Benefits for Sun
Folks have often said things in the past about Sun like
This move however would be a massive, positive move in the UI space and earn Sun a lot of kudos IMHO. Sun could then leverage all the innovation thats taking place in the browsers and WebKit in particular (HTML5, SVG, microformats et al) along with in the JavaScript worlds.
It would also mean there's not that much for Sun to do (other that integrate WebKit and provide APIs to control the browser and expose the DOM). All the innovation can then happen above this layer by the Swing, JFace & web developers and the WebKit & JavaScript communities. Immediately the Java ecosystem could then reuse all of the amazing work being done by the webby folks in JavaScript or by the GWT ecosystem.
i.e. the Java platform would then become a cool place to develop applications for (removing all the limiations with web browsers) with loads of buzz -and Sun doesn't really have to do much other than take all the credit :)
Heck they could even brand the WebKit-in-JVM as part of the JavaFX brand; so JavaFX doesn't have to beat Flash/Flex & Silverlight in the market to avoid looking like a turkey. JavaFX Platform (or whatever we call it - basically Java7 + WebKit) could turn into an instant success (anyone doing Swing or JFace would probably start using the embedded browser for better layouts & rendering) and if that helped the JavaFX Plugin (the JavaFX-as-browser-plugin) make some inroads to Flash/Silverlight its an added bonus. (Whereas right now JavaFX as just a browser plugin looks setup for failure to be honest, I don't see it ever eclipsing Flash).
Note its worth mentioning that there's similar moves to DOMs and whatnot being experimented with in the Eclipse ecosystem; who knows we could maybe finally unify on a single DOM?
Benefits for the Java Platform
Being able to build rich desktop and web applications in any language - without any browser limitations would be a massive boost to the Java platform; allowing folks to reuse all the good stuff from the OpenWeb and the Java platform (language diversity, IDEs and tooling, connectivity, Java2D/3D and even JavaFX).
We'd also hopefully see significant cross-pollination of the Swing / JFace folks and web folks to help UI innovation (which Sun doesn't have to try do itself).
If nothing else hopefully it will encourage more folks to write web applications and desktop applications to take advantage of both environments to provide better user interfaces for our users and customers for less effort.
Sounds like a win win for everyone doesn't it?
Update - JWebPane
So I should probably pay more attention to the JavaFX stuff :)
It seems that there is such a thing called JWebPane (see page 27 onwards of this presentation) which has been announced - so maybe this is gonna actually happen soon! :).
IMHO JWebPane sounds way more important to the Java ecosystem than JavaFX - I really hope it gets enough backing and funding from Sun to get completed and released real soon! Its not good to see nothing at all being released to the community despite it being announced about 7-8 months ago - so fingers crossed that whatever the legal/licensing issues are holding it back get resolved really soon.
We've just gotta lobby Sun to release it ASAP - then include it in Java 7... :-)
I'm afraid this post is gonna be quite long. (Holy crap - no blogging for ages and then two big posts in a week!) - first some background...
Programming Rich Java Applications Is Sucky
Imagine the scene. You're part of a team of Java developers; you're tasked to write a rich application. It might be a commerical app or some intranet enterprisey thing, or some rich application to improve the user experience of some web app (like the iphone versions of facebook/twitter/gmail etc) - whatever. So what do you do?
You've a mindnumbingly broad choice to choose from - here's just a few options...
- Swing
- SWT/JFace/EclipseRCP
- web app with some combination of Ajax/JavaScript/GWT libraries
- JavaFX?
- Flex/Flash
Write once and run everywhere - except if your application has any kind of user interface.
This is maybe why so many Java folks like writing server side apps; as the client side in the Java ecosystem is such a mess.
Helping Swing Developers
Lets imagine you pick Swing to develop rich applications. In its day, Swing was a good piece of work by Sun. However that day was in the nineties :)
I've done a fair bit of Swing in my time and worked on Swing projects; in my experience you can spend years trying to tart up a swing app and it still looks - well like Swing. You can get a day of a good web designers time and make any web application look stunning via HTML/CSS/images. It just seems so much easier to hack up HTML/CSS to look great. Just compare some great web 2.0 applications out there to your typical Swing UI. As an end user which would you rather use?
As a developer one of the big PITAs with Swing is layouts, styling and working with images and links. The standard layout managers suck. (GridBagLayout anyone?). Yes I know there's a zillion layout manager implementations out there - all doing different things well with different results & rendering bugs - and which one do you choose?
Generalizing hugely but most of the work that goes into most data entry-ish rich applications is creating loads of screens which are full of text, images, links and some rich widgets with plenty of documentation, popup help, cheat sheets and then laying it all out and styling it nicely. Swing is lousy at these UI basics. Sure its got a good JTable and JTree, something that many a web developer will probably have been envious of at some point or other when hitting gremlins in their JavaScript table/tree - but at laying out forms, dialogs, help screens, documentation and working with links and images - well its kinda sucky.
Swing developers should be using HTML/CSS for this - its great at it. The web browser is the best layout manager we have - and HTML/CSS is the best standard for laying out widgets. With HTML/CSS there's a ton of tooling out there too for viewing/editing/styling. You can then pass the HTML/CSS to your web designer while the Java Swing hacker focusses on the business logic or the complex widgets.
Plus any time you spend hacking HTML/CSS - being a simple, standard text format used inside web browsers means you can reuse your work in web applications as well as rich applications. You don't spend your time hacking up some Swing Java code thats only useful inside a Swing application.
My Proposal
So my proposal is, in Java 7 we integrate WebKit into the JVM. Why WebKit? Well its smaller and easier to integrate than Gecko; Apple chose it for Safari & iTunes and the iPhone and Google chose it for Chrome and Android. If its good enough for a cell phone surely we can fit it into a JDK/JRE for a rich desktop application?
If Sun wanted to get clever, the browser engine could be pluggable; letting folks pick different versions of WebKit or FireFox/Opera/IE - but lets not go there right now - lets just assume a recent WebKit version is baked into the JRE/JDK.
Some would argue it should be optional; but then given the size of the JDK/JRE there's a ton of not-that-useful stuff in there; I'd rather include it by default over loads of whats there :) But then the JDK/JRE is getting more modular right - so lets leave the optional nature of WebKit for when the JDK/JRE is truly modular - right now its huge; so if a cell phone can include it, so can a JDK/JRE :)
Next we have a standard Java API for creating a BrowserPanel which can be hosted inside any AWT/Swing/SWT/JFace based UI. So a browser window becomes a standard embeddable widget in Swing and SWT/JFace/Eclipse. There should also be an API for controlling the browser (loading/saving URLs and interacting with the DOM).
Finally I'd like any AWT/Swing/SWT/JFace/JavaFX component to be usable within the DOM of WebKit. So I could create a nice HTML page with nicely formatted and CSS'd text, images, tables but then include, say, a JTable and JTree in the middle somewhere; letting the browser do the layout stuff.
This last requirement might seem complex but thats exactly what Flash and JavaFX are already; plugins which create custom UI widgets within the DOM.
For those that are aware of GWT Hosted Mode; this proposal is very similar - embedding a web brower inside the JVM as a single process. The main differences are
- we need a standard API to spin up browser windows and embed them inside any Panel and to be able to bind any UI Panel inside the DOM easily (e.g. finding a div by ID and binding it to a JTable)
- we don't need the restriction of being able to turn the Java bytecode into JavaScript - as for standalone Swing/rich apps you can can leave it as it is :). So any Java code could work with the browser. So none of the GWT restrictions would apply - plus you could use Groovy/Ruby/Python/JavaScript/whatever
Swing would instantly get an awesome, standards based layout engine capable of easily rendering styled text, images and widgets while dealing with other kinds of media. Through the use of CSS Swing applications would be easily styled using all the existing HTML/CSS tooling.
Swing developers would then have the best of both worlds; their Swing widgets still working when they want to use them - but having the great power of the browser window around the widgets to make the layout easy, powerful and great looking.
Since the JVM would now have a standards based browser; and it can already run JavaScript (and pretty much all other languages) easily - any Swing application could make use of any of the current GWT or JavaScript frameworks out there. There's a ton of innovation happening in the JavaScript/GWT space right now leading to ever better UI capabilities. e.g. take a look at SmartGWT and jQuery to name but 2.
Benefits for Web Developers
So how will this move - aimed at helping Swing developers help Web developers? The common PITA for web folks is often the browser imposes restrictions (for good reason) such as
- only being able to interact nicely with the single domain that serves the web page
- not able to interact with the file system
- only having 2 threads for communication
- limited connectivity (kinda hard to use native sockets, Java web stacks, JMS, native JDBC etc)
- unable to use things like Java2D/3D without via plugins
Now if you're making a public application; you're probably gonna have to deal with this (though now we're seeing custom apps for the iphone and android - maybe rich applications for public web sites are gonna be more common?). However loads of folks build web applications when they are really building internal, intranet applications.
So why not turn that web application into a desktop application making it run in a JVM? You can then package up your application with the exact, known browser you use and test with - and have access to all the features of the Java platform in your UI; whether its Java2D/3D, Swing/JFace, JavaFX or JMS/JDBC/JAX-WS etc
How this application is then made available to your users could come in different flavours; an application they install, Java Web Start (which might become cool again) or maybe even via JavaFX inside a browser?
So this could give a big safety net to folks building web applications. If you hit a browser limitation such as (say) a Canvas limitation? Just provide a Java2D version and ship a desktop application or Java WebStart it? It could end up that the JVM turns out to be the best place to host a web application reusing HotSpot?
Benefits for UI Developers
This single act of unifying the browser with Swing (and SWT/JFace) would provide a massive unification of standards based technologies for most UI development. More of the time spent building UIs would lead to creating more reusable standard artefacts (e.g. HTML and CSS) which are reusable in other contexts (e.g. transform HTML into PDFs or reuse the embedded microformats etc).
In these days of Dependency Injection; we're used to having a single code base then switching component implementations in different circumstances and environments; so we can start building more UIs which can be both web application and rich UI with each UI making the best use of its platform (zero install for web app, no limitations for desktop app).
Previously changing an application from a web application to a desktop application or vice versa was a massive undertaking (near total rewrite). Now it'll be pretty trivial to switch from one to the other as your requirements change. Applications will no longer be locked into one UI technology unable to move. UI code will become more aligned with the Write Once Run Anywhere mantra.
If folks create rich applications and web applications - there could be massive code reuse. While a web application and a Swing/JFace application are clearly going to have differences; they may use different views, components and features - there could be a huge amout of reuse of code. Even if the code reuse is only 30-50% its is big a saving; and we all need to do more with less these days. Though I can see - as UI frameworks improve, more and more chance of better code reuse across both.
Benefits for Sun
Folks have often said things in the past about Sun like
- Sun doesn't get the desktop, its not its core business
- Sun can't compete with Microsoft in its back yard (the desktop)
This move however would be a massive, positive move in the UI space and earn Sun a lot of kudos IMHO. Sun could then leverage all the innovation thats taking place in the browsers and WebKit in particular (HTML5, SVG, microformats et al) along with in the JavaScript worlds.
It would also mean there's not that much for Sun to do (other that integrate WebKit and provide APIs to control the browser and expose the DOM). All the innovation can then happen above this layer by the Swing, JFace & web developers and the WebKit & JavaScript communities. Immediately the Java ecosystem could then reuse all of the amazing work being done by the webby folks in JavaScript or by the GWT ecosystem.
i.e. the Java platform would then become a cool place to develop applications for (removing all the limiations with web browsers) with loads of buzz -and Sun doesn't really have to do much other than take all the credit :)
Heck they could even brand the WebKit-in-JVM as part of the JavaFX brand; so JavaFX doesn't have to beat Flash/Flex & Silverlight in the market to avoid looking like a turkey. JavaFX Platform (or whatever we call it - basically Java7 + WebKit) could turn into an instant success (anyone doing Swing or JFace would probably start using the embedded browser for better layouts & rendering) and if that helped the JavaFX Plugin (the JavaFX-as-browser-plugin) make some inroads to Flash/Silverlight its an added bonus. (Whereas right now JavaFX as just a browser plugin looks setup for failure to be honest, I don't see it ever eclipsing Flash).
Note its worth mentioning that there's similar moves to DOMs and whatnot being experimented with in the Eclipse ecosystem; who knows we could maybe finally unify on a single DOM?
Benefits for the Java Platform
Being able to build rich desktop and web applications in any language - without any browser limitations would be a massive boost to the Java platform; allowing folks to reuse all the good stuff from the OpenWeb and the Java platform (language diversity, IDEs and tooling, connectivity, Java2D/3D and even JavaFX).
We'd also hopefully see significant cross-pollination of the Swing / JFace folks and web folks to help UI innovation (which Sun doesn't have to try do itself).
If nothing else hopefully it will encourage more folks to write web applications and desktop applications to take advantage of both environments to provide better user interfaces for our users and customers for less effort.
Sounds like a win win for everyone doesn't it?
Update - JWebPane
So I should probably pay more attention to the JavaFX stuff :)
It seems that there is such a thing called JWebPane (see page 27 onwards of this presentation) which has been announced - so maybe this is gonna actually happen soon! :).
IMHO JWebPane sounds way more important to the Java ecosystem than JavaFX - I really hope it gets enough backing and funding from Sun to get completed and released real soon! Its not good to see nothing at all being released to the community despite it being announced about 7-8 months ago - so fingers crossed that whatever the legal/licensing issues are holding it back get resolved really soon.
We've just gotta lobby Sun to release it ASAP - then include it in Java 7... :-)
Tuesday, 27 January 2009
JAX-RS as the one Java web framework to rule them all?
One of the things about Java that sometimes gets made fun of is the huge number of Java based web frameworks. There certainly are many, of all shapes and sizes! I suppose there are quite a lot of different shapes and sizes of web applications out there but it sometimes seems like there's a 1-1 mapping between applications and frameworks :).
Picking the right web framework is probably a managers nightmare (Which one to pick? Pick the wrong one and we might end up using a duff dead framework that few developers know etc?). But it has lead to a ton of innovation in the web framework space. On balance I think competition and innovation are good things.
I'm a big Rails fan, I think its a stunning piece of work and one of the most impressive open source frameworks created in the last 10 years which together with Ruby, Erb and Rake is a good alternative to Servlets + JSP + JSTL + Spring + Hibernate + WebFrameworkOfYourChoice + SiteMesh/Tiles + Ant/Maven + a few other bits all in a surpringly small and easy to grok codebase.
JAX-RS came along initially as a way of writing RESTful services on the Java platform; using annotations and loose coupling to bind resource beans and their public methods to URIs, HTTP methods and MIME content type negotiation. I've said before I think its awesome, one of the most impressive JSRs we've had.
From the perspective of the controller layer I actually prefer JAX-RS to Rails routes.rb & controllers as
So whats interesting is - if you want to build a web application with RESTful services (e.g. a human facing website with computer facing XML/JSON APIs) why would you use JAX-RS and another web framework? Why not just use JAX-RS as the web framework? So recently I've been musing, could JAX-RS be the one Java web framework to rule them all?
JAX-RS works well with dependency injection frameworks such as Spring, Guice, GuiceyFruit or JBossMC - you can basically pick whichever one you prefer. It also does all the heavily lifting of binding URIs and HTTP methods to resource beans and their methods along with supporting content type negotiation, headers and etags elegantly. For implementing great RESTful services in Java I've never seen anything close to touching it. The main question is what features are missing from JAX-RS being the main web framework?
Incidentally in this post I'm ignoring the server-side UI type frameworks like Wicket, Tapestry, JSF et al. I'm focussing on web frameworks that spend most of their time rendering HTML / XML / JSON and not building complex server side UI stuff and treating the browser as a kinda dumb terminal with the real UI work being done on the server side. Having had a horrid time using Tapestry and Hibernate together on some projects in the past, I'm kinda over the whole concept of server side UI web frameworks personally (I'm putting my flame-proof suite on now). I kinda think if you want to do complex rich web UIs, use wizards or complex flows, just use GWT or JavaScript on the client (or Flex/Flash for video or crazy highly graphical widgets) and keep the server side fairly simple and very RESTful. (But lets leave that discussion for another day... :)
In this post I'm only really considering frameworks like Struts, Stripes, SpringMVC etc. Thankfully WebWork and Struts merged together so at least there's been some consolidation in the space - and certainly Struts and Stripes are now kinda similar (and not too disimilar from SpringMVC). I wonder if JAX-RS will lead to further consolidation with web frameworks adding themselves as JAX-RS extensions?
So whats is missing from JAX-RS to be able to use just it for your entire web app and set of RESTful services and not have to use it with Struts/Stripes/SpringMVC and have to map some URIs into the web framework and some to JAX-RS?
Right now today there are definitely some holes; though currently I don't think there's that much missing. Here's my list of things I think are missing and how we could add them - I'm very interested in hearing if there's anything you'd particularly miss from Struts/Stripes/SpringMVC/whatever; please blog about it or post a comment and I'll do a follow up post!
Implict & Explicit Views
One great feature of Jersey is the support for Implicit and Explicit Views. Update: here's a link describing implict/explicit views. It basically allows the controller to delegate to the view layer (JSP/Velocity/Freemarker/GXP or whatever) using a default naming convention to find the template files in a directory named after the resource bean's class name and if required - the URI being requested. So a given Resource bean could have an index.jsp and edit.jsp templates for example - and referring to ${it.foo} inside the template would extract the foo property of the resource bean (you can override what 'it' is if you like but the resource bean is a very reasonable default).
Maybe the easiest way to understand implicit/explicit views is to look at the bookstore example in the Jersey distro; its basically the glue between JAX-RS resources and templates.
However there are some issues (which are being addressed particularly by the helpful folks on the Jersey list, particularly Marc and Paul) which basically revolve around having implicit/explicit views and (say) XML/JSON representations on the same resource bean using the same URIs and getting JAX-RS to pick the right one.
For example the URI "/customers" might return a HTML page for most web browsers but return XML/JSON if folks want to specify those MIME types in their Accept header. Right now Jersey tends to favour returning XML/JSON (long story but basically more specific URI paths are preferred over implicit views).
I'm pretty sure some kind of @ImplicitProduces annotation to allow implicit views to be associated to MIME types along with a higher priority/quality ranking specified in the next feature would solve pretty much all the issues with implicit/explicit views though am sure folks can think of other improvements...
Better Content Negotiation Support
It would be nice to see these issues resolved to be able to use RFC 2296 to be able to raise and lower the priorities (or quality) of the different representations.
e.g. you might want to prefer to return HTML over XML/JSON so unless folks ask specifically just for XML or JSON you return HTML.
Bizarrely Safari uses an Accept header of
So you might want to specify something like this on a resource to declare that you want to return HTML by default for most users...
You could argue the out of the box rankings for HTML should be 1.0 and XML/JSON something lower, say 0.9 or 0.5 as thats what most folks would want.
Dealing with static content
The Servlet spec is a tad smelly in this area (and even in servlet 3.0) of not easily allowing you to mark URI patterns as being handled by the container (e.g. for static content or for JSP files etc) and mapping all of the rest to your default servlet. Hopefully as Paul suggests we can get around this using servlet filters in Jersey; but it'd be nicer if there was a better fix for this. (Rails wins here hands down with using regex to map URIs to controllers). But this is more a servlet issue than JAX-RS / web framework.
Multipart support
Having support for Struts style form beans; binding a multipart to a bean is very handy. MrStruts himself has contributed jersey-multipart which goes most of the way there. Allowing direct binding with any bean to avoid having to use the MultiPart class directly would certainly help.
Standard JAX-RS client API like Jersey's
While not that relevant directly to web applications; being able to implement a REST service by invoking other RESTful services - or being able to test easily any RESTful service using an API like Jersey's client - while reusing the cool entity providers on both client and server side - would rock.
GWT and JAX-RS client integration
If you're building JAX-RS services and want a rich web client then GWT is a great solution; you can reuse all your Java code on the client and server side and its very easy to debug the whole application in a single JVM in your Java IDE.
GWT ships with its own RPC mechanism and there are various REST libraries for GWT such as gwt-rest it'd be nice if there was an easy way to reuse the same DTOs used on the server side like you can with Jersey's client library from inside GWT. Using JAXB inside GWT is probably non-feasaible :) but it should be pretty easy to just use GWT serialization and then support it as an entity provider in the JAX-RS runtime. (Is there a MIME type for GWT serialisation I wonder :).
Basically as an application developer it should be trivial to be able to reuse RESTful resources in JAX-RS inside the GWT client reusing all those DTOs if you want to.
Update: some other suggestions
Julio Faerman mentioned on the Jersey list mentioned the need for better validation. So maybe we could integrate the validation layer from Struts/Stripes into JAX-RS? Or use the the Bean Validation API (JSR 303)?
Also Julio and Jon in the comments mentioned the need for managing conversational state so integrating Web Beans (JSR 299) as an option for bijection of conversational state on resource beans sounds a good possibility.
What else?
Those are the things I can think of so far. Can you think of any others? What are there features in your favourite Struts/Stripes/SpringMVC/whatever framework on the server that you really can't live without?
I'd love to hear others thoughts; do you think I'm smoking crack or do you agree? :)
Picking the right web framework is probably a managers nightmare (Which one to pick? Pick the wrong one and we might end up using a duff dead framework that few developers know etc?). But it has lead to a ton of innovation in the web framework space. On balance I think competition and innovation are good things.
I'm a big Rails fan, I think its a stunning piece of work and one of the most impressive open source frameworks created in the last 10 years which together with Ruby, Erb and Rake is a good alternative to Servlets + JSP + JSTL + Spring + Hibernate + WebFrameworkOfYourChoice + SiteMesh/Tiles + Ant/Maven + a few other bits all in a surpringly small and easy to grok codebase.
JAX-RS came along initially as a way of writing RESTful services on the Java platform; using annotations and loose coupling to bind resource beans and their public methods to URIs, HTTP methods and MIME content type negotiation. I've said before I think its awesome, one of the most impressive JSRs we've had.
From the perspective of the controller layer I actually prefer JAX-RS to Rails routes.rb & controllers as
- the URI bindings are local to the resource beans which can be arbitrarily nested which makes refactoring much easier and avoids the complex routes.rb file with regex switches (I try and avoid regex whenever I can :)
- the loose coupling between the objects returned by the resource methods and the actual entity providers is clean; helping the application programmer focus on returning DTOs and letting the framework deal with the XML / JSON /Atom / multi-part-form marshalling & data binding stuff really helps. e.g. its easy to drop in support for new representations in a DRY way without changing the code of your resource beans (controllers), you can just modify an annotation
- static typing can be a handy thing when binding URIs and parameters to your controller. e.g. having String, integer, Date fields and parameters helps you having to explicitly convert things in your controller
So whats interesting is - if you want to build a web application with RESTful services (e.g. a human facing website with computer facing XML/JSON APIs) why would you use JAX-RS and another web framework? Why not just use JAX-RS as the web framework? So recently I've been musing, could JAX-RS be the one Java web framework to rule them all?
JAX-RS works well with dependency injection frameworks such as Spring, Guice, GuiceyFruit or JBossMC - you can basically pick whichever one you prefer. It also does all the heavily lifting of binding URIs and HTTP methods to resource beans and their methods along with supporting content type negotiation, headers and etags elegantly. For implementing great RESTful services in Java I've never seen anything close to touching it. The main question is what features are missing from JAX-RS being the main web framework?
Incidentally in this post I'm ignoring the server-side UI type frameworks like Wicket, Tapestry, JSF et al. I'm focussing on web frameworks that spend most of their time rendering HTML / XML / JSON and not building complex server side UI stuff and treating the browser as a kinda dumb terminal with the real UI work being done on the server side. Having had a horrid time using Tapestry and Hibernate together on some projects in the past, I'm kinda over the whole concept of server side UI web frameworks personally (I'm putting my flame-proof suite on now). I kinda think if you want to do complex rich web UIs, use wizards or complex flows, just use GWT or JavaScript on the client (or Flex/Flash for video or crazy highly graphical widgets) and keep the server side fairly simple and very RESTful. (But lets leave that discussion for another day... :)
In this post I'm only really considering frameworks like Struts, Stripes, SpringMVC etc. Thankfully WebWork and Struts merged together so at least there's been some consolidation in the space - and certainly Struts and Stripes are now kinda similar (and not too disimilar from SpringMVC). I wonder if JAX-RS will lead to further consolidation with web frameworks adding themselves as JAX-RS extensions?
So whats is missing from JAX-RS to be able to use just it for your entire web app and set of RESTful services and not have to use it with Struts/Stripes/SpringMVC and have to map some URIs into the web framework and some to JAX-RS?
Right now today there are definitely some holes; though currently I don't think there's that much missing. Here's my list of things I think are missing and how we could add them - I'm very interested in hearing if there's anything you'd particularly miss from Struts/Stripes/SpringMVC/whatever; please blog about it or post a comment and I'll do a follow up post!
Implict & Explicit Views
One great feature of Jersey is the support for Implicit and Explicit Views. Update: here's a link describing implict/explicit views. It basically allows the controller to delegate to the view layer (JSP/Velocity/Freemarker/GXP or whatever) using a default naming convention to find the template files in a directory named after the resource bean's class name and if required - the URI being requested. So a given Resource bean could have an index.jsp and edit.jsp templates for example - and referring to ${it.foo} inside the template would extract the foo property of the resource bean (you can override what 'it' is if you like but the resource bean is a very reasonable default).
Maybe the easiest way to understand implicit/explicit views is to look at the bookstore example in the Jersey distro; its basically the glue between JAX-RS resources and templates.
However there are some issues (which are being addressed particularly by the helpful folks on the Jersey list, particularly Marc and Paul) which basically revolve around having implicit/explicit views and (say) XML/JSON representations on the same resource bean using the same URIs and getting JAX-RS to pick the right one.
For example the URI "/customers" might return a HTML page for most web browsers but return XML/JSON if folks want to specify those MIME types in their Accept header. Right now Jersey tends to favour returning XML/JSON (long story but basically more specific URI paths are preferred over implicit views).
I'm pretty sure some kind of @ImplicitProduces annotation to allow implicit views to be associated to MIME types along with a higher priority/quality ranking specified in the next feature would solve pretty much all the issues with implicit/explicit views though am sure folks can think of other improvements...
Better Content Negotiation Support
It would be nice to see these issues resolved to be able to use RFC 2296 to be able to raise and lower the priorities (or quality) of the different representations.
e.g. you might want to prefer to return HTML over XML/JSON so unless folks ask specifically just for XML or JSON you return HTML.
Bizarrely Safari uses an Accept header of
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5which kinda means it prefers to render XML over HTML (despite rendering XML as plain text! Truly bizarre - what was Steve smoking that day :). Most web apps I know of would rather return HTML by default :)
So you might want to specify something like this on a resource to declare that you want to return HTML by default for most users...
@ImplicitProduces("text/html;q=1.0")Those MIME Strings could be static final constants BTW to keep things DRY and not have to repeat a ton of MIME expressions throughout your resource beans and making it real easy to add a new MIME type to your code without changing your controller methods.
@Produces("text/xml;q=0.5, application/xml;q=0.5; application/json;q=0.5")
public class MyResource {
...
}
You could argue the out of the box rankings for HTML should be 1.0 and XML/JSON something lower, say 0.9 or 0.5 as thats what most folks would want.
Dealing with static content
The Servlet spec is a tad smelly in this area (and even in servlet 3.0) of not easily allowing you to mark URI patterns as being handled by the container (e.g. for static content or for JSP files etc) and mapping all of the rest to your default servlet. Hopefully as Paul suggests we can get around this using servlet filters in Jersey; but it'd be nicer if there was a better fix for this. (Rails wins here hands down with using regex to map URIs to controllers). But this is more a servlet issue than JAX-RS / web framework.
Multipart support
Having support for Struts style form beans; binding a multipart to a bean is very handy. MrStruts himself has contributed jersey-multipart which goes most of the way there. Allowing direct binding with any bean to avoid having to use the MultiPart class directly would certainly help.
Standard JAX-RS client API like Jersey's
While not that relevant directly to web applications; being able to implement a REST service by invoking other RESTful services - or being able to test easily any RESTful service using an API like Jersey's client - while reusing the cool entity providers on both client and server side - would rock.
GWT and JAX-RS client integration
If you're building JAX-RS services and want a rich web client then GWT is a great solution; you can reuse all your Java code on the client and server side and its very easy to debug the whole application in a single JVM in your Java IDE.
GWT ships with its own RPC mechanism and there are various REST libraries for GWT such as gwt-rest it'd be nice if there was an easy way to reuse the same DTOs used on the server side like you can with Jersey's client library from inside GWT. Using JAXB inside GWT is probably non-feasaible :) but it should be pretty easy to just use GWT serialization and then support it as an entity provider in the JAX-RS runtime. (Is there a MIME type for GWT serialisation I wonder :).
Basically as an application developer it should be trivial to be able to reuse RESTful resources in JAX-RS inside the GWT client reusing all those DTOs if you want to.
Update: some other suggestions
Julio Faerman mentioned on the Jersey list mentioned the need for better validation. So maybe we could integrate the validation layer from Struts/Stripes into JAX-RS? Or use the the Bean Validation API (JSR 303)?
Also Julio and Jon in the comments mentioned the need for managing conversational state so integrating Web Beans (JSR 299) as an option for bijection of conversational state on resource beans sounds a good possibility.
What else?
Those are the things I can think of so far. Can you think of any others? What are there features in your favourite Struts/Stripes/SpringMVC/whatever framework on the server that you really can't live without?
I'd love to hear others thoughts; do you think I'm smoking crack or do you agree? :)
Tuesday, 20 January 2009
Apache Camel goes top level!
Apache Camel is now a top level project at Apache - you can find it at http://camel.apache.org/. Yay!
Many thanks to all the Camel Riders who made this happen!
Wednesday, 7 January 2009
JAX-RS as the basis of a DRY web framework
I'm with Sam that JAX-RS rocks and is a great basis for a RESTful framework for writing services. As I've said before, I think its the best JSR output since servlets and JPA. There's a great presentation by Stefan on it if you want to get up to speed fast.
I'd like to see something like the Jersey client standardised in JAX-RS - after all many restful resources are mashups of other resources and it makes testing of RESTful resources super simple. Also I love the implicit views in Jersey and hope they are kinda standardised some more; making the mapping between templates and resources more well defined across providers. But even in its current form, its great stuff.
Tuesday, 14 October 2008
Liking the File language in Camel 1.5.0
Claus has a great write up on the new File language feature in Camel 1.5.0 - cool stuff! I'm really looking forward to the next release!
A favorite feature of mine in the next Apache Camel is a new feature to use file name patterns in the file component. What we have introduced is a new language, the file language, so you can leverage this feature anywhere in Camel where it uses Expressions, Languages etc. The file language currently support both the file and the FTP component as well.
As a lot of integrations is file based you need to be able to read (consume) or write (produce) files. Then you need to be able to specify file names. What's new in Camel 1.5.0 is that you can express this using patterns, for instance directly in the configuration of your endpoints. Prior you had to do this in Java code.
Simple example
Lets image you need to move consumed files into a backup folder after processing.
Now you can express this using the pattern: backup/${file:name}
Well then you need to use .bak as extension, and the pattern is:backup/${file:name}.bak
Okay next issue is that the backup folder should be grouped by dates using the yyyyMMdd pattern. Well the expression support thejava.text.SimpleDateFormat patterns also.
The pattern is:backup/${date:now:yyyyMMdd}/${file:name}.bak wherenow means current date. You can substitute this with different commands such as file for using the timestamp on the file instead.
Advanced example
In this sample you need to produce files (save) and you need to save the file using a generate unique filename. We use the divide and conquer pattern for this so you create a POJO class that generates the unique filename, then you as the developer have the full power how to do this. And then its very easy to unit test as its plain POJO that can be tested very easily with JUnit. Next step is to express this as a file pattern. As your POJO is a bean we use the bean langauge to invoke your pojo.
So the pattern is: myfile-${bean:myguidgenerator.generateid}.txt
Where myguidgenerator is the bean id of your POJO and generateidis the method name. You can omit the method name if there is no ambiguity which method Camel should invoke.
Camel routes
This feature is configurable directly in camel routing on your endpoints. So what we can do now is:
from("file://inbox?expression=backup/${date:now:yyyyMMdd}/${file:name}.bak").to("bean:processFile");
The route will consume files and process the files in the processFile bean, that is a plain POJO class. After processing the files is moved (renamed) using the pattern in the expression. So the file is moved to the backup subfolder, for example: backup/20081014/report-october-2008.bak
More to come
Well there is a ton of new features and improvements in Camel 1.5.0. Check out the current release note.
Thursday, 9 October 2008
Using Guice as a JNDI provider
In many ways a Dependency Injection framework is a replacement for looking things up in a registry like JNDI; but sometimes having some kind of registry or JNDI provider can be useful such as if you want to work with JSR250/EJB3 or some legacy code which expects JNDI to be used - or you want to use JNDI as a kinda loosely coupled registry between completely different modules of your system.
I've hacked up a simple JNDI provider which just uses Guice to create all the objects; so you stick to pure Java code for writing your Guice Modules to depenency inject your objects together then have a little properties file to enable/disable/tweak things.
When looking at Guice through spring-tinted glasses the most glaring difference (apart from the lack of XML) tends to be the absence of the ApplicationContext and a registry where you can look things up by name. This JNDI provider provides a more standard alternative to the ApplicationContext, as JNDI is in the JDK and it kinda gives you that crutch to lean on until you figure out the guicier way of doing your dependency injection :).
Tuesday, 7 October 2008
Adding support for @PostConstruct, @PreDestroy and @Resource to Guice
I do like guice as a Dependency Injection engine; I think it has a lot of promise; particularly if 2.0 is released soon :)
I still struggle sometimes, coming from a spring framework mindset, figuring out how to do some stuff. Though I love the @Provides support in trunk of Guice. Here's hoping 2.0 is out soon! :)
I've experimented recently adding support for ConstructorInterceptors into guice so you can add custom lifecycles like @PostContruct from JSR250/EJB3 or Spring's InitializingBean etc.
I've also created a patch to support closing of singletons such as via @PreDestroy or spring's DisposableBean.
Slightly more wacky is a patch adding support for custom injection point annotations which allows you to easily support things like
- @Resource from JSR 250/EJB3
- @PersistenceContext from JPA
- the various JAX-RS annotations like @Context, @PathParam etc
- WebBeans @In
- Spring's @Autowire
- Apache Camel's injection annotations like @EndpointInject or @Produce
Feedback greatly appreciated!
Enterprise Integration Designer preview
From Oisin's blog.
Thanks to Enterprise Integration Patterns, architects have a clear and succinct way to describe integration within complex systems. It certainly beats a lot of MS-Word documents and monster integration architecture diagrams. And, with Apache Camel, we’ve got an open source runtime that allows us to create routes by chaining EIPs together, using Spring XML or Java fluent builders. That’s fantastic, but EIPs are as much about sharing pictures as creating message routing graphs, and where are the pictures?
We’ve made some tools that will allow you to load up Camel Spring XML files into Eclipse for visual inspection and editing. You can also create EIP diagrams in your Workbench and save them as Camel configurations. Finally, we’ve put in some debugging capabilities to allow you trace through the paths a message will take through your EIP graph.
We are earnestly seeking feedback - check out the FUSE Integration Designer Preview page to download the Eclipse plugins, or check out the video links under the Training Videos at the bottom of the page.
Looks great! Feedback greatly appreciated
Subscribe to:
Posts (Atom)