netzooid

Found this quote from Roy Fielding in 2003 while I was poking around for my talk on scalable, secure, & reliable RESTful services:

Why is there no WSDL for REST? Because HTML is the WSDL for REST, often supplemented by less understandable choreography mechanisms (e.g., javascript). That usually doesn’t sit well with most “real” application designers, but the fact of the matter is that this combination is just as powerful (albeit more ugly) as any other language for informing clients how to interact with services. We could obviously come up with better representation languages (e.g., XML) and better client-side behavior definition languages, but most such efforts were killed by the Java PR machine. Besides, the best services are those for which interaction is an obvious process of getting from the application state you are in to the state where you want to be, and that can be accomplished simply by defining decent data types for the representations.

Sorry Roy, but ugliness matters. If it didn’t matter I probably wouldn’t care about REST. But there is something very nice about a uniform interface, URLs, etc. I will agree that proper resource oriented data types do make a big difference, but the issue to me is how do I even communicate that some datatype is available? If I’m supposed to define my own content types, surely I need a way to communicate what the some of the possibilities are and what they represent? Not everyone is going to understand application/purchase-order+xml off the bat. And surely application/purchase-order+xml might mean different things in different contexts - i.e. different companies or divisions.

I would also argue that HTML is insufficient for this, but thats for Some Other Day when I can actually finish off a larger blog post on the issue :-).

I’m excited to announce that we’ll be exhibiting at JavaOne this year. We’ll have a booth and will be around to talk about CXF, XFire, SXC, Jettison, web services (both the Just HTTP and WS-* kind), SOA, etc.

If you’re going to be a JavaOne, stop on by or send an email and lets meet up! If you don’t have a pass and will be in San Francisco, we have several JavaOne pavillion passes to give away yet. You can reach me at dan AT netzooid dot com.

I should also be at the CommunityOne event/RedMonk Unconference on Monday. It sounds quite enjoyable.

Hope to see you all there!

At Dim’s suggestion, I’d like to spend a few moments going over one of the underlying components of our policy framework in CXF - Apache Neethi.

Neethi provides an object model for working with Policy expressions. In some sense its the WSDL4J equivalent in the policy world. It provides a common model for both 1.2 and 1.5 policy expressions. For instance, here is a snippet which creates a Policy which says that MTOM is optional:

Policy policy = new Policy();
ExactlyOne exactlyOne = new ExactlyOne();
All all1 = new All();
Assertion a = new PrimitiveAssertion(
new QName("http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization",
"OptimizedMimeSerialization"));
all1.addPolicyComponent(a);
exactlyOne.addPolicyComponent(all1);
exactlyOne.addPolicyComponent(new All());


ExactlyOne and All are policy components which contain other components. ExactlyOne states that ONE of it’s policy components MUST be matched for a particular message/invocation. An All component states that ALL of it’s policy components MUST be matched for a particular message/invocation.

The first policy component that we set up here (all1) contains an MTOM Policy Assertion. The Assertion class represents this, provides Neethi with the assertion QName, and is able to normalize/serialize itself. The PrimitiveAssertion class is an implementation of the Assertion interface which resides in CXF. Its a very simple class which just creates an assertion around a particular QName. In essence, it just represents the XML <mtom:OptimizedMimeSerialization>.

The second policy component is an All with no assertions. Since both of the Alls reside in the ExactlyOne, the net effect is a Policy which says that MTOM is optional:

<Policy>
<ExactlyOne>
<All>
<mtom:OptimizedMimeSerialization/>
</All>
<All/>
</ExactlyOne>
</Policy>


This seems rather verbose, and it is. Luckily there is a way to shorten this:

<wsp:Policy>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
</wsp:Policy>

And this leads us to the concept of normalization. The first Policy snippet is a normalized version of the second one. Whenever an Optional=”true” attribute is encountered that means that the particular policy assertion that is optional can be transformed into two <All>s in an <ExactlyOne>. While its more verbose, its a bit more machine friendly when you’re trying to look through and figure out if any of the Policies were met.

Neethi also includes an AssertionBuilder class which builds these assertions from AXIOM elements. As we’re trying to reduce the amount of dependencies needed for CXF, we opted to create our own version of the AssertionBuilder class which uses DOM elements instead. We have a few implementations of the AssertionBuilder floating around, but one of the most interesting is probably the JaxbAssertionBuilder. This builder can build an assertion from a JAXB object. This makes it trivial to add new assertions. Just write your schema, generate your JAXB beans, and tell CXF to look for the new assertion builder.

All in all, I’m pretty pleased with the model Neethi has given us. If I could change one thing though, I would separate out the AXIOM dependant interfaces into a separate package. And similarly with the DOM implementations that we’ve written. However at this point (post 2.0 release), I don’t think its really possible so I haven’t brought it up.

As we near our CXF 2.0-RC release (we’re cutting it today hopefully!), I want to spend a bit more time on my blog talking about CXF, some of the unique things I think we’ve done, and why you should consider it for your projects. Consider this part 1 of n :-).

In CXF we’ve taken the philosophy that we want to leverage the containers and appservers that are out there. Our primary container that we support is Spring. We can also run without Spring, but then you miss out on some of the features.

One of the big new things in Spring 2 is its support for custom XML snippets, meaning we can mix and match any XML types inside a spring config. We’ve added support for configuring clients and servers via this mechanism. Here’s an example of what configuring a JAX-WS endpoint looks like:

<jaxws:endpoint id="helloWorld" class="com.acme.HelloWorld" addressing="http://localhost/helloworld"/>


We expanded this functionality to support various “features” which you can plugin to your service. Features are simply classes which can customize your Server/Client at load time. For instance, I wrote a simple logging feature:

