Archives
 


ATOM Feed

Why Service Component Architecture Is Big News  
# Sunday, April 02, 2006
 
In an industry where new technologies are usually over-hyped, there’s one that’s not getting nearly enough attention. Service Component Architecture (SCA), currently described in a group of preliminary specs created by IBM, BEA, Oracle, SAP, IONA, and Sybase, generated a few news articles and blog posts when it was announced late last year. Since then, it’s largely slipped from view.

Yet I’d argue that the magnitude of what’s happening with SCA is analogous to Microsoft’s announcement of the .NET Framework back in 2000. If the vendors behind this effort can make good on their promises—and there are good reasons to think they can—a major part of the development world will be shifting to a new platform. This is big news.

SCA attempts to do several things. First, it replaces large parts of J2EE. SCA still relies on some J2EE technologies, such as JavaServer Pages, but its creators seem intent on moving away from EJB and other parts of this complex technology environment. The SCA specs make soothing noises about working with these older technologies, but SCA largely subsumes their functionality.

SCA also aims to eliminate Sun’s control over the primary non-Microsoft application platform. Given that both Sun’s stock price and its J2EE app server market share are in single digits, it makes no sense for it to retain control of this fundamentally important technology. By creating SCA outside of the Sun-controlled Java Community Process, the vendors behind this effort have made their intentions clear.

It’s also fair to view SCA as an attempt to provide a platform that’s technically competitive with Microsoft’s Windows Communication Foundation (WCF). I wrote a comparison of SCA and WCF shortly after SCA’s announcement, and the two have many similarities. WCF is significantly simpler than the .NET technologies it replaces, and it’s simpler still than the analogous J2EE technologies. Without a streamlined replacement for these J2EE technologies, which SCA tries to be, Microsoft’s competitors would be at a serious disadvantage.

SCA certainly faces hurdles to success, some of which I described in my SCA/WCF comparison. Still, for organizations moving to SOA—that is, for pretty much everybody—SCA is a big deal. Unless you’re an all-Microsoft shop, in which case your future will rely on WCF, your primary vendors have told you that they’re about to change the platform on which you build service-oriented applications. Since this style of development is becoming the default, the platform you use for it matters enormously. If you care about application development, pay attention to SCA. It really is big news.


4 comments :: Post a Comment

 

Windows Live and the Good Ideas of Hailstorm  
# Thursday, March 30, 2006
 
As far as I could tell, I was one of the few people outside Microsoft who thought that .NET My Services--codenamed “Hailstorm”--was a good idea. The notion of Internet-accessible web services that developers could build applications on was clearly interesting, and the services themselves offered real potential: an alerts service, a presence service to figure out where to send those alerts, a common place to store contacts and other information, and more. I could easily imagine applications built on these services that would make my life better. I even devoted an entire chapter to .NET My Services in my book Understanding .NET, a decision I came to regret when the technology died.

This project's codename was well-chosen: .NET My Services brought down a storm of criticism on Microsoft. During its short lifetime, I gave talks about Hailstorm to many different groups in many countries. Largely because it included services to store personal information, the response was the same everywhere: “We don’t trust Microsoft to store our data”. Even the normally sober John Markoff, who tracked its rise and fall in a series of New York Times articles, seemed to think that .NET My Services was kind of scary.

But good ideas don’t die. Microsoft’s announcements about Windows Live in late 2005 and the latest ones at this month’s MIX 06 conference make very clear that parts of what Hailstorm offered are reappearing in a slightly different form. What’s public so far includes an alerts service, with alerts routed to a user based on presence information, a way to store contacts, and more. And unlike Hailstorm, Microsoft is talking about business models upfront, including support for advertising and others.

The Windows Live licensing does contain some interesting restrictions. Applications can be prohibited from integrating with a non-Microsoft search service, for example, a limitation that’s sure to apply primarily to Google. Google is now the current employer of Mark Lukovsky, who was the original force at Microsoft behind .NET My Services. It's plausible that Google could also provide Hailstorm-like services if they chose to, and I look forward to seeing what they decide to do. If this idea is any good at all--and I think it is--it ought to attract more than one competitor.

.NET My Services was the Apple Newton of this new market: a great idea, but the initial execution missed the mark. The first offering in a wholly new area commonly has this experience, but it does help everyone understand more about what’s really needed. Just as Palm learned from Apple’s mistakes and finally got the PDA thing right, someone will get the Hailstorm idea right. Maybe it’s Windows Live, maybe it’s Google, maybe it’s somebody else. Whoever does it, I look forward to the second coming of .NET My Services. This idea is too good to die.


0 comments :: Post a Comment

 

Making Loose Coupling Real: The Need for Interoperable Queued Messaging  
# Saturday, February 25, 2006
 
Assertions that web services are loosely coupled have always rung hollow to me. Everyone seems to have a unique view of what loose coupling means, although rigorous definitions are scarce. And the reality is that the most common use of web services today follows the traditional RPC model, which is at best only a bit more loosely coupled than DCOM or CORBA.

