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

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.

I'm just back from Javapolis in Antwerp. Javapolis is a conference put together by the BEJUG, Antwerp is a big city in Belgium and the second largest seaport in Europe . For a conference put together by a group of folks that are not pro conference makers, it was pretty impressive. The fact they have kept the price down to less than €300 is particularly amazing.

I was there to check out the conference, but even more importantly to get to have a chat with some of our new committers on the Eclipse SOA Tools Project. We've had a number of new components just added to source control (more about that in another entry) and now I was getting the chance to meet some of these developers for the first time. Even better, I got to hang out with Bruce Snyder, open source aficionado extraordinaire, and Stephen McNamara, a buddy of long standing and enterprise survivor.

First off the bat I had a chat with Mark Little whom you may know from JBoss ESB and the world of transactions in general. We marvelled at how world+dog is currently refactoring their {insert runtime tech of choice} to be composed platforms using OSGi bundles. This is going to be very interesting as it will open up the containers, which will hopefully bring more control to the customer platform developers on the one hand, and introduce with the other a whole raft of new interoperability issues :)

James Gosling's keynote was a round-up of everything that has happened in Java land for the last year. It's easy to see where his interest lies - realtime java and the spread of java-controlled devices, using SunSpots and similar tech. He also spoke of the mobile services architecture (JSR248) and how that was to be a "grown-up CLDC". I polled a few individuals over the next few hours and there was a keen interest in seeing how Google and the OHA will eat Sun's lunch on this one.

Key point for me was that mobility is coming of age at last, something like 2 years after we pulled our enterprise-mobility product. Timing is everything after all.

Netbeans 6 hit the presses during the week, and James was keen to point out some of the new and shinies in the bag. Enhanced mobility support was one thing, an holistic Java model that makes for keen context-sensitive refactorings, REST service development tools and advances in report design and generation were some of the things he mentioned. I'll be looking at the REST tools, because we are developing REST tools in STP too, but the Eclipse refactoring and reporting facilities seem to be at least a couple of years ahead in terms of feature comparison. I've not using the mobility gear in Netbeans or Eclipse, so no comment on that.

He also mentioned JavaFX, and later on in the week I attended a talk/demo on it. It looked faintly interesting until I spoke to the guy sitting next to me. He had attended a talk at OSCON where the JavaFX demo was followed up by a Flex demo which blew it out of the water totally - the SUN demo person looked pretty squirmy by his account. Flex is very very impressive, but perhaps JavaFX may beat it on the phones.

The guys from OW2 had a talk about all of the stuff that they have and how it can all be linked together. It had BPM, BAM, SOA, portals, workflow, monitoring and all other aspects of the enterprise buddha nature. My poor brain filled up early in the talk, so I will need to look into it in bite-size chunks later. I'm delighted that Eclipse STP counts among its committers a number of individuals that are involved in the OW2 community-- Christophe Hamerling, Adrian Mos, Andrea Zoppello, to name but a few and of course Alain Boulze, who is an STP PMC member.

In between the corridor work I managed to get to a few more talks. I experienced a good quality brain melt at Joshua Bloch's closures talk and attended a very informative talk on JSR311 and REST from Paul Sandoz. Andrea Zoppello did a very interesting demo on going from BPMN to runtime monitoring at the Eclipse stand and I got to catch up with the Eclipse stalwarts Wayne Beaton and Ralph Müller. In the photo below you can see the inimitable Bruce Snyder being totally mobbed by adoring geek fans after his talk on ServiceMix and Camel. [Note - picture is blurry due to awesome flux of worshippon particles]

If you are in the market for a Java conference, and a bit short on budget, Javapolis is well worth your while, methinks. I would just ask them to do two things for next year - first, open up the program to allow submissions from whoever wants to submit java related stuff; second, put some evaluation sheets out there guys! That panel with Bloch, Gafter, Gosling, et alii was really really terrible! Having Bloch and Gosling waffle on about unsigned int for nearly 20 minutes was a total waste of time. Got to hand the beachball of blame to the moderator there - should have put the squeeze on them, Carl!

For photos, hit Flickr with a keyword search on JavaPolis.

