For the past five years, the Internet standards community has been driving, slowly but surely, toward a significant revision of one of the core specifications used on the World Wide Web. Until now, the HTML 5 effort has been embraced by every major organization and business on the Web—except for Microsoft. Finally, though, Microsoft is allowing this effort to move forward, and we applaud that.

HTML 5 is important because it should address many of the pain points that developers (and end users) face when accessing websites with advanced features that go beyond core HTML text rendering. Compatibility issues with many browsers, especially Microsoft’s Internet Explorer, frustrate many users. HTML 5 should remove much of the ambiguity on today’s rich-content Web, especially when it comes to Cascading Style Sheets, and the requirements that many developers have to create two versions of their website code: one for IE, and one for other browsers.

The new specification also eliminates the need for many graphics plug-ins, as HTML 5 incorporates better core structures for rendering, animation and more.

Recently, Microsoft has been engaging more and more with the HTML 5 community, but one area—Scalable Vector Graphics—has been a sticking point. It’s unclear why SVG has been such a problem for Microsoft. Some speculate that it’s because Microsoft views HTML 5’s SVG capabilities as competing against Microsoft’s Silverlight technology. Microsoft denies this, but hasn’t offered a better reason for its longstanding refusal to participate in the process.

While HTML 5 could move forward without Microsoft, of course, but everyone acknowledges that Microsoft’s market clout makes that an exercise in futility.

The good news is that Microsoft has finally changed its position, and last month joined the SVG working group. We’re happy that Microsoft is, at last, fully engaged in the standards process. Developers, and end users, will be spared much frustration if the next version of Internet Explorer supports HTML 5.

SOA 2.0 means best practices
What does “service-oriented architecture” mean to you? The phrase’s definition is amorphous. Is it a strictly technical term for applications that can communicate via SOAP-based Web services? Is it a loosely coupled Web interoperability concept or a mesh of enterprise-hosted and cloud-based software? Is SOA a product category? A marketing concept? Does it mean anything at all?

If you analyze the breathless vendor and analyst hyperbole of the past several years, you’d probably conclude that SOA used to be a marketing phrase that referred to Web service-based middleware, and as Anne Thomas Manes said in early 2009, SOA is dead.

Yet there’s more to the story than that. SOA has moved past the hyperbole and competing product claims, and it is becoming a shorthand expression for a set of best practices around application integration. Call it SOA 2.0, perhaps, but this latest incarnation of service-oriented architecture is the most faithful to the original theoretical underpinnings behind loosely coupled service buses.

In other words, where vendors insisted that SOA is something that your company buys (from them), we’re realizing that, no, SOA is something that your architects and developers do. It’s not about products. It’s not about expensive consulting services. It’s not about specific languages, operating systems or platforms. It’s not about SOAP vs. REST. It’s not even about silos vs. data centers vs. cloud computing.

SOA 2.0 is an approach to open, interoperable and scalable computing, an approach in which loosely coupled integration is achievable, and where simple messages, not brittle governance structures, make everything work.

The benefit of thinking about SOA as SOA 2.0 (as a set of best practices) is that those best practices work anywhere. They don’t need to be reinvented for the cloud, or for new computing paradigms. It’s a much healthier approach than all that breathless vendor hype.