Today's preview of the Start.com Developer illustrates fundamental shifts in web programming patterns:

• DHTML-based Gadgets
  Start.com consumes DHTML-based components called Gadgets. These Gadgets can be created by any developer, hosted on any site, and consumed into the Start.com experience. The model is completely distributed. You can develop components derived from other components on the web.
• Adding Behavior to RSS
  RSS (Really Simple Syndication) is an incredible platform for sharing content and information. Today all RSS feeds are treated equally by aggregators. Start.com integrates the world of RSS with Gadgets enabling any feed to optionally be associated with a rich, interactive experience. Some feeds present information that may be better presented in an alternative format. Other feeds leverage extensions or provide extra semantics beyond standard RSS (e.g., Open Search, Geo-based coordinates, etc). By enabling a feed to define a unique experience or consume an existing one, the richness of the aggregator experience can improve organically without requiring a new application. Of course, we also allow the user to control whether a custom experience is displayed for a feed.
• Open-ended Application Model
  Start.com is what I call an open-ended application. An open-ended application consumes Gadgets and provides core application services and experiences. This is and has been the Start.com model since its inception (how do you think they released new features every week?). By opening up Start.com, we have removed the boundaries around Start.com features and experiences. The community of developers and publishers can now define and control the richness of the Start.com experience.

These are the web-applications of the future - applications that can integrate not only content (e.g., RSS) but associated behaviors and services. Today, via Start.com, the developer community can preview MSN's client technology and infrastructure. At Start.com/Developer, you will find early samples and documentation. This site will be continually improved with more documentation and samples. Go and build Gadgets and custom experiences for your feeds. Most importantly, since we are far from finished, please give us feedback. The platform can only improve with your feedback. Also, we are always looking for interesting Gadgets and custom RSS experiences.

I'm not sure I'm feelin' the "Web 3.0" monicker but the extensibility of the site is definitely cool beans. I remember a conversation I had with Steve Rider I had during the early days of the site where I asked if it would be possible to customize how different RSS feeds were displayed. At the time, I had noticed that there were three primary widget types for weather reports, stock quotes and headlines. I suggested that it would be cool if people could add annotations to the RSS feed to tell it how to display on the Start.com. Being an XML geek I was was thinking of extensions such as a start:display-style element which could have values like "columns", "headlines" or "rows".

Steve thought my idea was cool and chatted with Scott Isaacs about it. Since Scott is the DHTML guru of DHTML gurus, he kicked the idea up a notch and actually designed an infrastructure where sophisticated rendering behavior could be associated with an RSS feed using JavaScript. The rest is history.

Damn, I love working here.

The former co-workers (the Microsoft XML team) have been hard at work with the C# language team to bring the XML query integration into the core languages for the .NET Framework. From Dave Remy's post Anders unveils LINQ! (and XLinq) we learn

In Jim Allchin's keynote At PDC2005 today Anders Hejlsberg showed the LINQ project for the first time.  LINQ stands for Language Integrated Query.  The big idea behind LINQ is to provide a consistent query experience across different "LINQ enabled" data access technologies AND to allow querying these different data access technologies in a single query.  Out of the box there are three LINQ enabled data access technologies that are being shown at PDC.  The first is any in-memory .NET collection that you foreach over (any .NET collection that implements IEnumerable<T>).  The second is DLinq which provides LINQ over a strongly typed relational database layer.  The third, which I have been working on for the last 6 months or so (along with Anders and others on the WebData XML team), is XLinq, a new in-memory XML programming API that is Language Integerated Query enabled.  It is great to get the chance to get this technology to the next stage of development and get all of you involved.  The LINQ Preview bits (incuding XLinq and DLinq) are being made available to PDC attendees.  More information on the LINQ project (including  the preview bits) are also available online at http://msdn.microsoft.com/netframework/future/linq

This is pretty innovative stuff and I definitely can't wait to download the bits when I get some free time. Perhaps I need to write an article exploring LINQ for XML.com the way I did with my Introducing C-Omega article? Then again, I still haven't updated my C# vs. Java comparison to account for C# 2.0 and Java 1.5. It looks like I'll be writing a bunch of programming language articles this fall. 

Which article would you rather see?