I'd argue that an important aspect of loose coupling--often the most important--is the ability to communicate via queued messaging. Sadly, this isn't really possible today in an interoperable way with web services. WS-ReliableMessaging does allow reliable communication via SOAP, which is a good thing. But this spec effectively adds the functions of TCP to SOAP. It's not sufficient for creating interoperable message queuing in the style of IBM's WebSphere MQ (formerly known as MQSeries) or Microsoft Message Queuing (MSMQ).

I've been concerned about this for a while. (I remember complaining about it in my keynote at Software Development West almost a year ago.) To me, interoperable queued messaging is fundamentally important for the kind of environment that service-oriented architecture is aiming at. Because the standards in this area aren't sufficient, we see proprietary solutions like the use of JMS-based messaging in enterprise service buses such as Sonic ESB. (Don't be confused here: JMS defines only a programming API, not an interoperable wire protocol.) We also get unavoidable but imperfect solutions such as the reliance of Windows Communication Foundation on MSMQ for queued messaging.

What's needed to fix this problem? By all accounts, not much. Microsoft's Shy Cohen has recently posted a good description of the issue from Microsoft's perspective that's definitely worth reading. I have no first-hand knowledge, but it's easy to imagine that IBM isn't too keen on creating web services standards in this area. WebSphere MQ holds a commanding share of this market, and so it would be understandable if IBM wasn't enthusiastic about creating another WS-* spec that commoditized queued messaging. Still, without interoperable queued messaging, web services-based SOAs will be limited in significant ways.

Yet big customers still hold big sway with their vendors. Especially if you work for a large user organization, please tell your vendor reps that they need to work together to solve this problem. It's fundamental to making loose coupling real.


0 comments :: Post a Comment

 

VSLive Keynote Online  
# Friday, February 03, 2006
 
An audio-and-slides recording of the keynote I gave at this week's VSLive conference has been posted. The talk is called Building Modern Software: Services, Workflow, Integration, and it's available here.

The recording starts a few minutes into the presentation, so the opening is a little abrupt. Not much content was left out, though: what's missing is mostly just me introducing the "other" David Chappell, the Sonic Software VP, who was sitting in the front row. It's the best way I know to make people believe that we really are two different people.


1 comments :: Post a Comment

 

A Podcast on Modern Software  
# Tuesday, January 31, 2006
 
After my keynote this week at VSLive in San Francisco, I sat down with Ron Jacobs from Microsoft for a chat about modern software. In the context of this discussion, "modern" means service-oriented and workflow-based applications, although our conversation ranged over a number of topics. Ron is a great interviewer, full of smart questions and ideas, and it was a pleasure talking with him. The podcast is available here.


0 comments :: Post a Comment

 

The Three Faces of SOA  
# Monday, January 23, 2006
 
Among software people, the word “architecture” is commonly used in three distinct contexts: application architecture, infrastructure architecture, and enterprise architecture. The notion of service-oriented architecture spans all three of these areas. Yet whenever somebody talks about SOA, he or she is often implicitly thinking about only one of them. Developers are mostly interested in the challenges of building service-oriented applications, for instance, and so their focus tends to be on the application architecture aspects of SOA. A vendor of web services management tools commonly thinks of SOA primarily in the infrastructure sense, while an enterprise architect at a user organization is likely to be concerned mainly with SOA’s enterprise aspects.

All three perspectives have value. Here are simple descriptions of each one:

- Service-oriented application architecture: Guidelines, patterns, and practices for creating service-oriented applications. People who focus on platforms for service-oriented software and on the architecture of individual applications tend to emphasize this perspective. Technologies such as Microsoft’s Windows Communication Foundation (WCF) and the recently-announced Service Component Architecture (SCA) are directly relevant here.

- Service-oriented infrastructure architecture: Guidelines, patterns, and practices for managing and operating service-oriented applications. Big thinkers about SOA sometimes give this perspective short shrift, but anybody who’s actually trying to make it real knows how important these issues are. Vendors like AmberPoint and Actional are focused here.

- Service-oriented enterprise architecture: Guidelines, patterns, and practices for using and getting business value from service-oriented applications. Technical issues still appear here, but many of the biggest concerns revolve around people. (In fact, I’d argue that this view of SOA encompasses the most difficult challenges--people are usually more problematic than technology.) Advice on SOA from analyst firms such as ZapThink often emphasizes these aspects.

I’ve seen people argue about the meaning (and even the value) of SOA when their real difference was that one took an application-focused view while the other took an enterprise view. Words are only useful when we can agree on what they mean, and so having a clearer sense of what we’re talking about when we use this overloaded term would be a step in the right direction.


11 comments :: Post a Comment

 

This page is powered by Blogger. Isn't yours?


 

 

 

           
Back to Top.
Keynotes :: Seminars :: Consulting :: Books :: Articles :: Videos :: Newsletters :: About :: Contact :: Home