Software, Interrupted

As much as Twitter is a powerful communication and social application, it's a relatively simple Web app. As part of a new contest sponsored by Engine Yard, Ruby on Rails developers are going to turn Twitter into their own application server.

The contest asks developers to program the "Worst App Server Technology Ever" (Waste) using Twitter as the message bus. While much of the contest is being done tongue-in-cheek, it's actually an interesting use case to see if a service like Twitter can take the place of a more traditional message bus like IBM MQ series or AMQP (Advanced Message Queuing Protocol).

Contest participants register up to five Twitter handles and code the function that each would perform in a program. When the contest challenge is issued on November 12, participants will have to use at least 10 of the pre-designated Twitter handles (other than their own) as endpoints to perform functions on data sets located at unique URLs. All messages will work through a series of automated public Twitter replies.

This is somewhere between an application server, a social game, the "telephone game" and service-oriented architecture (SOA) where Twitter plays the role of the enterprise service bus and the Twitter API is the broker between data sources. SOA relies on services exposing their functionality other applications and services can read to understand how to utilize those services. In this case, Twitter can be used as an application server in the cloud. (Take that buzzword bingo players.)

The funny thing is that as absurd and comical as this sounded when the Engine Yard guys told me about it, I've started to think about this as a way to possibly achieve a real technological breakthrough. And while I don't think that Twitter will be the "cloud bus," I do think that there is a lot to be learned from applying this type of constraint to a data flow process.

Engine Yard VP of marketing Michael Mullany told me that the contest shows how developers can leverage a relatively straightforward platform in innovative ways. But it's also another example of an interesting marketing effort to use Twitter as the vehicle for one's own benefit. Also, in true open source fashion, developers wind up building new applications based on code written by their peers.

Let's hope Twitter can handle the attention and developers are not greeted by the ever-lurking fail whale. You can check out the contest and learn more details at Engineyard.com

Web-oriented architecture (WOA), a descriptive term for a subset of service- oriented architecture (SOA), has recently arisen as the next buzz-phrase to help further confuse the IT architect.

WOA is simply a way of implementing SOA by creating services that are RESTful resources, allowing any service or data to be accessed with a URI. (REST, by the way, stands for representational state transfer. And URI is short for uniform resource identifier.)

For many scenarios, this method dramatically simplifies things over the traditional WS-* approach. WOA resources are stateless and self-descriptive. Additionally, building SOA across intra-enterprise and in-the-cloud services becomes much easier with WOA.

As defined by Gartner's Nick Gall (thanks to Rob Eamon for the pointer):
Long version: WOA is an architectural style that is a substyle of SOA based on the architecture of the www with the following additional constraints: globally linked, decentralized, and uniform intermediary processing of application state via self-describing messages.

Shorthand version: WOA = SOA + WWW + REST

To be clear, the WOA approach is not ideal for every scenario. As with any architectural style, there are trade-offs. Any application that requires a real-time, event-based action or response, for example, can't be easily built in the WOA way (at least without crippling the system with constant polling). For the enterprise architecture with any level of complexity, no one approach will fit all needs.

Add in the inevitable enterprise mix of legacy applications, existing investments in SOAP-style SOA, and point-to-point integration infrastructure, and it becomes clear that the true pure-play WOA will be all but nonexistent.

As with so much of the landscape of service-oriented architecture, large vendors with extensive marketing departments have tried to prescribe how their software should be used to solve specific problems instead of investing in the bigger SOA picture.

Software is the enabler for the broader SOA project, but you need to have a baseline understanding in place before software becomes practical. At a minimum you need to know the problem you are solving before you choose software packages.

Dave Linthicum blogged about this subject this morning:

The fact of the matter is that SOA governance, and governance in general, is really a people and process thing, with technology only coming into play to automate the processes and support the people. If you don't establish that, you're going to fail at SOA governance and thus fail at SOA, no matter how much technology you invest in.

I would push a bit further (without blatantly shilling) that SOA governance makes a lot of sense to be open source. Instead of forcing users into a technology, open-source tools allow them to manipulate the software to their business. And with frictionless distribution (meaning you can get the software without having to pay license fees first), there is an obvious appeal to enterprise users.

Contrary to what many people think, there are a great many SOA success stories starting to pop up (more on that later--I am doing a Webinar this week). We're now starting to get to the meat of solving enterprise problems rather than forcing models, stacks, and "an SOA" on users.

Disclosure: my company sells an open-source SOA governance product.

There aren't yet many practical demonstrations of how you actually use cloud services like Amazon's Elastic Compute Cloud, or EC2. To put my money where my mouth is, I coerced Kevin, my IT guy, into setting up and deploying one of our products on Amazon EC2.

Disclosure: Lest you think I am trying to shill, we obviously used our own software for this proof of concept. Mule Galaxy is a service-oriented architecture governance platform with built-in registry and repository. It's written in Java and is GPLv2 licensed.

