Pete Lacey’s Weblog

… to bring you this important science fiction update.

Please read everything that John Scalzi has written. And in the event that you have not already read Vernor Vinge’s latest, Rainbows End, then read that too.

We now return you to your regularly scheduled blogging already in progress.

… and now SCA and SDO have been sent to OASIS. When will the madness stop?

Update: I took the time to look more closely and it looks like Netvibes is using client side Javascript to fetch feeds.  I guess that’s no different than if the user had a dedicated news client, but it sure would be nice if (a) Netvibes cached my feed locally and had all its users pull it from the cache, or (b) set the Referrer header to “-”.

I took a look at my Web server stats for the first time in a while and saw this.

Now, I know that Netvibes is getting some traction out there, but they can’t be this popular. Heck, I’m not this popular. Looking at the logs directly, it seems that Netvibes is setting the Referrer header when they’re just getting my feed. Not only that, the User-Agent varies from request to request (various versions of Firefox on Windows, OS X, and Ubuntu). But wait there’s more, Netvibes also does a normal feed fetch (empty Referrer, User-Agent set to “Netvibes”) every 45 minutes or so.

So here’s my theory. From the looks of it I have 21 subscribers via Netvibes. I suspect that Netvibes is not only fetching my feed as you would expect it to, but it is also fetching it 21 additional times every X amount of time. And for these fetches it’s setting the Referrer to netvibes.com and using the actual browser and OS combination of the subscriber in the UA header. At first I thought that Netvibes might be serving up some local JavaScript to do the fetch, but the IP addresses aren’t random enough. Anyone have any other thoughts on this?

I included a few extra lines in the stats picture so you can see that last entry. Apparently some robot that’s trying to crack phpBB (which I don’t use) sets its referrer field to “forum.{your_domain}” when it connects to your site. That’s annoying.

Update: Hao He is no longer unknown to me. Turns out he’s the CTO of SoftTouch Information Technology, has a doctorate in quantum optics (!), and has written some articles on REST and Web Services for XML.com. See comments.

Dr. Hao He left the following comment in an earlier post.

I think what is missing here is an architectural comparision between REST and the MOM, which is very popular among enterprises.

The main selling point of WS-* for enterprises is that they will be able to get a standard based ESB, which should be good enough for enterprise SOA.

The fundamental question is:”Is it MOM really good enough for enterprises so they can ignore REST?”

Any thoughts on this?

This is the kind of thing I hear routinely as part of my day job. Not the REST bit, but the SOA bit. The interesting thing about this comment is not the question per se, but the underlying subtext. Which is that WS-*, ESBs, and such provide the simplest substrate for distributed computing in the enterprise, and that using and deploying such technologies gives you instant SOA, the font from which all good things pour forth. It’s really rather fascinating.

To directly answer Hao’s question, however, I have to get a little terminology and positioning straight.

MOM: Message-Oriented Middleware. This is potentially a very large category of software, but I use the term fairly narrowly. To me MOM is infrastructure software that is responsible for delivering messages among components in a networked system. MOM’s implement a (typically proprietary) layer 7 transport protocol (though they ride a fine line with being application protocols) offering features in excess of straight TCP. A message is an arbitrary collection of bits. A MOM may deliver a message in a point-to-point fashion or it may be brokered. Delivery may be request/reply, fire-and-forget, synchronous or asynchronous. A MOM may offer publish-and-subscribe functionality using topics (many subscribers) or queues (one subscriber). A MOM may offer reliable message delivery, message ordering, and/or other delivery guarantees (e.g. exactly once). Today’s MOM products are robust, performant, and highly available. Representative products include IBM’s WebSphere MQ (ne MQ Series), TIBCO’s Rendezvous and EMS, Sonic’s SonicMQ, Microsoft’s MSMQ, and the open source JBoss Messaging, and various implementations of the open standard AMQP.

ESB: Enterprise Service Bus. Today an ESB is largely a marketing term meaning whatever a particular vendor wants it to mean. However, we can narrow it down somewhat. An ESB is a lightweight integration broker - nothing more and nothing less. It takes messages in over a variety of transports and protocols, typically normalizes these messages to some internal representation, and then either calls a locally hosted service or denormalizes the message and calls a remote service. Thus the principal features that an ESB offers are message transformation and routing and protocol brokering. An ESB may or may not be a JBI container or JBI compliant. An ESB can be distributed, they should not use a hub-and-spoke architecture. The typical messaging protocols supported are SOAP and one or MOMs (via JMS or natively). This MOM support allows for ESBs to subsume all or most of what a MOM does. In addition ESBs may offer connectivity adapters to a variety of legacy systems.

