Thinking Out Cloud

Web Services: Barrier to SOA Adoption

Joe McKendrick just posted Time to Drive a Wedge Between SOA and Web Services? over at ZDNet. Good post except that I would remove the question mark from the title.

One would hope that we were way beyond this issue by now and that most people realize that SOA and Web Services are not one and the same, and that in many cases it make much more sense *not* to use Web Services. For example, when your environment is fairly homogeneous -- let's say, all Java -- why would you want to introduce something as foreign, slow and un-scalable as Web Services?

Even in environments where you do want to expose some of your services to external service consumers, it still makes sense to separate into "internal SOA" (not WS-based) and "external SOA" (exposing WS) -- as Joe himself sort of points out.

There is one point in Joe's blog that I would partially argue with:

Ultimately, SOAs will either be built entirely on Web services, on some Web services, or not on Web services at all. But, at least for now, for most enterprises, Web services represents the path of least resistance.

It is true that for *some* organizations, Web Services represents the path of least resistance. But just like in the classic Innovator's Dilemma -- you're not hearing what those who aren't your current customers are saying. In other words, those who would never consider SOA in the first place *because* of Web Services. Or more accurately, their perception that SOA equals Web Services. These are customers with high-performance and high scalability requirements. Customers with data-intensive and stateful services.

Try suggesting to a Wall Street trader to use Web Services for an automated trading application. You'll be kicked out in a New York minute. And that is despite the fact that these applications are highly amenable to be  composed of multiple loosely-coupled services, some of which can be reused by other applications.

They need something else.

Guy Nirpaz of GigaSpaces gives a good presentation at Javapolis on what that solution could look like.

Scalable SOA

Last week I had the pleasure of speaking to Dave Linthicum from the Linthicum Group ("SOA for the real world"). Dave is a prolific columnist, blogger and podcaster on SOA, and is one smart cookie.

What triggered my conversation with Dave were two of his most recent posts on his InfoWorld blog: Scalable SOA Solutions Continue to Emerge and Why SOA Governance Needs to do a Better Job with Data, both of which hit the nail on the head. In the first, Dave is saying something we've been saying at GigaSpaces for a while now, but he puts it really well:

Making solutions scale is nothing new. However, the SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads. SOA implementers were happy to get their solutions up-and-running, however in many cases scalability is simply not a consideration within the SOA, nor was load testing, or other performance fundamentals. We are seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology in many instances.

As I previously wrote in The Law of Unintended Consequences scalability is even a bigger problem when it comes to SOA, because you have even less information how much and when your service will be consumed.

And as I wrote in SOA Governance - Who Cares? the large vendors are focused on selling their SOA governance products and relying on either Web Services or their same old J2EE app servers for the service implementation itself.

In his data post, Dave continues to nail it, bringing up the issue of not dealing with data and the service logic holistically in most SOA environments. Dave is obviously a guy who is out there in the real world.

At GigaSpaces, we are already seeing the need for a new approach to implementing services, especially with our capital markets customers and their very high-throughput, low-latency stateful front office trading and real-time analytics apps. And that is what Space-Based Architecture and our eXtreme Application Platform are all about.

