netzooid

I hate building webapps. I’ve even gone so far as to swear that I would never work on another.

I guess I lied as I need to select a web app framework for an application.

I’m poking around at frameworks, and well, I’m lazy. Maybe you can help. I’m thinking of:

• Stripes - James raved about it a while back. Possibly shiny object of the day though.
• Struts 2 - Hooray for simple action based frameworks.

Things I’m not thinking about:

• Tapestry - sorry Howard, my mind doesn’t work like yours.
• Seam - Its JSF, which seems (no pun intended) to mean it will still suck. Is everything still required to be a POST?
• jRoR - I’m not ready to introduce a new language into the mix
• Grails - see above
• Spring Web Flow - seems to require a helluva lot of XML. I could be wrong.

Thoughts?

Fake Steve

Ahhh crap - Fake Steve has been revealed and he works for Forbes. I was hoping the revealing would be more dramatic than this. Maybe involving lawsuits. Will it keep its charm? Or will it turn into a Forbes marketing ploy? Whatever the outcome, Jaysus, we need more posts with Bono!

Dopplr

I started using to Dopplr to track all my trips and my friend’s trips. The interface kinda sucks, but my life is still better off with it than without it. My #1 feature wish is for the ability to give trips names. I.e. get Septemeber 13 & 14 to be called “JavaZone” instead of “Oslo, Norway” in my calendar.

I have several invites if people want to join up. I recommend it especially if you travel a lot and like to see who will be where you’re travelling. If you’re already on there, add me as a fellow traveller!

Conference Season

Speaking of travelling, there are too many conferences coming up: JavaZone, QCon, Oredev, ApacheCon US, OS Summit Asia, and possibly others…

CXF 2.0.1

We’re voting on it right now. Well technically the Apache Incubator PMC members are voting on it. Hopefully it will pass in a day or two. If all goes well we’ll have a follow up release with bug fixes and new features in under 5 weeks! Pretty good, eh?

Its also our one year anniversary - check out Dan Kulp’s retrospective for a good recap!

Thomas just announced that JBoss has been working on making their WS layer pluggable. In addition to supporting the native JBossWS framework, CXF and Metro (the project formerly know as the JAX-WS RI + Tango) integration code will be added for the 2.1.0 release as well. Among other things, this should help make it easier for CXF/Metro users to deploy services and create EJB backed web services inside JBoss.

I’m very happy to see this. Its not uncommon for me to visit a customer who is mixing different stacks together. Its part of the promise of open source, you can pick the best technologies (dare I use the marketing term - best of breed), and integrate them together.

Its great to see JBoss/RedHat support this approach.

<horn-tooting>

Coincidentally, why might you want to use CXF within JBoss [1][2]?

• Spring integration - we have lots of lovely support for the Spring 2.0 syntax. Its trivial to make a Spring bean a web service. Just write a <jaxws:endpoint … /> snippet and you’re done It equally trivial to inject a WS client into your application.
• JAX-WS frontend - Use the standard JAX-WS APIs to build your services via annotations
• Simple frontend - CXF supports the building of services with no annotations needed through the simple frontend. It works well in conjunction with the Aegis databinding, which can generate schemas from just about anything - including Map<Foo, Bar> constructs (maybe someday JAXB will support that).
• RESTful services via annotations
• WS-* support - including Addressing, Policy, Security, and ReliableMessaging
• The ability to work with non-XML data like JSON
• Maven Plugins

</horn-tooting>
1. Important: this is not to imply that the JBossWS Native or Metro does not have any particular one of these features, I just think it is this combination that makes CXF unique.

2. Disclaimer: The JBossWS code is an ongoing effort and the CXF code still isn’t quite ready yet AFAIK. I would encourage you to get involved though if this interests you. Also, CXF can still be run standalone inside JBoss in the mean time - many users do that already.

Most web service frameworks provide some way for you to intercept and work with the raw messages that it receives. In JAX-WS this comes in the form of Handlers. Through these handlers you can either work with the raw protocol message (i.e. the XML DOM) or the logicial message (i.e. the databound objects).

In CXF, this comes in the form of Interceptors. Nearly all CXF functionality is built on interceptors. When a transport receives a message, it does as little work as possible, creates a Message object, and then sends that Message off through an InterceptorChain.

One of the things that I think is unique about CXF’s Interceptor support is its ability to make working with low level I/O streams and non XML formats easy for the developer. I want to explore that momentarily and show how you can easily create a GZip Interceptor.

An Interceptor in it’s rawest form is simply a handleMessage() method. There are some other support methods, but we can focus on just the important stuff by extending AbstractPhaseInterceptor:

