Windows Into a Parallel SOA Universe

Microsoft isn't the first name that comes to mind when you think about service-oriented architecture vendors. Despite Windows' ubiquity on the desktop and its advance into the server market, SOA is firmly associated with Java and often runs on Linux.

But Microsoft has big plans to change that. It has already entered the enterprise service bus market, has designs on governance, and is partnering with management vendors. Most ambitiously, it has announced technologies that could put it at the center of business-to-business Web services while making application development accessible to everyone--if the products ever ship, that is.

WAITING FOR THE BUS

According to the Redmond party line, Microsoft has always supported SOA. It has simply seen SOA as a foundation for business process management rather than an end in itself. This is partly true: Microsoft was an early supporter of SOAP and the many WS-* (Web Services) standards built on top of it.

Most agree that SOA is an architectural style, not a specific product. Microsoft goes further, even denying that the ESB is a product. Now, many vendors sell standalone enterprise service buses, and ESBs are widely considered to be at the core of SOA, but Microsoft isn't necessarily wrong. Rather, it has chosen to spread ESB functionality across several products, many without obvious counterparts in the non-Microsoft world.

In fact, for a long time, Microsoft eschewed the phrase "enterprise service bus" altogether, saying its products offered a superset of ESB functionality. It relented this year and now promotes iBizTalk Server 2006 R2--still mainly a BPM server--as a way to implement an ESB. This doesn't mean BizTalk is an ESB; users wanting full ESB functionality also will need the Microsoft Visual Studio .Net development environment, the Office InfoPath XML forms editor, and SQL Server.

There's nothing necessarily wrong with breaking up an ESB. Traditionally, ESBs have been divided into at least two areas: Service enablement splits apps into reusable components, then service orchestration puts them back together into composite apps. What's more, the ESB usually runs on multiple servers, while BPM is often seen as a third layer that runs on top of orchestration, managing tasks performed by humans as well as machines.

Microsoft doesn't divide things up in quite the same way. Instead, BizTalk Server handles all integration, from enablement through orchestration to BPM. Visual Studio is needed for developing applications, whether using pure SOA or full BPM, while InfoPath and SQL Server help with XML transformation, routing, and management tasks--functions most ESBs also offer but that can alternately be handled by hardware or Web services management appliances.

For most users contemplating Microsoft SOA, service enablement is the biggest question mark. Most application servers designed for SOA are based on Java Enterprise Edition, but Microsoft uses .Net, raising compatibility issues. This mostly means that applications written for one platform can't easily be ported. The two can still share data through standard Web services or various adapters.Just as other vendors' ESBs can talk to .Net, BizTalk isn't restricted to it. Like most ESBs, BizTalk includes adapters that enable it to understand the messaging formats and APIs employed by other apps. Microsoft doesn't offer as many adapters as competitors, but importantly it can understand Java Message Service, a format many other SOA implementations use internally.

For Microsoft's own applications, the most important adapter is for Windows Communication Foundation, or WCF, a framework for building distributed apps that run under .Net version 3.0. In Windows-only environments, this makes an ESB unnecessary, as it applies SOA principles of loose coupling to components within .Net itself and even to procedures running on the same machine. That can help apps take advantage of multicore chips, as well as make it easy for Windows developers to build SOA apps.

Microsoft isn't alone in aiming to make applications more like SOAs. The Java world has an equivalent in Services Component Architecture, a standard pushed by vendors including BEA Systems, IBM, Oracle, Red Hat, and Sun. It achieves much the same thing as WCF, but--like Java itself--ought to be more open. In theory, SCA doesn't have to be tied to Java at all; Microsoft or anyone could adopt it. But in practice, all the vendors using it are from the J2EE community.

SCA and WCF aren't directly compatible, but they do both use parts of the WS-* stack, so apps developed using either can natively expose Web services. There's also incompatibility at the data layer. SCA uses Service Data Objects, a framework that some vendors are expanding to cover general data integration. However, Microsoft isn't one of these vendors. Its similarly named Server Data Objects is a remote access API for Windows servers

Microsoft also is planning to sell its adapters separately, without tying them to BPM or even an ESB. This is potentially a much bigger market than SOA, as it just means providing access to legacy systems through standard Web services. Rather than full-blown orchestration, these services tend to be accessed by browser-based rich Internet applications, or RIAs, and so can essentially mean giving a mainframe app an Ajax interface. But standardized APIs also make it possible to build mashups and, eventually, full composite BPM-type applications, so Microsoft describes this approach as "incremental SOA." And browsers aren't the only clients. Microsoft also talks about making all Office apps consumers of Web services.In most cases, this initially means only that client-side Office apps communicate with their server-side counterparts using protocols based on the Web services stack, or at least XML over HTTP. The first were Outlook clients connecting to Exchange, but Microsoft has extended this to most Office apps communicating with SharePoint. And unlike the closed system of Exchange/Outlook, it's making SharePoint/Office a more open platform that in-house apps also can access.