While perusing my referrer logs I noticed that I was receiving a large number of requests from Google Desktop. In fact, I was serving up more pages to Google Desktop users than to RSS Bandit users. Considering that my RSS feed is included by default in RSS Bandit and there have been about 200,000 downloads of RSS Bandit this year it seemed extremely unlikely that there are more people reading my feed from Google Desktop than RSS Bandit.

After grepping my referrer logs, I noticed an interesting pattern when it came to accesses from the Google Desktop RSS reader. Try and see if you notice it from this snapshot of a ten minute window of time.

2005-09-13 16:31:05 GET /weblog/SyndicationService.asmx/GetRss - 80.58.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:32:13 GET /weblog/SyndicationService.asmx/GetRss - 65.57.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:32:36 GET /weblog/SyndicationService.asmx/GetRss - 209.221.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:33:05 GET /weblog/SyndicationService.asmx/GetRss - 64.116.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:33:12 GET /weblog/SyndicationService.asmx/GetRss - 209.204.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:33:20 GET /weblog/SyndicationService.asmx/GetRss - 68.188.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:34:48 GET /weblog/SyndicationService.asmx/GetRss - 209.221.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:35:25 GET /weblog/SyndicationService.asmx/GetRss - 64.116.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:35:32 GET /weblog/SyndicationService.asmx/GetRss - 209.204.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:35:40 GET /weblog/SyndicationService.asmx/GetRss - 68.188.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:36:14 GET /weblog/SyndicationService.asmx/GetRss - 80.58.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:37:33 GET /weblog/SyndicationService.asmx/GetRss - 65.57.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:37:46 GET /weblog/SyndicationService.asmx/GetRss - 209.204.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:37:55 GET /weblog/SyndicationService.asmx/GetRss - 68.188.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:37:55 GET /weblog/SyndicationService.asmx/GetRss - 64.116.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:39:19 GET /weblog/SyndicationService.asmx/GetRss - 196.36.*.1* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:39:31 GET /weblog/SyndicationService.asmx/GetRss - 12.103.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:39:55 GET /weblog/SyndicationService.asmx/GetRss - 18.241.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:40:11 GET /weblog/SyndicationService.asmx/GetRss - 63.211.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:40:15 GET /weblog/SyndicationService.asmx/GetRss - 64.116.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:41:23 GET /weblog/SyndicationService.asmx/GetRss - 80.58.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200

The *'s are there to protect the privacy of the people accessing my RSS feed. However it is clear that not only is Google Desktop fetching my RSS feed every 5 minutes it is also not using HTTP Conditional GET requests. WTF?

Since I couldn't find a place to send feedback about this product, I've posted it to my blog. I hope Google fixes this soon, I'd hate to have to ban their client because it is wasting my bandwidth.

I am proud to announce that we have launched the MSN Developer Center on MSDN. This is culmination of some of the efforts I started driving shortly after writing the blog post MSN Developer Network? where I wrote

Yesterday, in a meeting to hash out some of the details of MSN Spaces API an interesting question came up. So far I've been focused on the technical details of the API (what methods should we have? what protocol should it use? etc) as well as the scheduling impact but completely overlooked a key aspect of building developer platform. I hadn't really started thinking about how we planned to support developers using our API. Will we have a website? A mailing list? Or a newsgroup? How will people file bugs? Do we expect them to navigate to http://spaces.msn.com and use the feedback form?

Besides supporting developers, we will need a site to spread awareness of the existence of the API.

After writing that post I started talking to various folks at MSN who were interested in providing APIs for their various services and realized that there was an opportunity for us to come up with a unified developer portal as opposed to a number of disjoint efforts. My argument was that instead of developers having to figure out they need to go to http://addins.msn.com/devguide.aspx to find out about extending MSN toolbar and http://www.viavirtualearth.com to find out about building MSN Virtual Earth mash-ups, we should just have http://msdn.microsoft.com/msn for all of MSN's Web 2.0 efforts. Everyone I talked to thought this made sense and now here we are.

Currently you can find information on extending or building applications with the APIs from Windows Desktop Search, MSN Toolbar, Start.com, MSN Virtual Earth, MSN Search, and MSN Messenger. In the near future I will be adding information about the APIs for interacting with MSN Spaces.

