Category Archives: SOA

SOA

SOA

Amazon vs. Google: Services vs. Application Hosting Plus

2 Comments

So everyone’s abuzz about the Google Application Engine. Is it a me-too play on Amazon Web Services? Is this gonna get ugly? (Bloggers love it when it gets ugly!) Here’s the low-down according solely to moi:

Amazon is playing the services game; Google is playing the application environment game. Put more simply: one is doing SOA and the other is doing web application hosting with extras (like authentication.) Then there’s the coupling issue: Amazon loosely-coupled (with some acceptable exceptions regarding S3); Google fully-integrated.

They’re apples and oranges, really. Though I don’t expect that to stop the comparisons and competitive hype. One could certainly take business from the other. There could potentially be plenty of ugliness. Somehow I doubt the Amazon WS team is quaking in its boots just yet.

In the enterprise, Amazon will win hands down. You can use Amazon WS without your business logic or operational data ever leaving your own data center. You can replace SQS with another queue service if you don’t like Amazon’s (assuming you’ve written your interfaces properly!) In the Web 2.0 space, it depends on a few things: 1) marketing, 2) price, 3) reliability, 4) stage in growth of web app–I believe at some point any successful web app will outgrow a sandbox.

As for the Python thing: well, it might have been a smart move. Python developers are quite vocal. If enough of them try and like GAE, the buzz generated might be deafening (see 1, above.) On the downside, if Python developers give it the thumbs down, GAE could have an even steeper curve to climb.

Me, I prefer apples to oranges. I’m just a loosely-coupled kinda gal. I like systems that are big, open, and distributed. Away with yer stinkin’ sandbox! And I happen to believe that SOA can be more than a buzzword (enterprise middleware suckage notwithstanding.)

Distributed Computing, REST, SOA

Amazon Web Services Redux

1 Comment

It seems my earlier post “The Long Tail of Web Services” is getting some traffic from links here and here. At least someone is willing to put their money where my mouth is :)

Since that original post, Amazon has come out with yet another service (still in limited beta) called Amazon SimpleDB. This is a simple but apparently powerful service to query structured data. Although I note some complaining from the database community about it not really being a database, that’s just a semantic issue. If they renamed it, the complaints would probably go away. I think I would describe SimpleDB as something like a content-addressable DHT.

BTW, I can’t help wondering if this new service is related to Amazon’s Dynamo. (This is total speculation on my part, BTW. Perhaps closer inspection will tell. Or maybe Amazon will, eventually…)

SOA

The Long Tail of Web Services

5 Comments

Google is a “global technology leader”, the tech company to watch in the 21st century; and Amazon is an online retailer—so 1999. Right?

A casual perusal of the blogosphere and IT news sites would seem to suggest such a consensus. Amazon gets occassional kudos for its web services initiatives like the Simple Queue Service (SQS), the Elastic Compute Cloud (EC2), Alexa Web Services, and it’s Simple Storage Service (S3)—though many wonder why they’re spending so much money on something apparently not core to their business (something like $2 billion so far, according to a CNET News article).

But when people think of strategic technology leadership and innovation, they generally think Google, not Amazon. There’s no shortage of hype about Google becoming “the web platform that powers much of what people do online”, the “Microsoft-killer” with its very own OS (this one is particularly absurd), and “the locked-in platform on which web applications and services are all built.” These are only a few selected examples of which there are countless others on any given day.

Now there’s no denying that Google has a lot of smart employees and a lot of cool technology. However, little of that truly innovative technology does anyone but Google any good. For example: the Google File System is by all accounts way cool, but noone outside Google is ever likely to benefit from it. And their expertise in such hardcore tech neither directly generates any revenue, nor builds any profitable relationships with users, advertisers, or partners. An MIT Technology Review article, What’s Next For Google quotes a couple of employees claiming: “Google’s leaders believe that the company’s expertise in infrastructure—knowing how to build and operate those 250,000 servers—constitutes a competitive advantage more important than APIs or standards.” Uh oh…

Amazon, on the other hand, has apparently made a commitment to turn their technical know-how and serious real-world experience into a profit centre. Since it costs so much money to develop the kind of high-performance, highly-distributed, fine-grained Service Oriented Architecture for their own operations, it makes sense to monetize it. As this ACM Queue interview with Amazon’s CTO Werner Vogels (who also maintains the personal blog All Things Distributed) makes clear, these people know as much as anyone about how to make composite web services actually work on a massive scale. And they realize that this is a strategic asset with real growth potential. As Vogels says: “I think our biggest success has been that Amazon has become a platform that other businesses can benefit from.” And: “We see Amazon.com as part of the larger Internet ecosystem, and we want to stimulate innovation wherever possible.”