Didn't we do this already, a while back?

It's slated for contribution to Apache too.

p2 is a framework which is all about configuring things and putting them somewhere. That's as generic as I can make the definition :) In the example on the website, p2 is being used to move bundles around. The SoaTools, Swordfish and WebTools projects already do this kind of thing, and we have a set of deployment frameworks which allow us to configure and deliver things (WAR files for example) to different places (server runtimes for example). That's why we are interested, especially since there are visible moves in the direction of OSGi based runtimes for hosting Services .

I'm just at the point where I need to drill into the information on the web. As per usual, I'm confused about how p2 and Buckminster appear to do exactly the same thing. And I want to see how p2 matches up with the SoaTools SOAS component. If we could do something around extending p2 (if appropriate) then we could reduce the STP workload a bit. I guess that WTP and Swordfish are thinking the same thing.

I feel a workshop coming on here :)

A tangential point: as far as I know, and I am open to correction here, the p2 project was brought into the Eclipse ecosystem as an effort to replace the aging Update Manager mechanisms. Certainly over the course of the last couple of years, many interesting behaviours of the UM have come to light, but it might have been a good idea to fix those in conjunction with starting a new development effort. As per usual, if you have patches, feel free to open a bugzilla :)

Another tangential point: there is a project proposal called Riena which will also be interested in the p2 capabilities. I don't yet understand what Riena is trying to do - all I know is that it is about 'smart clients', the committers are mostly tall, and that they all wear the same teeshirts. When I find out more I'll let you know. In the meantime visit the top-level page on wiki for p2 for details.

Plugin Spy
Select something in the UI, hit Alt+Shift+F1, and you get a window containing an introspection of the current widget/part that you have selected. Check out the PDE Incubator page, and a blog entry from Chris. If you are using Eclipse 3.4M2 or later, you will find this feature already built-in.

Clean Ups
I use Checkstyle in most of my project work, and it and I have an uneasy relationship. The sort of one where the dishes get broken and people come around to bring the pets away. I have always whined that if Checkstyle is so smart, why doesn't it get rid of that trailing space it spotted for me and stop bothering me? Well, it can't do that, but Eclipse Clean Ups can. Woot!

A Clean Up is just a collection of refactorings that you use regularly on your code to keep it squeaky. You can run 'em manually, or have them run automatically when you save a Java file. Go to this developerworks article to find out more.

EclEmma
If you are familiar with the Emma Project then you will have probably guessed that this is a test coverage tool for Eclipse, based upon Emma. I've always found test coverage to be an invaluable tool for showing you where the great, gaping, black holes of non-deterministic behaviour reside in your code. There's a lot of tools that can do coverage, and there are Eclipse integrations at varying levels of quality. What I liked about EclEmma is that it is quick and straightforward to use on a single Eclipse project, and gives me the results fast. Although the results are not always welcome :)

Update: Jeff McAffer's Eclipse Update Talk [pdf link] has details of Plug-in Spy and Clean Ups.

Apparently crap4j can also estimate your CRAP Load (we've beaten this one to death - ed.), in which it gives an indication of how many tests you will need to write to reduce the CRAP index to less than an arbitrary bar of 30.

Update: tried it out, and it seems interesting - I can understand the concepts immediately and it has an amusing toilet paper icon on the menu. Here's a screenshot of the CRAP Report that it produces.

In the case of this anonymous component, you can see that the crapometer weighs in at 14.91% - an artitrary figure that tells me that a little over one in seven of the methods in the component are, well, crappy.

The CRAP Load figure above hints that maybe about 14 tests would do the trick in reducing the CRAP figure of a complex method with 0% coverage.

This work is a big thing for EMF, in my opinion. Putting this together with a simple HttpService instance in an OSGi container can give you the basis for remotely manipulable models, with most of the work done by EMF itself. This opens up the field for Rich Internet Applications (blach - another buzzword) that can interact with hosted EMF models without having to depend on having an EMF library on the client side.

The Artix Repository product that IONA ships has done something very similar, but we have created the RESTful interactions outside of EMF. It's cool to see this kind of capability moving into the core.

The Euro Summit is an interesting conference - the content is usually good, the venues conducive to meeting people and of course the German beer is without peer. This adds up to a fun-filled few days. During the conference, Adrian from STP will be updating us on what's new and noteworthy on the project, and of course bringing us up to date on the old material too. One of the evenings will contain an STP BoF, although the date has to be confirmed.

import javax.persistence.*;

@MappedSuperclass
@EntityListeners({ModelListener.class})
public abstract class ModelBase {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name="id")
    private Long id;
    @Version
    @Column(name="version")
    private Integer version;
    @ManyToOne(fetch=FetchType.LAZY)
    @JoinColumn(name="created_by_user_id")
    private User createdByUser;
    @Temporal(value = TemporalType.TIMESTAMP)
    @Column(name = "date_created", nullable = false)
    private Date dateCreated;
    @ManyToOne(fetch=FetchType.LAZY)
    @JoinColumn(name="updated_by_user_id")
    private User updatedByUser;
    @Temporal(value = TemporalType.TIMESTAMP)
    @Column(name = "date_updated", nullable = false)
    private Date dateUpdated;
    // methods removed for readability
}

