All About Interop : Services

Microsoft Platform services

DotNetInterop — Tue, 17 Jun 2008 03:07:00 GMT

Microsoft has a new web page up covering a collection of hosted platform services. Worth checking out. There is good interop capabilities in all of these. I'm thinking maybe I have to stand up some PHP examples that connect to SQL Server Data Services and also to the BizTalk Services integration bus.

What you think?

SOAP? REST? Whichever you choose, WCF is the right framework

DotNetInterop — Wed, 14 Nov 2007 00:45:00 GMT

There's a new paper by David Chappell that is worth checking out. Entitled "Dealing with Diversity: Understanding WCF Communication Options in the .NET Framework 3.5", it discusses WCF and its applicability to REST as well as WS-* style communications. (To get the paper, click the link and then scroll down to download the Diversity paper.)

As you may know, there's been lots of discussion about whether SOAP-based or REST-style approaches to services interfaces are the right thing.

If you're not familiar with the debate, here's the plot summary: that REST-style interfaces can be useful in basic scenarios, but if services-based applications demand things like reliabilility, transactions, forwarding, or message-based security, then SOAP with the comlpementary WS-* family of standards is probably a better approach. (Regarding REST, a secondary point is that many people say REST when what they mean is HTTP QUERY, and the two are different things. See my note below on Amazon SQS.)

But that's my take. Not everyone will agree with that summary. I guess a safer, but not purely controvery-free statement might be: REST and SOAP will be useful in different scenarios, for different audiences.

It's an interesting debate, and probably not one that will settle clearly for a while. Our philospohy at Microsoft is that, whichever protocol you choose, REST, SOAP or otherwise, if you are building applications on Windows, WCF is the right programming framework. WCF is the Windows Communication Foundation; it is part of the .NET Framework, and is the generalized communicoation programming framework within .NET. If you are building an application that communicates with other systems, whether those other systems run on Windows or not, whether the communications are outbound or inbound with respect to the part you are building, WCF is for you! Due to previous marketing focus on SOAP and WS-* support around WCF, many people who are conversationally familiar with WCF mistakenly believe that WCF is a programming framework that solely helps people build WS-* applications, or applications that speak SOAP. That is true: WCF does help you build apps that do WS-*, but the statement is incomplete. A more complete statement is: WCF helps people build apps that communicate.

Whether you choose a binary transport that is optimized for communication between .NET endpoints, or SOAP and angle brackets, or a REST-style communications endpoint that uses JSON for the data format, or an RSS feed, or something else, WCF is the right programming framework. (Special note!! The REST and JSON and RSS stuff in WCF was added in the .NET Framework v3.5, which is set to release this month (November 2007)) Using WCF, you can even create a single service with multiple services interfaces, each of which uses a different protocol and serialization format.

Sidenote: speaking of multiple interfaces for the same resource, check out what Amazon did with SQS: there is a REST interface, a SOAP interface (described in WSDL) and a QUERY interface. The REST interface is bona-fide REST. It uses HTTP verbs like (GET DELETE PUT POST), and the URI corresponds or maps to the resource in question, for example the queue you'd like to operate on. In WCF, to build this sort of interface, you would use a [WebInvoke] attribute on your service interface. The QUERY interface on the Amazon SQS resource is, like the REST interface, always based on HTTP, but QUERY is different than REST in that QUERY is always an HTTP GET, and specifies the object and verb in the URI.

Example:

The QUERY request to create a queue:

GET /?Action=CreateQueue&QueueName=Foo HTTP/1.1

Host: queue.amazonaws.com

The REST request to create a queue:

POST /?QueueName=Foo HTTP/1.1

Host: queue.amazonaws.com

Some people confuse or conflate REST with HTTP QUERY, but Amazon certainly does not. It doesn't help matters that there is no widely accepted or adopted name for the HTTP QUERY services interface. Amazon calls it HTTP QUERY or just QUERY but as far as I am aware, that name is not widely used by other systems who expose similarly architected interfaces.

This is what I mean when I say that WCF is a generalized communications framework. It is not WS-* only. WCF supports different protocols, different data formats, different models, all within a single generalized communications framework.

David Chappell makes this point very well in his paper. It's worth checking out.

Cheers!

-Dino

Microsoft launches new SOA Website

DotNetInterop — Tue, 30 Oct 2007 19:38:00 GMT

The new Microsoft SOA & Business Process website is up! And I am really pleased to see it.

Mea culpa time: For a long time, we (Microsoft) have not effectively communicated with customers and partners about Service Oriented Architecture. That's why I'm so pleased to see this new website.

By the way, the new website is up on this, the first day of the 2007 SOA & Business Process conference, happening on Microsoft's campus right now. I'm sitting in the keynote address as I type this. The event is sold out! There are 1000 people here to learn about the Real-World approach to SOA that is enabled by the Microsoft application platform.

Why were we so bad at communicating? Have a look back. As SOA became a theme that captured the imagination of people, Microsoft got leery. Other companies started slapping SOA badges on their existing products: "New! Now SOA enabled!" Some companies started producing new products targeted to SOA. Companies built SOA centers of excellence, SOA Swat teams. The attention around SOA grew and grew. SOA became the solution for everything. SOA was the solution to world hunger!

Side note: Later came the backlash. People started realizing, hey, maybe we're over-doing this SOA thing. People want to get more pragmatic on SOA, they want less pie-in-the-sky promise and more practical results. That's a natural, and maybe a necessary, part of the cycle I guess.