In addition to the developer center, we also have MSN Developer Forums where developers can discuss the various MSN APIs and interact with some of the people who work on the technologies.

Of course, this is just the beginning. Over the long term we have a bunch of stuff planned for the dev center including more APIs and more MSN properties joining the Web 2.0 party. This is going to be lots of fun.

PS: Shout outs go out to Jim Gordon, Chris Butler, Seth Demsey, Scott Swanson, Josh Ledgard and a host of others who helped make this a reality.

Surprise, surprise. Check out http://atlas.asp.net to try out a preview of Microsoft's AJAX framework. From the website

ASP.NET "Atlas" is a package of new Web development technologies that integrates an extensive set of client script libraries with the rich, server-based development platform of ASP.NET 2.0. "Atlas" enables you to develop Web applications that can update data on a Web page by making direct calls to a Web server — without needing to round trip the page. With "Atlas", you can take advantage of the best of ASP.NET and server-side code while doing much of the work in the browser, enabling a richer user experience.

ASP.NET "Atlas" includes:

• Client script libraries that provide a complete solution for creating client-based Web applications. The client script libraries support object-oriented development, cross-browser compatibility, asynchronous calls to Web services, and behaviors and components for creating a full-featured UI.
• Web server controls that provide a declarative way to emit markup and client script for "Atlas" features.
• Web services, such as ASP.NET profiles, that can add useful server-side features to an "Atlas" application.

It's great to see this getting out to developers so quickly. Kudos to Scott Isaacs, Walter Hsueh and the rest of the folks at MSN who worked with the ASP.NET team on this project.

In planning for our future releases, I came up against a design question that I'd like to see solved in future versions of the .NET Framework. The basic scenario is a website that wants to expose a web service using a number of different protocols (SOAP, XML-RPC, JSON, Plain Old XML (POX), etc) without having to write a lot of duplicate code. For example, the Flickr web services expose 3 interfaces for each method (SOAP, XML-RPC and POX).

From my perspective, this is something that should be handled by a protocol agnostic web services stack which is what the Windows Communications Foundation (aka Indigo) is supposed to be. On the other hand, the ASP.NET team's recently announced Atlas project is targetted server-side AJAX development.

What I want to know is basically this, if I want to create web services that utilize both SOAP & JSON does that mean I have to adopt both Indigo and Atlas?

Can some helpful soul at PDC ask this at any sessions on Indigo or Atlas? I guess I can always wait until next week and get the info from the horses mouth but product teams tend to give better answers to external customers than us internal MSFT folks. :)

Since my previous post on the various MSN sessions at PDC, two new ones have finally had their details announced. They are

PRSL02 - Case Study: How Hotmail Used Atlas and ASP.NET to Build a Great User Experience

September 14, 12:30 PM - 1:15 PM 152/153 (Hall F) Walter Hsueh

Microsoft's Hotmail web application team is developing the successor to Hotmail: a modern webmail experience focused on safety, simplicity, and speed. We will walk you through the scale and performance requirements of the Internet's largest distributed webmail application and show you how building on ASP.NET and Atlas technologies provides the right solution for the problem space. Learn from our experiences and design patterns of how we leveraged the "Atlas" programming model and "Atlas" components to build rich, interactive Web applications. PRSL04 - MSN: Extending Start.com Using Startlets September 15, 1:00 PM - 1:45 PM 408 AB Scott Isaacs/ Sanaz Ahari MSN's Web incubation team is creating a new AJAX-based personalized Web experience at start.com - here is your opportunity to get under the covers and see how we are building this site. Start.com allows for consumers to personalize their web experience to the things that matter the most to them. See how we build Start.com modules (Startlets) such as the Stock Picker, Weather Picker, and Blogger Map. Learn how to create your own custom Startlets for Start.com. We will also present how your RSS feed can also define a unique experience when viewed within Start.com. The Start.com team and architect will give you a tour of code you can use today. Join us for lunch and catch the latest wave of innovation from MSN's Web incubation team.

Shelley Powers has a post entitled Change starts at home where she points out the speaker list of the Our Social World conference is pretty homogenous (white males) and consists of the usual suspects when it comes to geeking about social software. I was quite surprised to see a comment in response to her post which stated