Contrast this view with the recent kerfluffle over Google’s abandonment of its SOAP-based search API. The issue here has nothing to do with the technical supremacy of AJAX over SOAP, and everything to do with the fact that—despite its self-description as a “global technology leader”—Google makes 99% of its revenues from advertising (did you know they own a radio advertising subsidiary?) With such a business model, only eyeballs matter. Machines and software processes cannot view ads, cannot be influenced by branding messages, and do not make purchasing decisions. For Google to become the sort of web services platform so many people seem to expect, they’d have to radically change their business model. As it is, there’s absolutely no advantage to Google doing anything other than forcing more and more human eyeballs to view more and more ads. Having worked in advertising for several years (I’m in recovery now, thanks!), I know as well as most that doing so requires making decisions that are directly counter to the interests, needs and wishes of your customers and users (no matter how much account directors may protest that consumers actually want what’s being shoved down their throats.)

So, to end this long-ish rant, don’t look to Google to provide any real technology leadership anytime soon (cutesy AJAX email interfaces really aren’t going to change the world—sorry.) Instead, consider what you might call “The Long Tail of Web Services”: “Ultimately, Amazon wants to build up a massive partner network of tens of thousands of third-party outfits, ranging from corporations to developers and even hobbyists. ‘I’ve always thought that high-volume, low-margin businesses are more defensible,’ Bezos said.”

Coming soon: a tutorial on running a network of JXTA super-peers on Amazon’s Elastic Compute Cloud.

Update: there’s a new, related post, here.

REST, SOA

The Web: Beyond SOA

Leave a comment

Along with a significant minority of developers, I never believed that SOAP and WS-* based Web Services were going to be a practical way of constructing loosely-coupled, Internet-scale distributed applications—let alone the architectural answer to everything. (Hint: once people begin discussing the notion that human-readability and -writability are unnecessary as long as there is “adequate tool support”, you know the technology is a big fat expensive dead end.) Now I guess it’s official: WOA is the new SOA.

I have to agree with Tim Bray:

I think we should take the “Web Services” label into the jailyard, strap on a blindfold, give it a last cigarette, and shoot it. It doesn’t mean much any more, and to the extent that it does, it’s misleading: WS-* doesn’t have much of the Web about it.

Long live the Web-style.

SOA

Content-Based (SOAP) Routing

Leave a comment

Now this is interesting: a Content-Based Routing Service from Systinet. Finally a way to truly decouple service providers from service requestors (in a web services-friendly way). The idea of subscribing to SOAP documents by content as a method of service invocation has been kicking around for a while in the context of XML-document-based, Linda-like systems. I even prototyped one two years ago, though it was not specific to SOAP (I have no problem with SOAP, but I tend not to use it if a simpler solution will suffice so I needed a more general solution), and Mike Champion has been floating trial balloons about related concepts for some time.

Systinet’s CBR Service is still an alpha technology. There’s an informative article on it from the Web Services Journal: “Beyond Point to Point”. Will this approach (finally) catch on?

REST, SOA

Coordination in a Content-Addressable Web

Leave a comment

While thinking about the differences between the Web and Linda (or REST and generative communication, if you prefer), I found this paper (pdf) from 1999 in which the authors propose replacing the current web architecture with a new one based on a Linda-like coordination language. Despite its dated-ness and a number of flaws, it’s a fascinating alternate vision.

First of all, many of the authors’ claims about the shortcomings of the architecture of the Web will strike current readers as naive. Perhaps they can be forgiven on the grounds that none of Roy Fielding’s work on the architectural style of the Web was published until a year later. Nevertheless, their unsupported assertions about the Web being inefficient and inflexible will no doubt rankle, and the significance they place on increasing performance looks, in retrospect, misguided.

A more interesting critique involves the web’s use of location (URL)–or in present terms, identifiers (URIs)–to address web resources. Since the relationship between a URL/URI and the content or value of the resource is not explicit, search engines had to be introduced to perform the mapping. “This article suggests that the mapping be removed altogether: since the content of the page is what distinguishes it, one should use content as the basis for locating and organizing pages as well.”

A second critique of the Web applies to the constraint of statelessness, noting that in practice the state of a client-server dialogue is maintained through a variety of “baroque” techniques applied on both sides. While it’s well-established that statelessness is a constraint that induces scalability in the Web, it’s also recognized as a trade-off reducing the server’s control over consistent application behaviour.

The athors may have been ahead of their time in envisioning the notion of a service on the Web. They suggest a mechanism whereby servers provide services by manipulating resources through an extended set of operations, and where clients take a more active role by storing their own views of interaction state as resources (as opposed to cookies). This leads them to propose replacing HTTP with a Linda-like coordination language.

Due to its content-addressable nature, Linda allows search-engine functionality to be baked in to the infrastructure. The catch is the requirement for a scalable, distributed tuplespace implementation. The authors don’t discuss the practical challenges to building such a beast, but from a survey of some of their other publications (for example: list of publications by R. Menezes) it’s apparent they are not naive about the issues.

In this “location-free” proposal, services would be represented and discovered via tuples in a distributed space. Each service would then use a unique space to coordinate with clients.

Despite a significant amount of hand-waving, this proposal is an early attempt to develop a web of content-addressable services and documents. It isn’t difficult to add content-addressable messages and application state to this view, increasing visibility of transactions (see Bill de hÓra’s discussion of transactional blackboards).