We are using the EC2 instance of Galaxy for customer demo purposes and to prove out the cloud as a deployment option. Odds are most enterprises won't put their SOA governance in the cloud, though there is a strong likelihood that you will have assets that cross your corporate firewall.

The cloud is becoming a more and more realistic deployment option making software consumable in new and interesting ways.

Just how complicated is this cloud thing?

The Amazon toolset has come a long way since the beta launched. In fact, it took us less than an hour to provision a lightweight instance of Fedora 6, install a few missing utilities, set a couple of environment variables, and launch Galaxy.

Here are the basic steps, followed by the nitty-gritty details for each section:

I was going to write something up about this announcement "Sun Microsystems and Intel Break Million-Messages-per Second Barrier for Thomson Reuters Market Data System" and relate it to how Twitter could leverage some design principles from financial services for scalability.

Then I clicked on the link to the Sun webpage for FinServ only to find out they had announced nearly the same exact thing two years ago.

A million-messages-per-second is still very impressive, but this is hardly news. Where is all the news about Sun's SOA, Cloud, or MySQL efforts?

UPDATED JULY 9, 2008:
The fine folks at Sun's financial services group have provided some clarity on the two RMDS benchmark announcements.

We should have articulated more clearly the differences between the two benchmark results. If we used the exact same configuration for the old benchmark, we have actually broken 3.05 million-messages-per second. This information was buried in the bullet points in our press release.

Our new benchmark with the one-million-messages-per second result was actually based on a different product--Source Distributor--that is under the same RMDS product suite. Sun and Intel was actually the first platform to have broken the one-million-messages-per second benchmark for the Source Distributor product. This information was also buried in the bullet points in our press release.

Over on ZDNet Joe McKendrick asks Is Microsoft slow to the punch on SOA, or just waiting for the right moment? The answer is neither. Microsoft is clueless about SOA (service oriented architecture) and seems intent to remain so.

Microsoft can't seem to figure out what it wants to be anymore. In this day and age the company simply can't be all things to all people. It's clear that after the Yahoo fiasco, the focus is on the business "user" and the consumer. There has been very little in the last year or two that suggest Microsoft is taking the enterprise seriously anymore. Even all the noise about Linux has stopped.

Fundamentally I think the Microsoft SOA challenge is due to the fact that most SOA environments are multi-vendor. Even when Oracle is giving away components and trying to shove a whole stack down your throat they realize that interoperability is key to success. Microsoft has *never* embraced interop at full-scale. If they had, the market would be very different right now and arguably Microsoft would have an even bigger footprint.

Joe makes a point below that Microsoft will likely attempt to go bottom-up with SOA as it's still too large of an undertaking.

Microsoft typically hasn't gone head-to-head against large enterprise vendors, especially with SOA. And my guess is that Microsoft doesn't even want to attempt to try to take away or eat into IBM or BEA/Oracle's huge SOA engagements. It's not worth it -- at least not yet. Instead, Microsoft intends to move into underserved and long-ignored markets with commodity-priced tools and work their way up from there.

I agree to the extent that the opportunities will still be there for Microsoft once these initial deployments are done. One of the main reasons I still work like a dog is because consumption equals deployment in 99.9% of our use cases with Mule. The odds of another vendor pushing out existing infrastructure is very low and Microsoft is missing the boat.

I just took the SOA IQ test over at ebizQ and scored my way into the SOA boardroom.

I'm trying to think of another area of technology that has more acronyms than SOA (service-oriented architecture) does...maybe networking? It's amazing how many acronyms you can put into 10 questions.

Nice job by the ebizQ team in putting the quiz together. Anything that makes technology fun or interesting is a win in my book.

One of the more interesting enterprise IT topics of late is the realization that there are "shadow" or "rogue" IT efforts at a vast majority of companies. These efforts are often how open source applications gain a foothold and lead to "legitimate" usage.

SOA magazine has a good overview of Shadow IT and how it relates to SOA.

The term "shadow IT" was coined for systems built without corporate approval inside business units, departments and whole subsidiaries. Born from the IT backlogs of every organization, shadow IT can drive innovation and effectiveness without hindering larger IT evolution. While organizations wrestle to centralize their applications, the reality is shadow IT is not going away. As such, it is most effective to ensure the sustainability of shadow IT instead of attempting to avoid it.

I think it's a great thing to see the big analyst firms recognize open source products and companies as key players in today's software world. The fact that Gartner has named MuleSource as a "Cool Vendor in SOA Governance" obviously speaks to the quality of the software, but also to the fact that the analysts who have typically been less open source focused (versus say, Red Monk) are realizing the massive impact that we are having on the market.

According to Gartner, "The cost, complexity and potential vendor lock-in of closed-source technology from infrastructure platform vendors have pushed the desire for open-source technologies past operating systems, application servers and enterprise service buses."

If you read into the Gartner quote, they are now also setting themselves up to be able to talk about open source applications and other infrastructure components. The times sure are changing.

Mule Galaxy is available for download and is licensed under the GPL v2.

Disclosure: I work for MuleSource.