Shelley, you’re totally off the mark here. Firstly, there simply are not that many women working professionally on social software/blogging in the UK...Secondly, the speakers were self-selecting. Geoff who organised it put up a wiki and anyone could put their name down to speak. No women other than myself went to the effort of putting their name down and turning up... Finally, regarding ethnic minorities, you have to remember that the UK is not as ethnically diverse (and that that diversity is not as widely spread out) as the US .

I don't know about the UK but I do know that in the US, there are a lot of women in Social Software yet I keep seeing the same set of [white male] names on the speaker lists of various conferences on the topic. Given that this is the second post I've read today that points out the incongruities in the choices of geeks typically chosen as spokespeople for the social software world (the first was Phil Haack's Where are the Sociologists of Social Software) I decided to write something about it.

Just like with my Women in XML post last year, Shelley's post did make me start thinking about how many women I knew who worked with Social Software whose works I'd rather see presented than at least one of the presentations currently on the roster for the Our Social World conference. Here is my list

Non-Microsoft

• Danah Boyd - a Ph.D student at UC Berkeley who also is a researcher for Yahoo! Research in Berkeley. She has written a number of papers on social software including a number of interesting analysis of articulated social networks, specifically Friendster.

• Elizabeth Churchill - former project lead of the Social Computing Group at FX Palo Alto Laboratory, Fuji Xerox’s research lab in Palo Alto. She has produced a number of books and research papers on the topic of social software.

• Mena Trott - president and co-founder of SixApart, she is one of the folks that is behind the company that gives LiveJournal, TypePad and MovableType which are all excellent pieces of social software that are utilized by millions of people.

• Catalina Danis - a researcher on the Social Computing Group at IBM's TJ Watson Research Center. She has authored a variety of interesting papers on collaboration within small and large groups.

• Liz Lawley - currently a visiting researcher at Microsoft Research. She is the founder of the Rochester Institute of Technology's Lab for Social Computing

• Beki (Rebecca) Grinter - a Xerox Parc alum who's done a bunch of research on how teenagers use social communication tools such as SMS and IM.

• Wendy Kellog - she runs the Social Computing Group at IBM's TJ Watson Research Center and has been involved in a number of ACM conferences on Human-Computer Interaction (social software's cousin).

Microsoft

• Lili Cheng - former head of the Social Computing Group at Microsoft Research. A driving force behind innovative social applications such as the Virtual Worlds Platform and Wallop.

• Shelly Farnham - a researcher on the Social Computing Group at Microsoft research. She's worked on a number of innovative social software applications including Swarm (group-based SMS) and Wallop.

• Betsy Aoki - the head wrangler of Microsoft's corporate blogging efforts at http://blogs.msdn.com and http://blogs.technet.com

• Karen Luk - she is responsible for the weblogging aspects of MSN Spaces which is one of the worlds most popular and fastest growing blogging services.

• Gina Venolia - she was one of the researchers that came up with Sideshow which has inspired numerous copycats including the sidebar in Google Desktop and Desktop Sidebar. Currently researching the impact and effects of weblogging.

• Linda Stone - founder of the Social Computing Group at Microsoft Research. She was key in the creation of a number of interesting social software applications including Photo Story

• Nikki Santoro - she runs the client team for one of the most popular instant messaging clients in the world, MSN Messenger.

These women either are heavily involved in research around the sociological impact of technology and human interaction or actually work on building social software applications used by millions of people. Quite frankly, I'd rather hear any one of them speak than the typical geek you see at the average O'Reilly conference yaking about Social Software.

Unfortunately the people who really do the work that changes the world often get less publicity than the ones who just talk about it.

A couple more details of MSN's upcoming announcements of the various APIs we'll be opening up during PDC have come out. The write up with the best overview I've seen so far has been the article Microsoft Web plan takes aim at Google which states

Microsoft will detail its "Web platform" strategy at its Professional Developers Conference in Los Angeles next week, company executives told CNET News.com
...
At the developers conference next week, Microsoft plans to publish the API to its MSN Search service, which can be used by developers through the Simple Object Access Protocol, or SOAP. The noncommercial license will let people produce 10,000 search results per day per Internet address, said Seth Demsey, group program manager for MSN Search. Microsoft will release an API for its desktop search as well.

