netzooid

Dear Google:

I know you worked hard at your JavaOne party this year, but did you just copy Simula’s (aka devzzzzz) party from last year? You’re on top of the world – I expect more than bad beer and wine over the course of a few hours which you’ve paid 10x too much for! How will you attract your developers unless you flaunt your incredible chefs or tell us how awesome the 20% time is? The one thing that the party might have had going for it was exclusivity, but even then it was screwed up – you gave out invitations to anyone who asked. How are you going to keep the uncool people out?

Sadly, you are just a poor man’s Tangosol. They managed to get bought by Oracle and still have a party where someone can get a RedBull & Vodka. Where does that leave you?

Regards,

- Dan

I know this is just a few days late, but Gregor just got his out, so at least I’m in good company.

I spent a lot of time this year manning the Envoi booth with Paul. Paul’s entry captures most of my thoughts, but its worth just recapping some things.

The booth was a good chance to talk to people about their needs and how they’re using CXF & XFire. Conversations ranged from educating people about our open source involvement to talking about WebLogic issues to discussing advanced product integration to whats next for CXF. It was also a good chance to educate people about our business. As Paul mentioned, it is easy to have your work in open source get disconnected from the company you work for. Conferences seem to be a good way to help establish that connection.

I was very unimpressed with the start up booths this year. They tried a new layout that resulted in us getting comparatively little traffic. While they admitted it was a mistake, they were were pretty unapologetic about it and tried very little to fix it.

The nighttime parties were a lot of fun this year (as always). While I sufferred from a cold the whole week, I did manage to stay out late a fair amount (which probably didn’t help). The new restaurant of the week was the Town Hall. Highly recommended. Other highlights included visiting the Slanted Door yet again, the RedMonk unconference, the Tangosol party, and a visit to the “place of leaky abstractions.”

The disappointments of the week included being randomly bitten (hard) in a bar by some drunk woman and the Google party at the W.

(Updated to move the letter to Google to a separate post and also add mention to the RedMonk unconference. Random question: is everyone a RedMonk customer these days? Crikey – they’re everywhere.)

I’m happy to announce that the first version of Navigating WS-* is now available. It expands on my ApacheCon EU presentation about WS-* and tries to answer some of the following questions:

• What standards should I be aware of, which ones should I consider using, and what do they offer me?
• How do these specifications work and how can they be composed?
• What platforms and tools interoperate with particular standards?
• Where are these standards going in the future?

We’ll be distributing copies at our JavaOne booth this year, so if you’re around, come pick one up and say hi!

No doubt there are some errors, unclear sections, etc in my writing. If you have feedback I would love to hear it. Leave a comment here or send along an email to dan AT envoisolutions dot com. There is definitely still more to cover and I should be updating the document in the future – as well as producing an HTML and/or wiki version (*mutters something about Word HTML generation*).

Stephan just recently wrote in to say that my XFire Web Services talk is no on Parleys, which is where all the Javapolis and Bejug videos are hosted. In it I talk about XFire, some tips for building good web services, and give a little intro into CXF.

Its a pretty cool site in general. One of the talks on there that I really enjoyed at Javapolis was Guy Pardon’s talk on WS-AtomicTransactions, BusinessActivity, and Coordination. Not being a transactions wonk, it clarified how everything was supposed to fit together.

I’m very happy to announce that the CXF team has produced a 2.0 release candiate! This release has some real quality stuff in it:

• A JAX-WS implementation – although we aren’t quite TCK compliant yet.
• Built in support for WS-Addressing, WS-Policy, WS-RM, and WS-Security
• Really good Spring 2.0 integration
• Support for building web services from POJOs – i.e. no annotations
• HTTP, JMS, and local (in-JVM) transports
• RESTful services support – including JSON services

If you’re currently an XFire user, I would suggest you take a look. I think there is a lot to benefit from:

• Improved WSDL support
• Improved JAX-WS support
• Improved JMS transport
• Maven plugins
• Spring 2.0 syntax support
• Improved WS-* support
• Cleaned up APIs for building services
• Easier to use extension points
• RESTful support
• Support for a “bare” XML binding, which doesn’t include a SOAP envelope

Most XFire services that you have written should be compatabile out of the box with CXF. You will however have to change your deployment code or xml configuration to take advantage of the improved APIs and improved XML format. See the XFire migration guide for some more details.

There has been a question or two about why we are announcing a release candidate as people don’t often announce RCs. There are a couple reasons. First, we’re attempting to finish the JAX-WS TCK testing before we release 2.0 final – although that may wait until 2.0.1. So we wanted to give people a release to use in the meantime. Second, while we’ve had many users testing CXF, we’re sure there are a few bugs out there yet (people have already pointed out a couple which we’re working on fixing). We’d like to throw the release out to the wider community to run through the gauntlet before we declare 2.0 final.

Stefan Tilkov writes today:

The SOAP/WSDL/WS-* SOA view of the world is like a statically typed programming language, i.e. C++ or Java — everything is pre-defined, contracts govern everything, nobody can interact without following formal rules … and ideally, everything violating the rules (and policies) will get caught before even going into production.

RESTful HTTP is like a dynamic programming language (i.e. Smalltalk, Ruby, Python, etc.) — you’ll only find out at runtime whether things actually work together, and might well run into errors that would have been caught by a rigorous (and strict) rule-checking process up front; but on the other hand, you have a much more dynamic system, where you can add and remove and change stuff on the fly, and even have some means to react to errors dynamically.

While that may be how things are currently, I don’t know that SOAP and WS-* necessarily implies such an approach (although WSDL may), nor do I think that RESTful services preclude a more static approach.

For instance, I can send messages over a JAX-WS Provider/Dispatch instances without any typing at all. Also, WS standards like WS-Security, WS-RM, etc are supposed to operate in a transparent way, so they shouldn’t affect how you build your service and the amount of “typing” needed. Just like SSL is transparent with HTTP, so these should theoretically be transparent. We also have people like Arjen arguing for a more dynamic approach (I really need to follow on that post too!).

On the other hand we have things like WADL which are bring a more contract oriented approach to RESTful services. The thing that does seem more dynamic about RESTful services is it’s linkability. Where as WSDL based services have operations which are very static, a RESTful data model will provide links for me to navigate. However, I still need to understand the various content-types and data structures. We can exchange these via a contract, put it in documentation, or let the user figure it out for themselves.

I’m just finishing my stay here in Amsterdam where ApacheCon EU was hosted. It was a good conference, and like most ApacheCons, thats because of the people here.

I gave two talks this week. The first was Secure, scalable and reliable RESTful services. Its always fun to talk about REST at ApacheCon, because the members/committers are the definitely experts in the area and everyone has an opinion to voice . It was a good time though, and hopefully it was informative for some of the non HTTPD committers in the room!

The second was Navigating WS-(death?)*. It wasn’t so much WS-* bashing as trying to help people understand why these specifications sprang into existinence (it all flows from the concept of a transport neutral, message oriented system), how they work, who interoperates with the various standards and if they should consider using them. I focused mainly on WS-Addressing, WS-ReliableMessaging, WS-Policy, and WS-SX*.

I’m off to home tonight, and then off to JavaOne on Sunday. See you all there!