<jaxws:endpoint id="helloWorld" class="com.acme.HelloWorld" addressing="http://localhost/helloworld">
<jaxws:features>
<bean class="org.apache.cxf.feature.LoggingFeature"/>
</jaxws:features>
</jaxws:endpoint>

Notice that you can easily mix & match the Spring syntax and our own jaxws:endpoint syntax. This helps the user as they can leverage the Spring syntax they already know. It also helps developers as it makes creating extensions pretty easy - no XML parsing needed and no schemas need to be written.

CXF and WS-Policy
Before we continue, I’d like to explain a little bit about CXF supports WS-Policy. With WS-Policy I can assert various policies on my service - like that it needs to be using WS-Addressing or it should be using WS-ReliableMessaging. Within CXF there are two things associated with each type of assertion - an AssertionBuilder and a PolicyInterceptorProvider. The AssertionBuilder is responsible for building Assertions classes from XML. The Assertion class is from the Apache Neethi project which provides us with a nice API for working with WS-Policy.

The PolicyInterceptorProvider is where the magic comes in. It allows you to supply interceptors to the CXF message processing chain for whenver your policy is active. For instance, say you are writing support for the <UsingAddressing/> assertion. Then you can have a PolicyInterceptorProvider which provides WS-Addressing Interceptors which get added dynamically to the chain if the policy is active. This means you only have to configure WS-Policy - you don’t have to also configure your service’s interceptors for WS-Addressing.

Bringing together WS-Policy and Spring

The above lays a foundation for simple configuration via WS-Policy. All that you need to do is simply write an assertion for your service and it will get configured correctly (that is, the assertion’s interceptors will be added to interceptor chain).

This merges really well with the Feature framework. We wrote a WSPolicyFeature which understands <Policy> documents embedded inside your <jaxws:endpoint> definition.

<jaxws:endpoint id="helloWorld" class="com.acme.HelloWorld" addressing="http://localhost/helloworld">
<jaxws:features>
<wsp:Policy xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
xmlns:wsam="http://www.w3.org/2007/01/addressing/metadata">
<wsam:Addressing>
<wsp:Policy />
</wsam:Addressing>
</wsp:Policy>
</jaxws:features>
</jaxws:endpoint>

Since this is still Spring, the <Policy> element becomes a WSPolicyFeature Spring bean which you can reference anywhere else inside your code. We simply use the Id attribute on the Policy. This makes it very easy to share Policy configurations across endpoints inside a spring file:

<jaxws:endpoint id="helloWorld" class="com.acme.HelloWorld" addressing="http://localhost/helloworld">
<jaxws:features>
<ref bean="AddressingPolicy"/>
</jaxws:features>
</jaxws:endpoint>

<wsp:Policy wsu:Id="AddressingPolicy"
xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsam="http://www.w3.org/2007/01/addressing/metadata">
<wsam:Addressing>
<wsp:Policy />
</wsam:Addressing>
</wsp:Policy>

You can of course do policy attachments and what not as well, but I’m just focusing on the Spring part of things for now.

More Spring Configuration Coolness
One of the other cool things about this is that we can also apply this configuration to an Endpoint I’ve created via the API through Spring’s AOP mechanisms. For instance, when you create a JAX-WS Endpoint, interally CXF calls into Spring and configures your Endpoint. It finds the appropriate <endpoint> definition using the service’s name. Here’s a sample of a configuration that could be applied to your service:

<jaxws:endpoint id="{http://my.service.namespace}ServicePort" createdFromAPI="true">
<jaxws:features>...</jaxws:features>
</jaxws:endpoint>


Closing Thoughts
All in all, this makes me much more likely to use WS-Policy than I ever thought I would be predisposed to before. I don’t have to write extra XML files and WS-Policy automatically configures features like Addressing, RM, and soon MTOM as well. Much of the credit here goes to Andrea Smyth for doing the WS-Policy layer the AOP configuration stuff. It all looks very cool!

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!

Thanks to Greasemonkey, we finally have a way to delete messages in GMail with just the keyboard instead of using the mouse. Just download Greasemonkey and install this script. The shortcuts added by this script are detailed in more depth here.

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.

Bill de Hora touched on some topics today that I find deserving of more thought:

WS-* as a process, as a technical means designing systems , as a way to generate ‘future business value’ now lacks credibility. This has less to the do with the technology involved and more to do with how the technology has be presented to the market, and consequently how it has evolved.

I completely agree that the way WS-* has evolved has been less than ideal. Part of this is probably just 20/20 hindsight. But contrast the WS-* process to Open ID which seems to have developed from a real simple need and a real implementation within LiveJournal into a standard with a lot of vendor support (hopefully this summary is somewhat accurate). Where as your typical WS-Foo spec has been developed by a committee trying to support every possible use case (granted there is a big quality spectrum here across the different specs, some are much better than others).

I think that people make the mistake of completely writing off WS-* because they assume that the motivations are bad (its those evil vendors!). Yet there are real use cases motivating many of these standards. If people really want to see WS-* go away, they need to start addressing these needs within a web architecture. Or as Bill writes in the comments: “I think we need to talk about how “REST as in the HTTP Web, sucks”, before it becomes another silver bullet. There are definite issues.”

But I think the more important point here is how WS-* presented to market. As Bill says, one of the big issues is that it is marketed as a solution which abstract our problems away. A way to align IT and business!

The problem is that solving and implementing solutions for these problems is just hard in general. Whether you choose WS-* or a RESTful solution, you’re still going to have to worry about performance, scalability, reliability, transactions, etc. I think if you look at the WS-* standards as a way to add complimentary features and support additional use cases (for instance, message level security or security token exchange), you end up with a much more realistic picture than if you view WS-* as abstracting away all your architectual issues. There are different ways to solve these problems of course, but none of them are a silver bullet.