Also next week, the company will announce a free commercial license to use a JavaScript "control" to display data from its Virtual Earth mapping service. The MSN Messenger group, meanwhile, will allow developers to write Windows applications that make use of the "Activity" window. This would allow a customer service representative, for example, to display customer information in a chat session.
...
Next Thursday, Microsoft executives will discuss a developer program for Start.com, an MSN incubator Web site that consolidates information from RSS feeds and other Web sites onto a single customizable page.

That's right, during the PDC we'll be announcing developer programs for four MSN properties; MSN Virtual Earth, MSN Messenger, Start.com and MSN Search. Unfortunately, MSN Spaces isn't on that list but this is mainly due to logistics reasons and not because we won't be opening it up to as a platform for developers.

Of course, there are more details from the horses mouth.

MSN Messenger
From Leah Pearlmann's post about the MSN Messenger Activity API we learn

The release of the API will be announced at the upcoming Microsoft PDC next week in LA. Along with this announcement will be another for a contest
...
Starting next week, you, yes you, can download the Activity API, build an Activity using the competition guidelines, and submit it. You Activity will be posted in the App Gallery where people around the globe can try it out and vote for it (which they will, because YOURS will be the best).

Activities will be judged based on creativity, usability, inclusion of MSN services/features and number of popular votes. Besides the most valuable reward – unlimited bragging rights— you can also win:

• Alienware Area 51 laptop with armored case (grand prize)
• Aurora Desktops (1^st runner-up)
• Oakley Thump sun glasses with built in MP3 player (2^nd runner-up)

For more information, go to visit this forum or wait until September 12^th and then go to http://www.worldsbestapp.com and http://msdn.microsoft.com/msn/messenger

I've been involved in the discussions on opening up different parts of our IM client and it's great to see some of these efforts begin to bear fruit. Once the contest is live, don't hesitate to post questions to the developer forum. I'll be watching as will several folks on the MSN Messenger team.

By the way, the MSN Messenger PM team is looking for someone with experience to drive their audio and video efforts. If this sounds like your cup of tea, then check out the job description and maybe even respond.

MSN Virtual Earth
The big news here was posted by Chandu Thota in his blog posting Virtual Earth APIs available for commercial use (and they are FREE!) where he wrote

Here is the good news folks: We are now offering the MSN Virtual Earth API for commercial applications free of charge to developers.  This APIs include the JavaScript map control and local search service (exposed via the What/Where search boxes on Virtual Earth site today). 

Here are some important notes about this release:

1. Maps are available in U.S. only and does not include any routing capabilities. In the future we will add European and Asian geographies. 
2. In order to use the API for commercial applications with no charge, your application must use the local search service on the map (the What/Where search boxes)
3. There is no SLA for Virtual Earth enabled applications until January 1, 2006.  Also, if you choose to use Virtual Earth in your production environment before the end of 2005, you must notify the MSN Virtual Earth team first in order to ensure capacity
4. MapPoint Web Service and Virtual Earth platform are not integrated (yet!)

 Now how does the future look like? On January 1, 2006, you will have two additional options to choose from to fit your commercial application needs:

1. You can use the Virtual Earth APIs for free as long as you use the What/Where search boxes on your map. This is also makes sense from a revenue stand point since you will have the opportunity to make money by placing advertisements on your site in a revenue sharing model (more details to be announced at a later date)
2. If you do not want to utilize the What/Where search boxes on your site or advertising, you can use the Virtual Earth API under your current MapPoint Web Service contract. In this scenario you will be charged for transactions through the Virtual Earth API. Note that this option comes with SLAs. 

There you have it - now you have what you are waiting for: the opportunity to integrate maps into your applications at free of cost (as long as you use the What/Where search boxes). I will be writing more about how to integrate maps and the What/Where search boxes into your web applications on this blog in my future posts. In the mean time, don't forget to check out ViaVirtualEarth to learn how to build applications using Virtual Earth Map control (and to win $1000!)