Microsoft, for its part, conceived SOA in a technical context, and the way we talked about SOA showed this. We articulated the four tenets of SOA: Boundaries are explicit, services are autonomous, Services share schema and contract, and Service compatibility is negotiated and based on policy (link). Yikes! This is SOA for bit-heads. This is not actually SOA at all! It is how to build web services.

This tech-heavy focus was our error. Certainly we wanted to educate people on how to build services. But that wasn't the only issue around Service Orientation, and maybe wasn't even the most important issue around Service Orientation. Really, SOA was interesting to businesses because of flexibility and agility. SOA had the potential to bring flexibility to a business, and that meant better competitive positioning. We were talking about service contracts and WSDLs, while customers were talking about getting their work done more quickly, or being more responsive to market shifts. We whiffed on this.

But we've seen the error of our ways! SOA remains an important theme for the industry, a key opportunity for customers. And We, Microsoft, have slowly but steadily evolved and matured and broadened our thinking on SOA, and that's a Good Thing. The new SOA website is good evidence of this. It's meant to provide a single point of access for our customers into our SOA thinking, a single place where we talk about the capabilities across the entire Microsoft application platform product set - across Visual Studio, System Center, the .NET Framework, SharePoint Server, BizTalk Server, and more - and how those pieces fit into a SOA strategy. It also provides a place for Microsoft to communicate about SOA-related events, partner activities and offerings, and other content related to SOA that is available throughout the Microsoft.com web.

Project Astoria, S+S, and Interop

DotNetInterop — Wed, 16 May 2007 18:11:00 GMT

With the unveiling of Project Astoria, we're seeing more and more "services in the sky" from Microsoft. Of course there is the BizTalk Services ISB, which I commented on previously. At Mix, Microsoft talked about a bunch of things, but one category was the Windows Live platform.

Lots of new services offerings, and lots more action to come in this area. One of the philosophical underpinnings of the activity around Microsoft services, goes by the name of S+S inside the halls of Microsoft buildings. S+S means "Software plus Services". The traditional model for software has been to install software on-premise, on a machine (a server) located in a datacenter that you own and operate. Services, on the other hand, promised to provide the capability of locally-installed software, without the locally-installed part. This is often called SaaS, for Software-as-a-Service, but some people just call it Services. It's an overloaded term: Ask EDS what they mean by "Services" and you'll get a different take! For now I will call it "(software)services" to distinguish.

Anyway, the idea behind S+S is that people want the option to choose both locally-installed software, and remotely-accessible (software)services as their needs dictate. Microsoft can't really be a broad supplier of software unless we do both, and offer customers choices. That's what S+S attempts to express.

With all the activity around (software)services, keep in mind that these pieces can all be complementary to the existing software deployed in businesses today. And also, these (software)services compose nicely into a SOA, which is an IT architectural approach Microsoft has been espousing for years now, specifically to enable this sort of opportunity - the opportunity to choose S+S.

Getting back to Project Astoria, if you haven't looked - it is a data services platform for the web. The idea is that apps can do HTTP GET's with special URLs to access data services. Technologically, there is nothing really too revolutionary here, especially if you have previously looked at the SQLXML Query capability that is available with SQL2000 and SQL2005. I have online demos dating from 2004 showing interop - for example Java apps rendering XML derived from SQL, with ASPX pages consuming that (plain old) XML; or conversely, ASPX pages rendering the XML and Java consuming the XML. The big difference with astoria, of course, is that Astoria is a data service "in the sky" - it is on the internet, and is accessible to anyone. Another difference is that Astoria maps a generalized query and access model to a URI space.

Now to the interop part - if you look at the examples of the Project Astoria data services, you will see that the data is returned in pretty clean-looking XML, or alternatively, JSON. So this means these data services will be easily re-usable from any non-Microsoft platform, including Java, PHP, or anything that speaks HTTP GET. and of course the new Web programmability stuff that will be delivered in the .NET Framework v3.5 later this year (codenamed "Orcas") will do very nicely, too, thankyou.

Nice!

"BizTalk Services" ISB debuts

DotNetInterop — Tue, 24 Apr 2007 22:38:00 GMT

This just in.... Microsoft has just released a Community Technology Preview (CTP) of BizTalk Services, a set of hosted services delivered via the Internet to help developers rapidly build and run composite applications at internet scale. At it's core, it is an Internet Service Bus.

With platform technologies including Windows Server, the .NET Framework, BizTalk Server, and other so on, Microsoft has long been dedicated to delivering ever-broader application platform value to businesses that want to be able to buy+build+integrate their systems. The “BizTalk Services” ISB extends and complements the existing Microsoft platform to further advance the capability and productivity available to those businesses.

"BizTalk Services” is easily programmed through the familiar .NET Framework v3.0 and Visual Studio. In addition, the “BizTalk Services” capability is accessible through standard Internet and WS-* protocols making them fully interoperable with existing IT investments, and easy to use from a wide range of platforms.

Dino sez, check it out.

Oh, also, some other blogging attention:

John Shewchuk, the distinguished engineer at Microsoft who is heading the project for BizTalk Services, is blogging about the effort.
Dennis Pilarinos , another engineer on the team, has some insight into the internals.
Clemens Vasters chimes in with his view
Steven Martin also has some comments on the significance of this stuff
Vittorio Bertocci is excited about the P2P potential here.
David Lemphers, in Melbourne, weighs in, too.

eWeek did a story, too