public class MyInterceptor extends AbstractInterceptor {
 public MyInterceptor() {
  super(Phase.USER_STREAM);
 }
 public void handleMessage(Message message) throws Fault {
  System.out.println("Hello World!");
 }
}

When an endpoint receives a message, this interceptor will run in the USER_STREAM phase and print out “Hello World.” Now how do we work with the low level InputStream?

InputStream stream = message.getContent(InputStream.class);
GZIPInputStream gzip = new GZIPInputStream(stream);
message.setContent(InputStream.class, gzip);

The CXF Message stores multiple content formats which you can easily access via the “T getContent(Class<T> type)” API. An InputStream is one. XMLStreamReader, List
<Object>, SAAJMessage.class, etc are all other possibilities at well. Its perfectly valid for their to be multiple valid formats at once. For instance, we can have both an XML document and a List of databound objects at late points in the chain.

In the final line of the above example, we can replace the InputStream that was set by the transport with our new GZIPInputStream. Its all pretty simple. So whats the big deal?

Well most web service frameworks (including XFire), only provide an XML document to their message processing engine. In CXF, ALL the binding specific details, including transport level details like recognizing attachments and finding the most appropriate data format, are handled in Interceptors. This ultimately makes the transports much cleaner and more flexible. You don’t need a SOAP specific HTTP transport or a RESTful HTTP specific transport. You just have an HTTP transport and all the protocol details get handled by the Interceptors supplied by the bindings.

It also makes several things possible which weren’t before with XFire. One of these things is working with non-XML data. Another important use case is message routing. Since CXF is just a generic message handling framework, you can route based on some criteria (i.e. SOAP or HTTP headers) and copy the message to its destination without parsing the whole thing.

P.S. CXF 2.0 final is being voted on now… Hopefully we’ll have an announcement soon!

I’m at BarCampChicago today. Just got here, but so far so good. I already like the first talk - The Future of Software is Hardware. He’s talking about the growing trend of personalization in the world - i.e. desktop fabrication, or threadless. Also, they have more beer, wine and alcohol than any other event I’ve been to of this size.

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.)

Jason van Zyl announces in his blog:

Since my departure from Mergere I’ve been quietly and steadily working to help start a Maven related company that I’m proud to say I’m a part of. No grandiose launch, no marketing hype, no VCs, haven’t talked to a single analyst, and we hope that you can actually understand what we do by looking at our website. The company’s name is Sonatype and I’m finally happy with the people involved and the direction we’re headed in. We are focused on facilitating the adoption of Maven through our partners network, providing training, and delivering Maven related products for software development.

I’m excited to see an open source business that is as strongly focused on their customers and their business as I know these guys are. They’re great people, and great companies can’t help but come from great people.

Envoi Solutions is proud to be one of Sonatype’s partners. We’re in the process of working on various solutions to help people develop web service/SOA projects more effectively - including a set of archetypes around CXF/XFire.

Congratulations to Jason, Neel, John, Kenney, Eric and the many others involved!

From Richard Gray’s comment on Jon Udell’s blog:

So long as our online identities are fragile and easily compromised people will be wary to trust them. If we lower the probability of an identity failing, people will, as a result, place more faith in that identity. But if we can’t reduce the probability of failure to zero then when some pour soul suffers the inevitable failure of their identity, so many more people will have placed faith in it that undoing the damage may be almost impossible. It would seem then that the unreliability of our identity is in fact our last line of defence.

I think the potential for web identity theft is very high - someone could go around claiming to be me destroying my reputation and make googling me turn up very bad things. In my case, my blog’s rank in Google might give me the first say with anyone researching me. But I feel sorry for those poor schmucks who have no link love for their own web page and have someone impersonating them online.

Update: Kyle Adams writes in with this account -

Hey Dan, just wanted to let you know that my church is actually stuck in the same situation. Due to a botched hand-off between myself and the previous webmaster, the domain name expired. Godaddy.com actually held onto the domain name for renewal for awhile, but once it got into that limbo neither of us could actually figure out how to renew it.

When the dust settled, a pornographer ended up with the church’s old domain name. Worse still, he used the church’s front page + a bunch of links at the bottom to various sites, probably in an attempt to boost Google rankings. We now have a new domain name (not through godaddy.com) but I’m not really sure how to rescue our old domain from being soiled.

The old website is at http://www.calvincrchurch.com/ - careful though, it locks up my browser. And to give the new website some link-love for Google to boost its page rank, here is the correct Calvin CRC Church website.

Stefan Tilkov has been doing a good job covering the ongoing discussion of how to do POSTs reliably.