It’s instructive to understand what an ESB is not. An ESB is not a mandatory component of a SOA architecture. Yes, it is recommended that some intermediary be positioned between endpoints, but ESBs are not necessarily the best choice. An ESB is a tool you may use to integrate a variety of systems. And in this sense, it can be a very useful tool. But remember, the goal of SOA is not to integrate everything with everything, it is to get most things speaking the same language (whether that be RESTful HTTP or SOAP or whatnot), so that the need for integration brokers is greatly diminished. Other intermediaries you will likely need in your environment include XML appliances and SOA management systems. Representative ESB products are Sonic’s Sonic ESB, Fiorano ESBs, BEA’s AquaLogic Service Bus, IBM’s WebSphere ESB, and Oracle’s ESB. There’s also a wealth of open source ESBs including: Mule, Apache’s ServiceMix, and Celtix.

To sum up: MOM’s good. ESBs useful (on the edge). To Hao’s point then, an ESB is not good enough for enterprise SOA. You can’t buy SOA, you do SOA.

In the past I’ve provided my view on positioning REST, WS-*, and MOM (here, here, and here). In summary, due to the reach, effectiveness, and relative simplicity of REST, that should be your default position for distributed computing. If the features of a MOM are necessary, then use a MOM (though the resulting system will not be RESTful). Use WS-* only when you need to talk to something that exposes only a WS-* interface.

Remember, REST is an architectural style whose sole manifestation today is the HTTP application protocol. MOM is a transport, offering a variety of useful messaging models and other features. And WS-*, well, no one’s really sure how to nail down what WS-* is. It’s a little bit of everything, and that’s a large part of the problem.

So, Hao, ignore REST at your own peril. Yes, MOM’s can be effective, but that’s just a means of getting bits from point A to point B. The fundamental question is really, “Is REST really good enough for enterprises so they can ignore WS-*?” And the answer is yes, for a significant subset of use cases. For the rest, architect a solution around a MOM.

One of the reasons why RESTful applications have made little headway in the enterprise is we don’t have nifty things like maturity models. To remedy this, I have created the ROA Maturity Model.

Click image or here for full view (HTML in new window).

Note, I’m not picking on Sonic, it’s just that their model comes up first when you Google “SOA Maturity Model.”

If you’re trying to get your arms around this whole REST thing, then the RESTian posts of the last few weeks have made that job a whole lot easier.

David Meggison starts things off with REST: the quick pitch. Including this wonderful elevator pitch: “With REST, every piece of information has its own URL.”

Then Joe Gregorio offers up two gems: REST and WS-*, which is sort of a condensed version of his XML.com series “The RESTful Web,” and (building on David’s post) “REST Tips: URI space is infinite.”

Mark Nottingham provides a summary of “REST Issues, Real and Imagined” that should help put to bed some of the FUD surrounding REST.

And then there’s Benjamin Carlyle’s Sound Advice blog. Man, I wish I could think like that. Benjamin has hit the trifecta with his most recent three postings (but you should really go back and read all of them): Remixing REST: Verbs and Interaction Patterns, The Architectural Spectrum, and You are already doing REST. Unlike others, e.g. myself, Benjamin doesn’t toss out the baby with the WS-BathWater, but instead provides reasoned, insightful explorations of distributed computing. A representative quote from “The Architectural Spectrum:”

Network effects are still important, even in relatively small architectures. This means that it is still worthwhile following constraints such as the uniform interface. There is no point splitting your architecture up into point-to-point integration pairs when you could just as easily have ten or twenty components participating in an architecture and working together for the same cost. The main areas that REST constraints can be relaxed in involve scalability evolvability, and even there you have something of a newtonian vs einsteinian issue. You may not see the effects of relativity when you are travelling at 60Kph, but they are there. Sure enough, when you really get up to speed at 1/4 the speed of light you’ll know it. Every architect should be aware of the constraints and the effect of bending them.

Do yourself a favor and subscribe.

Regrettably, I had to miss the last three hours of the Web of Services for Enterprise Computing workshop. Here, though, is as brief a summary of the first day and a half as possible:
It seemed to me that the room divided into two groups. One group wants the world to stop so they can model it—they want more specs and more control. The other group doesn’t.

Some more sweeping generalizations: WSDL 2.0 got the shit kicked out of it by both groups, but there was a lot of love for WADL. The WS-I is apparently a lost cause, and the WCF is the new web services profile. And where the heck is Microsoft anyway?

It was also a great pleasure to put faces to the names of many people I knew only via their online presence: Mark Baker, Mark Nottingham, Mark Hadley, Dave Orchard, Paul Downey, Nick Gall, Eric Newcomer.

72 prior comments. 186 inbound links. And the only one who doesn’t get it is the VP of Technology at WS02.