We have recently posted a great example and explanation on implementing high-performance, scalable SOA using SBA and in the context of our new API - the OpenSpaces framework on our award-winning Wiki. Check it out. (BTW, It's still a work in progress).

Update: Check out this presentation from Guy Nirpaz at JavaPolis on Space-Based Architecture and Scalable SOA.

Update 1: Nati Shalom writes about this topic here.

SOA Governance - Who Cares?

One of the things that have been baffling me for the past few months is the amount of money and effort the big middleware vendors  - IBM, BEA, Tibco, Oracle - have been pouring into their SOA governance products in terms of development and marketing.

It's not that I think that SOA governance is not important. Of course it is. But it is more of an organization, planning and consistency issue for those implementing SOA. The products themselves -- registries and repositories, etc. -- seem to be low-value products that are rapidly being commoditized and undifferentiated.

Seems to me that the more interesting issue, which few vendors are tackling, is how to implement your services. Existing approaches using J2EE and databases won't cut it in an SOA world where services need to be loosely-coupled, dynamically scale and so on. I previously discussed some of the challenges of implementing services in this post.

The good news is that from discussions with folks at some of the large vendors, it seems that some (senior) people are starting to get it.

By the way, Nati gave a great presentation, together with Shay Banon (one of our lead architects) on the topic of implementing services at TheServerSide Java Symposium last week, entitled From Tiers to Services without Web Services. It roughly follows the same concepts Nati discusses in The Scalability Revolution white paper we published recently.

The Law of Unintended Consequences

Service-oriented architecture is becoming one of the latest examples of the Law of Unintended Consequences. In a recent InformationWeek survey, 24% of respondents from large corporations said their SOA projects “fell short of expectations.” Of these, 55% said the reason for failure was that the SOA initiative “introduced more complexity into their IT environment” -- ironic , given that one of the benefits touted by SOA proponents is that it reduces complexity.

There are several reasons for this complexity, and one of them has to do with capacity planning. Eric Roch and Jason Bloomberg have both written thoughtful pieces that discuss this issue, but generally it did not receive much attention.

Capacity planning challenges are not unique to service-oriented environments. They exist with many applications. The typical approach to address these challenges has been over-provisioning. In other words, estimating peak loads expected (usually, for the next few years), and providing enough hardware resources to be able to handle those loads. That works well, if you like throwing away money on idle hardware, electricity, cooling and data center real-estate costs. So the industry has ended up with a pathetic 5% to 15% utilization figure (the lower number typically occuring when you count people's idle desktop computers).

With SOAs, the problem is exacerbated. Services are publicly available (either within the organization or externally). This means that the designer of the service has even less visibility into the potential demand for the service down the line.

Q: So what's the best way to do service capacity planning?

A: Don't.

Eliminate the need to plan by creating a service infrastructure that dynamically grows and shrinks on demand. This is the notion of the Service Grid we introduced in GigaSpaces Enterprise Edition 5.0.

The Service Grid creates a self-managed, dynamic “cloud” of services. Requests are sent to the cloud, and it determines, based on demand and Service Level Agreements, if services need to grow or shrink their capacity (i.e., dynamically deploy on additional resources) The Service Grid is also self-healing, meaning it will dynamically maintain the high-availability policies you define.

The approach is to assume the Law of Unintended Consequences, not to ignore it.

You can learn more about the Service Grid here. There's lots more to it than I described above. As an acknowledgment: The Service Grid was originally developed by Dennis Reedy, the "father of Rio," who essentially enhanced the open source Rio Project he originally developed at Sun Microsystems, and tightly integrated it with GigaSpaces.

Larry Mitchell and Kevin Hartig are even blogging about Rio.

 

The Tyranny of Tiers

Ted Neward wrote an excellent piece in his new MSDN column about "layering." Essentially, Ted is making the same argument that is one of our key tenets at GigaSpaces -- separation of concerns in the architecture should be logical, not physical, as is the case with most tier-based systems. The physical separation creates huge latencies and is a scalability bottleneck. This idea of "virtualized Tiers" is the basis of our Space-Based Architecture and what lies behind our slogan: Write Once Scale Anywhere.

A while back, Nati Shalom wrote an excellent white paper about this entitled Space-Based Architecture and the End of Tier-Based Computing (registration required). By the way, it was one of the all-time most downloaded white papers on the TheServerSide. And Nati has been presenting this idea in various conferences.

We have been talking about "virtualized tiers." Ted gives it a name, which I think clearly establishes the difference between a "virtual tier" -- a "layer" in Ted's terminology, and a physical tier. I think I'll adopt Ted's version from now on.

From Nati's paper:

Tier-based computing has hit a wall when it comes to supporting performance-intensive applications. Whether the challenge is to grow these applications beyond a few hundred concurrent users or a few dozen parallel processes, issues like complexity, scalability, load-balancing, and synchronicity get in the way. The solution is not to improve the tier-based approach but to move beyond it — to a service-oriented architecture built on shared spaces within a grid computing framework.

The power of spaces comes from not having to separate various parts of an application into discrete physical runtimes — and then wiring those together in complex, hard-to-scale, and performance-consuming tangles of middleware. A space doesn’t care if an application has been “tiered.” Whether it has or not, the same program code will instantiate multiple times on the same machine or on multiple machines automatically — and even dynamically - in response to runtime parameters like CPU utilization.
Instances communicate through the space, just as if they were talking to middleware. In fact, they can use the same middleware APIs they always have — except now the middleware’s role has become virtualized, meaning that all physical message and data exchanges are handled transparently by the space.

And here’s the best part: Spaces make migrating today’s tier-based applications to tomorrow’s service oriented and grid architectures an evolutionary migration — with immediate performance boosting benefits.

Jini - Killer Apps aren't developed; they emerge

With the shift in Jini/JavaSpaces legal status from Sun to Apache, there has been some re-thinking in the community about the technology. Fans and users of the technology have long realized its power and benefit, and are somewhat perplexed: how is it that the rest of the world isn't catching on?

As part of this re-examination, a recent survey on Java.net asked "What would best help Jini gain traction?" The results made me wonder. More than half of the 490 voters answered that Jini needs a "killer app" (either for developers or end users). This result is not surprising. It echoes the "Beyond the Choir" presentation given by Daniel Steinberg at the 10th Jini Community Meeting (reproduced here).

I question the wisdom of the crowd on this one. Not so much because it isn't true that a killer app would help Jini, but because it is not a helpful call to action. Killer apps are not what makes a technology widely accepted. Killer problems do. Killer apps emerge.

To understand this better, some familiarity with Richard Gabriel's brilliant work would help. In particular, his seminal presentation Models of Software Acceptance: How Winners Win (PDF). It is very worthwhile going through Dr. Gabriel's presentation in its entirety. The main point I want to extract, however, is the myth that if a technology has been around for a long time, and has not achieved wide acceptance, it never will.

As Gabriel shows, most successful technologies, including software, actually take between 10 to 25 years from first instant in the lab to wide commercial acceptance. He gives a wide range of examples: from the VCR (developed 1954, widely accepted c. 1985), spreadsheets (first developed 1965, wide acceptance c. 1986), the web, and various programming languages.

The basic assertion Gabriel makes is that while a technology may have been around for a while, massive acceptance only occurs when there is significant environmental change that suddenly makes those technologies relevant (he gives 3-4 other scenarios, but this is the one he focuses on). Once this change happens, and if the technology is positioned to seize the opportunity, everything else will fall into place: products rapidly improve, they become cheaper, and with multiple applications -- including killer applications.

When a product is first launched, its quality is often low, its price high and its applications limited. The personal computer fell into this category, until software firms developed spreadsheets and word processors.

Gabriel then revises the Crossing the Chasm model. Geoffrey Moore's assertion is that innovative products that successfully cross the chasm between early adopters to mainstream use do so by finding a niche market they can dominate and expand. In Gabriel's version:

This [chasm] really represents a change in the environment that renders the technology useful/desirable/hot/necessary. It turns a vitamin pill into a pain killer, a nice-to-have into a must-have.

Now back to Jini/JavaSpaces.

The bad news: there is really nothing to do in terms of "developing a killer app". If the environment changes so that the need is strong, killer apps will emerge.

the good news: The environmental change required to turn Jini/JS from a vitamin to a pain killer is happening now -- and in a huge way.

Jini was originally designed with the motivation to overcome The Eight Fallacies of Distributed Computing. And distributed computing has never been more in demand and "more distributed" than it is now, because of (among other things):

• The trend to move to low-end commodity hardware
• Virtualization and grid computing
• Service-oriented architecture
• Multi-core platforms
• The overall need for scalable systems due to exponential data and transaction increases

There are also enabling factors that come from changes in the environment, particularly the abundance and low-cost of memory and fast networking.

Looking at the world with this in mind, killer apps for Jini/JavaSpaces are everywhere: Wall Street, defense, online retail and gaming, analytics, RFID. Heck, even the original, somewhat derided, proposed killer app for Jini -- device connectivity -- is highly relevant today.

It's everywhere. I know. My company sells more of these "killer apps" every quarter.

So what should Jini/JavaSpaces fans do now? Finish the job. Make it easy to understand and learn, easy to use, interoperable, commercially supported.

At GigaSpaces we've been doing a lot of this: interoperability with .Net, C++, Spring, Mule and other environments. We're working hard on online documentation, and ease of use, and every other aspect of making Jini/JavaSpaces into an enterprise grade product.

Others have been doing good things as well: Paremus with their efforts on OGSi and SCA, Dan Cresswell with the Blitz Project, the Sun Jini team, Van Simmons with the ComputeCycles project,  Calum Shaw-Mackay with Glyph and many others.

(By the way, there's an interesting presentation from the folks at Paremus at the 10th JCM on the topic Why Jini must Adapt to Survive.)

We are seeing the momentum for Jini/JavaSpaces out there -- backed by dollars. It's an idea whose time has come.