All the solutions for a reliable POST seem ugly. Stefan ultimately suggests:

1. POST to the http://example.com/purchase-orders/new URI and have it return 201 Created and the URI for the new resource in the Location: header.
2. PUT the intended content to the URI, possibly repeatedly in case of error.

While it has beauty in consistency, it seems less than ideal to require two invocations for an addition of a resource reliably.

On the other hand we have WS-RM. The nice thing about WS-RM is that it is transparent, even if it does take a message based approach instead of a resource based one. However, WS-RM is XML only. One of the major benefits of going down the RESTful route in my opinion is that works with any type of resource. This is one reason I don’t really see the WS-* and REST camps merging together.

Last year I started a project which is called SXC, or simple XML compiler. This project has gone through a couple revisions (and name changes), but I think its finally ready to talk about. The core of SXC is an API which allows you to declaritively say what type of XML you’re expecting to be parsing or writing. You can then attach actions to perform when you encounter/write that xml. For instance, you can say I’m expecting the “customer” element and I want to do “new Customer()” when I get there. It will then compile an optimized XML parser for you.

SXC includes 3 frontends in addition to its core APIs, and these are probably what you really care about:

• JAXB: SXC uses the JAXB annotations to drive compilation of an optimized parser/writer for you at runtime. Why would you do this? It is 2-3x faster on the reading side, and about 20-90% faster on the writing side of things. (See below for more important details). We do not claim JAXB compliance yet, but we support most common JAXB functionality. It has been tested with both CXF and XFire. Note: we aren’t trying to replace the JAXB RI here, we’re augmenting it. You still need to use XJC to compile your schemas and keep the RI around at runtime.
• XPath: SXC can compile down XPath expressions and build an optimized streaming xpath parser for them. Through an XPath event API, you can listen for multiple events as you scan a document. Currently we only support a vey limited subset of XPath expressions, but my hope is it will grow significantly as time goes on. On a VERY ROUGH test (did I mention this was very rough?) it performed about 100x faster than Jaxen for repeated evaluations on a DOM with expressions like “/foo/bar[@bleh='biz']/baz[text()]“.
• Drools: Now that we have a streaming XPath parser, whats the next logical step? Efficient content based message routing using rules! Through Drools and SXC you can create a very efficient XPath based message router. Rules will fire as your XPath criteria are met and you can take action. I’m sure there are many other uses for Drools+XPath, but this is one at the forefront of my mind.

Going Deeper…

Maybe that is a lot to understand, well how about some code to help? Check out the parser example on the website. Here is a quick outline of how building a parser works:

• Create a SXC ElementParserBuilder
• Call: elementParserBuilder.expectElement(new QName(”customer”));
• Tell SXC to create a new Customer object and return it. This happens using the excellent Sun CodeModel API which allows you to declaritivley create Java files.
• Call builder.compile(). This will generate Java files and compile them in the background at runtime. It will then pass you a Context class.
• Use the Context class to get a Reader optimized for your XML needs

SXC opens up a realm of possibilities with respect to databinding. One of the cool things I like about SXC is it makes it really easy to try different ways to databinding. The JAXB related code is a total of 2500 lines. Pretty much any databinding toolkit could be rewritten to use it too.

Another cool thing, which is slated for a future release, is inline validation. If you think about how much performance is lost when validating navigating a DOM, changing strings to ints over again, etc, when doing validation, it is a lot. We should be able to inline most, if not all validation, right into the parser. For instance, if you were limiting a value to between 1 and 10, we could simply add an if statement - if (num < 1 || num > 10) throw ValidationException(). Of course it gets a lot trickier than that thanks to the lovely specification known as XML Schema (*cough*), but the idea is there and with some work it should be doable.

JAXB Performance

I’ve prepared a few initial benchmarks: read performance and write performance.

As with all benchmarks, you may want to keep several things in mind:

• Depending on your own document types, performance will vary. If you have a lot of textual content (as opposed to small textual values), you are likely to benefit less from SXC.
• This was done on my 2GHz T60 Core Duo laptop. The FSB is 667 MHz. With a faster bus my suspsicion is that SXC performance would probably improve.
• The JAXB RI does have an output mode that is faster - if you write directly to an OutputStream with UTF-8. I haven’t done benchmarks to compare it yet to SXC though.

Future

There are many things I’d like to look at for the future revisions:

• Simplifying and documenting the SXC APIs
• Passing the JAXB TCK
• Better XPath support
• XSLT support?
• Inline schema validation

If any of this sounds up your ally, or you have other ideas for SXC, be sure to join the mailing list or contact me at dan AT netzooid dot com.

Enjoy and report back on your experiences!