MODELING THE FUTURE

Most RIAs use Ajax, but Microsoft hopes developers eventually will migrate many rich Internet applications to its new Silverlight platform. Unlike previous client-side Microsoft technologies like ActiveX and Windows Media Player, Silverlight is cross-platform (supporting Macs) and cross-browser (working with Firefox, Opera, and Safari).

The intent clearly is to marginalize the browser, hoping that RIA developers will target a richer platform. However, Ajax's wide compatibility means it remains the platform of choice for applications on the public Internet, despite alternatives like Flash. Within ECMA, the standards body responsible for browser scripting, Microsoft is engaged in a heated debate with the Mozilla Foundation over the future of browser scripting. Mozilla wants to add functionality. Microsoft disagrees.

Within intranets, there's less of a case for standardization: Web-based apps need only support the standard corporate image, not every user out there. However, even here, Silverlight faces strong competition from Flash and Curl. Microsoft's hope is that Silverlight will appeal to developers because they can use the same tools--primarily Visual Studio and C#--whether they're building for the browser or the Web server, or conventional Windows apps for that matter. However, the same theoretical benefits apply to Java, yet despite dominance on the server and a head start of several years, it has been marginalized on the desktop.In the long term, Microsoft's pitch to SOA developers goes beyond conventional programming languages. It goes beyond conventional developers, too, aiming to open application development to all users, even those without programming skills. Code-named Oslo and announced in June, the initiative borrows heavily from BPM modeling, in which business processes are described through flowchart-like diagrams rather than lines of code.

Oslo extends BPM models to cover computational processes--at first composite apps for SOA, but potentially for anything that runs on a Windows server or desktop. According to Microsoft, Oslo isn't just about making coding easier. For many apps, coding will be eliminated as the model comes to fruition. The interpreter needed to execute this vision will be in a future version of the .Net framework, while Oslo modeling tools will be built into other apps, including BizTalk and Visual Studio.

Oslo also signifies Microsoft's shift further into SOA governance, mirroring moves made by other ESB vendors. Windows Server already includes a UDDI registry, but not a full SOA repository. Oslo will fix that, with a repository aimed at keeping track of models and shared among BizTalk; Visual Studio; and System Center, Microsoft's IT management product.

The catch: Oslo is still vaporware. Beta versions are due sometime in 2008, but Microsoft won't commit to delivery of final products, which could still be several years out. For example, Oslo is slated for Visual Studio 10, but Visual Studio 9 is still in beta.NATURAL MONOPOLY

The most ambitious part of Microsoft's SOA strategy is BizTalk Services, which it calls an ISB, or Internet service bus. Microsoft claims that BizTalk Services will be a true standards-based ESB, able to perform all the same functions as an ESB that an enterprise hosts in-house and therefore competing with them. Like Oslo, BizTalk Services hasn't shipped yet and doesn't yet have a firm availability date, but it's more real. Customers can already test it online (at labs.biztalk .net), along with some sample services designed to use it.Microsoft's plan is to roll out the ISB in two steps, aimed at two disparate markets. Its first targets are organizations that need to integrate applications with business partners or other third parties but are put off by the complexity. The theory is that instead of dealing with multiple Web services connecting to multiple different networks, enterprises will need to connect to just one: Microsoft.

Of course, this only works if all the organizations you need to connect with are also Microsoft customers. Ultimately, Microsoft sees itself becoming a central hub for interenterprise Web services, something that not every organization will be comfortable with. For integration to be seamless, Microsoft also will need to host identity services for all participants. These, too, are already in test form, looking a lot like a business version of Microsoft's Passport plan.

Microsoft describes the second step as taking the ESB down-market, opening SOA and BPM to companies that can't yet justify the expense of an ESB. Its pitch here is similar to those of other software-as-a-service providers.

The second step is where Redmond is likely to face the strongest competition--not just from other SaaS vendors but from conventional SOA and application platform players. With ESBs rapidly becoming commoditized and open source versions available from Red Hat, MuleSource, and the Sun-backed OpenESB, it may be too late. The main competitor in the business of selling SOA as a service is Salesforce.com, though its plans seem no more advanced than Microsoft's and it's even less associated with SOA.

In an unusual move for a SaaS provider, Microsoft also will offer all components of BizTalk Services as software that enterprises can install on their own servers. It says it may also use the platform as a way to offer other services, though the company wouldn't give many details. The first is likely to be the aforementioned identity service.This "software plus services" concept is obviously good for Microsoft: It gives the company two revenue streams and, perhaps more important, lets it leverage its dominance in desktop software into the services world. But it may not be so good for customers. A major selling point of SaaS is that it doesn't need locally installed software. While nearly everyone has Windows and Office on the desktop already, tying a service too closely to Windows Server products is unlikely to bring as many benefits.

(click image for larger view)