2008s

Open Source not proof against EOL

[caption id=“” align=“alignright” width=“198” caption=“Thanks to Aaron_M!“][/caption]

“The glories of our blood and state     Are shadows, not substantial things;  There is no armour against Fate;     Death lays his icy hand on kings: …”

And, as it turns out, Eclipse Projects too. On November 12th, the Eclipse Foundation is holding two Termination Reviews as part of its regular Eclipse Project Review schedule. The ALF Project (death knell pdf) and two of the components (SC, SOAS, death knell pdf) of the SOA Tools Platform project are slated to shuffle off their mortal coil, kick the bucket, buy the farm.

The good thing is that while an Open Source project might well crumble, through neglect or disinterest, to readonly svn dust, like the mythical vampire, just a few drops of the right kind of blood dripped onto the repository will have it up and about again.

Updates 2:

Blog posting gets SearchSOA interview with Rich Seeley

Updates 1:

Slow Friday in Vulture Central  ;  Sanjiva has a Little Sneer at Eclipse

Camel Spit

What goes into a When?
Isn’t it great when you get an excuse to learn something? Even though you have a to-do list the length of your leg already?  Inspired by this potential enhancement to Apache Camel, intrigued by Xtext and (crucially) enabled by two full batteries and a flight to Boston, I hacked up a simple grammar for a DSL to describe Apache Camel routes and generated a syntax-checking Eclipse editor. It’s not pretty yet, but you can see the result at the Camel Extra project - introducing the charmingly named Camel Spit.

Working With Enterprise Integration Patterns

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.

Blog move...

This blog is moving to http://oisinh.wordpress.com and will resume with a slightly different focus. See you there!

Developing Web Services with Eclipse and CXF

Update:This is the most searched-for entry on my blog, and I have to warn you it is WAY OUT OF DATE! So skip it - and someday I’ll write an update and link it from here…

I’ve seen more than one instance of people scratching their heads over the CXF tools in the Eclipse STP project, so it was time to go back to the drawing board and take a new approach. Now we’ve finished our first cut of what we think service creation tools should look like, we would like you to check them out and tell us what you think.

What have we done differently? Well, the code is now completely based on Eclipse WTP frameworks, rather than having only a passing integration with them. If you’ve ever done Axis2 web service development with Eclipse, then you should be able to get familiar with this really, really quickly. You can create CXF web services from WSDL, or from a Java class or interface. The tools support selection or extraction of an SEI if you are starting from a class. JAX-WS annotations get added automatically, and you set preferences on how you would like them to be defaulted. And to help with getting those annotations right, we’ve added some validation - you’ll get error markers if you incorrectly combine annotations.

If the alphabet soup in the previous paragraph has made you sleepy, a few examples of the tools working might help to perk you up. Check the silent movies.

So, where can you get the code? For a start, we’ve bundled it in the FUSE Integration Designer Preview. We’ve also decided to contribute the code to the Eclipse WTP project, where it can be warm and cosy and be accessible for all. You can find the proposal for the WTP Incubator attached to Eclipse bug #248630. Also attached to that Eclipse bug is a zip file that contains the plugins you need to get running. Unzip this into your eclipse directory, restart your workbench and you should be good to go.

Try it out and let me know how you got on. You can leave feedback here on this blog, add a comment to the Eclipse bugzilla, send an email to users@cxf.apache.org (best place right now), or drop in on the FUSE Tools Forum.

Web 2.0 == (Web 1.0 + Pies)

It’s official. Web 1.0 has grown up, become more attractive, but behind the scenes has been cramming in the pies. Average web page size has tripled in the last five years.

WSDL Revisited

Waay back in May last year, I wrote a little blog entry taking WSDL and associated tools to task. You can imagine my delight when my esteemed colleague Guillaume Nodet sent me a link to a Google Code project called Relax-WS.

The author states

WSDL is a key technology for SOA, and yet creating and editing these files is about as much fun as straightening all the noodles in a bowl of spaghetti with a pair of tweezers.

and goes on to promise

Relax-WS aims to provide a simple, programmer-friendly syntax, without losing any of the metadata

all good, right and true, in my opinion. I would go even further on the last quote there and say that Relax-WS should aim to provide the simple, programmer-friendly syntax, but should also lose any metadata that is not necessary and add metadata where it is missing from WSDL.

One comment I have on the Relax-WS approach is a reaction to the sample code that is on the front page

service Hello {
  port {
    operation SayHello {
      in {
        element name {xsd:string}
      }
      out {
        element message {xsd:string}
      }
    }
  }
}

What's wrong with this, you might ask? It's clear and concise. Indeed it is, say I, and there is nothing at all wrong here, but the bit that makes me somewhat uncomfortable is the use of the service term there. Once you start to mention services, you are looking at a crossover from definition of schema and operation to a service provider definition, which necessarily leads on to having concrete pseudo-physical resource details in the Relax-WS file. What's a pseudo-physical resource? It's an artifact that has a constraints on a machine - so things like ports, databases, file systems, etc fall under this category. If you nail down your pseudo-physical resources at development time, then you are in for a reduced amount of fun when it comes to deployment. Ideally, you bind all those pp-resource details at the last minute (delay your decisions -- a lean maxim), so when you are developing you should set up the capability to discover those details at start up time from a fixed place, rather than baking them in.

A good example would be coding a Spring application for the ServiceMix 4 kernel, burning in the configuration into the bundle, and then binding it to a little properties file that contains the pp-resource specifics for the particular [virtual] machine upon which it is to be hosted.

Anyway - fair play to the author of Relax-WS for taking this on. I'm sure there will be take-up of the project.