I got a bit of a chuckle out of the comment at the end of class declaration, but my overall feeling was one of giddiness at the sight of Annotations Gone Mad. It's fashionable, it appears, to bang in as many annotations as possible in Java 'frameworks'. If you have dealt with debugging C# webservices clients, you might recall the brain damage that was introduced when trying to fish through dozens of C# annotations in the generated code. Is this going to happen all over again, but for Java this time?

My particular complaint is not about using annotations, which I do think are wickedly useful for getting rid of the omnipresent and immiscible configuration APIs in thousands of products. Being able to inject values into class members is brilliant. There are even some gnarly uses where annotation declarations may themselves have annotations (go look at the Apache Camel source code). But using annotations to tie Java programs to what are irreducible and unmappable resources - ports, URLs, even DB tables - doesn't make a lick of sense to me.

Update: Benson Margulies has given this condition a name - an infestation of snails (@) - in a cxf-dev posting. This is so good I had to change the name of this entry.

You can download the slides and notes and check it out. From the top of the room, I observed the reaction: a healthy mix of boredom, horror, torpor, confusion, outrage, interest, catatonia and crackberry tapping. After the talk, I did get some compliments and interesting questions. No pitchforks and torches, so that was good.

On the subject of pitchforks and torches, I was lucky enough to be invited to sit on a SOA Industry Leaders Panel with Martin Fowler and Gregor Hohpe. It was an interesting thing to site between those two guys, whose books and articles I've avidly consumed in the past. Mainly I worried about looking like a total idiot. According to Jay at DeCare Systems, I did ok - if you read that entry, you'll see the torches reference I made earlier.The whole thing was filmed, so perhaps we will get to see it online sometime. The panel moderator, the inimitable Ted Neward, gets my vote for best panel mod evah, coaxing some excellent tough questions from what turned out to be a good audience. It was with a mental sigh of relief from me that Gregor got in first on the inevitable What is a Service, anyway?.

Update - check out Ade's experiences at TSSJS

From the perspective of SOA Tools, it's a time to gather our wits and make some plans, with the help of the community. I'm glad to say that over the last few months, there has been a considerable amount of interest in the project from a number of organizations that wish to contribute code and expertise. The PMC's challenge is how to make sure that all these prospective committers can work together in a way that is conducive to developing the best open source tools and frameworks.

Enter the Incubator. This is to be an STP sub-project (it's in pre-proposal phase right now), which I hope will address our challenge. It works like this -- a number of organizations decide they would like to contribute some code, but in each case, they have code that does the same or similar things. The best thing for the project is that the committers come together, bring their solutions to the table, re-architecting if necessary, and producing a joint vision for the merged code. The 'table' in that metaphor is the Incubator sub-project. Once the technical vision has been constructed and agreed upon, and a draft plan put in place, any work that has taken place in the Incubator is ready to 'graduate', that is, move to full STP sub-project status.

It's also time to let us know what you would like to see happening in the current areas of the project - let us know on the dev list or the newsgroup!

I'm looking forward to getting this out the door so that we can get back into a planning mode next week!