That's right, they have a developer contest going on as well. I'd hoped to have my article on building my Seattle Movie Finder page up by PDC to give folks a place to start when building their first mapping mash-up but I never got enough spare time at work. The article should be done by next week and should hopefully show up online the week after PDC.

Dion Hinchcliffe wrote a blog entry entitled State of Ajax: Progress, Challenges, and Implications for SOAs  which did a good job of pointing out the [somewhat obvious yet not so obvious] link between web services and AJAX. For those who don't have time to wade through his entire post, the key bit is

Lightweight SOAP and REST services are in and WS-* services may be on the rocks. Since Ajax applications can and will frequently call backend XML web services as the user interacts with the front-end, having lightweight, easy-to-consume, high performance/availability SOAP and REST web services will only become more important. Of course, the implication is that since Ajax applications live in a fairly austere JavaScript sandbox, this means heavy-duty WS-*-style SOAP stacks probably won't play well with the lightweight XML/JSON service interactions that Ajax prefers. This doesn't mean WS-* is broken for Ajax, but at this time there are no Ajax frameworks yet that support more than basic SOAP service interaction.

There's some stuff I agree with here but a lot I don't. Personally I think even lightweight SOAP services are out in the AJAX world. As it stands, lots of AJAX developers are trying to eschew the overhead of XML for the simplicity of JSON let alone the overhead and complexity of SOAP. The fact is that most AJAX applications talk to lightweight REST services with either XML or JSON being the wire format.

This is yet another example of the dichotomy between providing services for the Web and building services for using within an enterprise's intranet.

Surprisingly, it seems some people fail to acknowledge this dichotomy. One of these people is Nick Malik who in his recent post On Atlas/Ajax and SOA stated

I ran across a blog entry that attempts to link Atlas/Ajax to SOA.  What absolute nonsense!
...
So what's wrong with having a browser consume enterprise web services?  The point of providing SOA services is to be able to combine them and use them in a manner that is consistent and abstracted from the source application(s).  SOA operates at the integration level... between apps.  To assume that services should be tied together at the browser assumes that well formed architecturally significant web services are so fine-grained that they would be useful for driving a user interface.  That is nonsense.

For an Atlas/Ajax user interface to use the data made available by a good SOA, the U/I will need to have a series of fine-grained services that access cached or stored data that may be generated from, or will be fed to, an SOA.  This is perfectly appropriate and expected.  However, you cannot pretend that this layer doesn't exist... it is the application itself!

In a nutshell, the distinction is in the kinds of services provided.  An SOA provides coarse-grained services that are self-describing and fully encapsulated.  In this environment, the WS-* standards are absolutely essential.  On the other hand, the kinds of data services that a web application would need in an Atlas/Ajax environment would be optimized to provide displayable information for specific user interactions.  These uses are totally different. 

This is probably one of the most bogus posts I've ever seen written by a Microsoft employee. As Nick points out, the point of providing services is to be able to combine them and use them in a manner that is consistent and abstracted from the source application.

For example, my Seattle Movie Finder web page is powered by a RESTful web service which gives it information about movies currently playing in the Seattle area. The URL http://www.25hoursaday.com/MovieFinder/MovieFinder.aspx?showall=1, gives me an XML list of all the movies currently playing in my neighborhood. The web page is an AJAX application that consumes this service. This information could also be consumed by a smart client on a desktop or another service which augments the data (e.g. merges in the movie critic ratings to the various movies before sending to an end user). Claiming that because this service doesn't use the various WS-* technologies and is being accessed from a web browser somehow makes it illegitimate is just plain ridiculous.

Furthermore, it is quite likely that the various services that are used to gather this information aren't RESTful. However what works within the intranet isn't necessarily what works on the Web.

An interesting challenge I've faced at work is convincing some of the developers on my team that just because we use SOAP for the services we use internally, this doesn't mean we may not use alternate appproaches for Web facing services. This issue first came up when we decided to go with the MetaWeblog API as the blog editing API for MSN Spaces and I'm sure it will keep coming up.

When you have a hammer, everything looks like a nail. SOAP/WS-* are not the answer to every problem and just because they can't be used in a particular problem space doesn't mean that problem space any less valid than others. The sooner people understand the dichotomy that is intranet vs. internet service development, the better.