What's In Microsoft's "Strata"[?] Cloud OS

(Probably)

Just for fun, let's do a little educated speculation on Microsoft's "cloud os" initiative. It's not too hard to make some good guesses -- Microsoft's existing and unreleased products telegraph a lot about what they are likely assembling. For example, the semi-well-known "COOL" and Visual J++/WFC gave you most of what needed to know to imagine the real .Net platform.

There are lots of pieces out there -- certainly enough to comprise a pretty interesting cloud stack and application model.

Since Microsoft -- and platform vendors in general -- like to go all out, let's imagine this stack reaching from real hardware up through virtualized hardware up to application servers and then to client components and the end-user's browser or alternative on the other end.

Let's start in the middle of this stack and work our way out.

What would the "middle" look like? Well, what makes a hosted ASP.net account different from a cloud platform? Some answers: storage and bandwidth may not be elastic; clustering the app is neither automatic nor declarative, but requires programmatic and operational work; the database is typically a SQL Server instance (perhaps a mirrored failover cluster) with all of the usual capabilities and scaling constraints.

So imagine a hosted ASP.net account with a few changes that address these limitations.

First, swap in an alternative implementation of sessions, that supports clustering, proper caching, etc., with zero config. Add a lint-like tool to warn about code that isn't properly stateless. And an asynchronous worker service for any long-running, background, or scheduled tasks that could be "fudged" with threads or events in a controlled Windows Server environment, but won't work that way in the cloud.

Next, replace the datastore with something like ... SSDS, and a LINQ provider so that in many cases code won't need to be changed at all. The interesting thing about SSDS, of course, is that unlike other non-relational cloud datastores, Microsoft has said the roadmap will offer more relational capability (subject to constraints, no pun intended). So ASP.net apps that need real relational behavior might have an easier time moving to this new datastore.

So, without much new, we have a flavor of ASP.net that is more cloud-centric and less server-centric.

Now on the hardware and VM end of the stack, bear in mind also that -- to add value and sell the Server product, as well as to service enterprises which would like cloud architecture but need parts of the "cloud" to stay inside the firewall -- the whole enchilada is likely to be available as a service (or its own SKU) on Windows Server.

In fact, a number of Microsoft products related to modeling data centers, virtualization, and automated migration of services and machine images suggests that a key thrust of the "cloud os" might be that a customer can easily move services from individual servers up to a private cloud implementation and on to one (or more -- perhaps an opportunity for the hosting partners) public cloud data centers... provided they are coded to conform to the API.

ADO.Net Data Services (aka Astoria) already supports AtomPub, the format Microsoft is using or moving to for all of its Live services, so minimal wrappers (not to say minimal effort in the API design) could turn this into a platform API. A simple using directive brings in a File object and API that works with Skydrive instead of My Documents.

Last, look at the client end of things. Right now, we have ASP.net serving web pages, and we have web services for Silverlight clients. There is also a project (named "Volta", and which has just recently gone offline while a "new version" is in the works) aimed at dynamic tier splitting and retargeting apps in terms of the client runtime. Hmmm... Sounds like a critical part of the front end of the cloud os stack.

In order to provide a RIA experience via Silverlight (or even desktop experience for a cloud-os edition of office), promote the client os product by offering a best-of-breed experience on Windows clients, and at the same time offer a legitimate cross-platform web-browser-consumable app, a piece like Volta is critical, and makes complete sense.

Microsoft tends to hunt big game, and I doubt they are interested in a me-too web app environment. They really intend to offer a cloud os, allowing developers to code libraries and GUIs that are outside of the web paradigm. These bits can run as .Net on Windows ... as .Net in Silverlight on Mac or (one day) Linux ... and as Javascript apps in non-.Net-capable browsers.

The big question in my mind is timing -- how far along are they on the supportable, RTM version of this stuff. Whether this is relevant -- or even becomes a reality -- will depend on how fast they can get this out of beta.

It seems that when Microsoft is quite close to production with a platform they can grab enormous mindshare (recall the release of the .Net platform). If this is an alpha look, with no promised timeline, things are a lot more tenuous. If there is a 1.0 planned before mid 2009, this could make things interesting.

Amazon EC2 to Support Windows Server AMIs

Jeff Barr, Amazon Web Services Senior Evangelist, just finished giving a talk at "The AWS Start-up Event – San Francisco" in which he showed slides listing upcoming plans at AWS, including support for Windows Server.

This is an exciting development, as Windows Server / ASP.Net make for a fantastic if potentially expensive platform. Now Microsoft has to step up to the plate and come up with a pay-as-you-go, per-cycle or per-cpu-hour licensing scheme.

One of the things that makes ASP.Net interesting is that it lives in a nice middle ground between Java, which is extremely fast (in EC2, this means less expensive per transaction) and has great "enterprise" capabilities but is cumbersome to develop with, and, say, Rails, which is quite slow and has poor enterprise app cred but is very pleasant and lightweight to develop with. ASP.Net, especially with the MVC framework and forthcoming support for Python and Ruby in addition to C# and the other .Net languages, seems to combine extreme performance, easy development, and access to as much "enterprise" as you need while offering lightweight alternatives like LINQ and SSDS.

My point isn't to make a commercial for ASP.Net, but to point out that if Microsoft can get their licensing in order, they might catch up in the cloud world through fast, cheap development cycles plus faster (and hence cheaper) runtime operation on a given machine instance than some competing platforms.

Just to be fair, cloud vendor enomalism has run Windows Server on EC2 before, by virtue of the Qemu emulation software (on top of Linux). But if we're talking about maximizing efficiency, wasting cycles on another layer of emulation (EC2 instances are of course virtual to begin with) doesn't sound like the way to go.

Public Domain Reprints Offers a "Transactional Web" Mashup

Some time ago I wrote about how the "programmable web" has really turned out to mean the queryable web, because real transactional APIs have not been readily available.

Public web services (with a few exceptions, mainly around payments and online file storage) are a way of retrieving state. Using web services to execute useful "write" transactions into other systems has turned out to be the business of enterprise SOA, not late-night hacker camps.

The concern, of course, is over users "getting it wrong" when insufficient semantic data is available. Although that's a bogus argument (many industries and services have solid semantic models that are readily accessible from web service descriptions), most folks seem to be waiting for the legendary semantic web to come along.

But "most" isn't "all," and I was glad to see O'Reilly write about Public Domain Reprints, a transactional mashup that submits books to print-on-demand services where you can later order a copy.

Although Public Domain Reprints is just formatting and "preparing" the book -- you still need to order a copy yourself from the service of your choice -- the mere adding of an item into a print-on-demand service's catalog is fairly exciting given how rare these "commit data"-type open web integrations (mashups) are.

At this stage, it doesn't really matter what sort of integration mechanism is used -- it needn't be a web service; it could be emailing a PDF into a dropbox, or simulating a file upload from a web form. Obviously, having a "strong" interface (including some kind federated authentication, so that a mashup can act on my behalf using a restricted token and not my password) will make more services feasible.

I continue to hope that we will see more services that don't just pull down a bunch of data and create a nice report, but actually reach out to services I use and improve my life by doing a little bit of work for me.

Looking For: a Reverse-Search Web Service (aka Semantic Analysis the Easy Way)

For one of my projects, I'm looking for a web service that does search "backwards" to reveal page semantics. If anyone can point me in the right direction, I'm all ears!

What do I mean by backwards? A normal web search service (Google/Yahoo/MSLive API) takes a set of search terms and other conditions and returns the web pages that best match.

A reverse search takes a URL and returns the search terms for which this page scores well. I call this Semantic Analysis the Easy Way because, strictly speaking, it doesn't require actually understanding the content of the page -- yet you can get semantic data out. Of course the better your content analysis engine can understand the content, the better your search engine will work, so the hard problem figures in a little bit too.

The big search engines certainly have the data -- I'm sure it plays a big role in ad-placement mechanisms like AdSense. Just as the search engines expose their search APIs, confident you can't (or won't be allowed to) steal their search results and pretend they're your own indefinitely, they could theoretically expose the reverse search data too. But sadly, I haven't found one yet that does.

I did the requisite scan of the major players, looking through programmableweb, etc. No dice. (Although programmable has a link to an interesting "hard way" semantics service that did a nice job of analyzing the text I threw at it from real pages.) The closest I've come so far is the del.icio.us URL API, which will tell you the top tags associated with a specific URL -- valuable data indeed, but not the same thing.

Little help? Anyone?

Thanks!

Amazon SimpleDB isn't Astoria... it Could Be, but Does it Need to Be?

A while back I wrote about Microsoft's Astoria REST-based relational data store in the cloud (or in your data center, if you want it there).

With Amazon's SimpleDB, we're a step closer to making this vision a reality. Now we're almost on track for competition (and sooner-than-later commoditization) of the new world where you don't even need MySQL to store your stuff.

Why almost? Because SimpleDB is not a full RDBMS, but is looks more like a flavor of triple store. Now, a typical (i.e., SQL-style) RDBMS can be built on top of a triple-store fairly easily. So we could will see a SQL processor, JDBC drivers, and the like, from the community pretty soon.

Another way to look at that "top layer" is to take a REST API like those used by Astoria or ActiveResource [PDF link] and simply implement that. Not as expressive as hardcore SQL, but easier, and probably enough for many applications.

What I don't see -- in the long run anyway -- is applications developing against thin wrappers specific to the Amazon triple store service itself. There's nothing fundamentally flawed in doing so ... it's just that, for a variety of reasons, data storage has evolved very slowly. The relational model is going on 40 years old, but still reigns supreme in terms of popularity, even if it has conceptual or technical flaws when put to work in today's applications.

Given the brilliant data storage alternatives that have fallen flat time and again, I doubt Amazon SimpleDB will change the way people talk about storing structured data. So SimpleDB doesn't need to be SQL but it will probably need to at least be RESTful.

Microsoft Will See Your Web Services and Your Horizontal Database Scaling, and They'll Raise

Don Box has come out in defense of Microsoft's support of REST technologies a number of times. And this year we've started to see what else is behind the curtain, with project Astoria. Still being designed and built, but with bits available and integrated into VS2008 today, Astoria includes both local (your own machine/datacenter) and cloud services for data storage that support HiREST, relational modeling, and support for various data formats (JSON, POX, Web3S [the last a play on, and jab at, S3?], ATOM).

If you haven't seen these services, you need to check them out. In addition to being technically interesting (e.g., since queries can be expressed via REST-style URLs, your network appliances and front-end web servers can actually participate in execution or caching strategies!), these services are likely to be a big part of the web service landscape.

Whether you love Microsoft or not, it is fairly clear that the original ASP.NET SOAP implementation (and client generation) were years ahead of anyone else in terms of no-nonsense ease of use, compatibility, and extensibility.

These SOAP components were made available to developers in 2000 or earlier. They brought things like "Type [WebMethod], ok now you have an XML-RPC SOAP service. You're done, go home, have a beer," while Java was still trying to figure out how which alphabet to jam into the end of their JAX* wildcards, and inventing APIs where you just start off with a nice ServiceFactoryBuilderConfiguratorFinderInstantiatorFactory and go from there.

Why rehash this history? Because in its final form, the Microsoft solution is going to be influential. They may be late to the party here, but don't discount them.

Enterprises need service description layers for REST. Someone is going to give it to them in a way that they can use it. And an Amazon-S3-scale relational data service in the cloud (no, Freebase and the like don't count) could be really interesting to everyone who doesn't have enterprise, need-my-data-physically-in-house requirements. With ActiveResource a core part of Rails 2.0, I could see building read-heavy apps using caching and Astoria, and no local database at all! My clustering problems (and expense) have all just become someone else's problem!

There's something else to see here too: read the Astoria dev team blog and the comments. You're watching Microsoft designing and implementing a big API in real time with interaction from the community. Don't look for an open-source experience -- you can't check out the code and send patches. But there is a lively discussion going on between the development team and outsiders to try and come up with the best solution that fits the constraints.

ASP.Net Hack for Processing SOAP Faults on Clients that Hate the HTTP 500

Occasionally you may need to execute some SOAP operations using a client that doesn't understand SOAP. If this client doesn't like the HTTP 500 that comes back when the server generates a SOAP Fault (behavior specified in the SOAP spec), you may not be able to read the content that comes back, with the actual fault XML in it.

For example, I recently needed to use URLLoader and HTTPService to access a SOAP service in Flex, because the WebService (SOAP) implementation didn't like the server's WSDL. Admittedly, the WSDL included some legacy XML schema, and was a bit unusual, but it did validate. So it seems plausible that other valid services might also be inaccessible to the Flash/Flex WebService or other SOAP clients.

With HTTPService and ActionScript 3 E4X support, it's not terribly painful to do the SOAP client work yourself... until you get a SOAP Fault. The 500 causes HTTPService and URLLoader to abort and they do not return the document content to the application.

In this instance, I couldn't alter the web service itself, and didn't have the resources to build a new HTTP client on flash.net.Socket. That's the setup. Here's the hack, for IIS/ASP.net services:

Concept: alter the ASP.Net processing pipeline to return OK (HTTP 200) in place of a 500, but only when the SOAP fault is the cause of the 500. The way to do this is to use an ASP.Net facility called a Soap Extension to allow programmatic reading and/or writing to the SOAP message stream as it passes into and out of the application. Find the message in the state you don't like. Alter it. Done.

1. Create a C# DLL project in Visual Studio and pull in boilerplate code for a System.Web.Services.Protocols.SoapExtension (MSDN docs and MSDN magazine have sample code, or look here)
2. Pull out everything you don't need (which is most of it, if you're looking at a real-life sample)
3. Locate the ProcessMessage method, and check for the SoapMessageStage.AfterSerialize lifecycle value. In most samples, there's a switch statement on the SoapMessageStage, so you can just identify the proper branch (the others should be blank for this basic solution)
4. Add the following code:
      if (message.Exception != null)
         HttpContext.Current.Response.StatusCode = 200;
5. Build. Place resultant DLL with other precompiled binaries used by the ASP.Net application.
6. To tell ASP.Net to use this extension, add the following XML tag to the application's web.config, and all SOAP calls will use your extension. Find (and/or create) the <soapExtensionTypes> tag (under <webservices>, under <system.web>), and add


<add type="YourSoapExtNamespance.YourSoapExtClassName, YourSoapExtAssemblyName" priority="1"  group="High" /> 

That's it. One line of code, a little configuration, and your hack is on. For a little more context, I've put the full SoapExtension class here.

No. It's Just About the Metadata.

If an ad-supported blog exists to stir the pot then I supposed the GigaOM network's future of software blog is succeeding. I thought the first post was tennis without a net. Actually I also thought the second post was tennis without a net. And now I think the latest, "Web Services war is over: Time to Rest" is just bogus hype. Not that REST isn’t gaining ascendancy, but it’s a case of the straw man fallacy.

The war was never between REST and WS-* specs: the WS-* specs have been despised, ignored, and abused since their introduction.

Nor is it between REST and SOAP (and the xml schema documents that go with SOAP, which are also despised) which WS-* was meant to supplement.

It’s a war of describing operation semantics versus hoping that they will be “implicitly self-describing” and that everyone can agree on what GET, PUT, DELETE, POST etc. mean.

 The latter, which is the purist REST position, works well for documents (e.g., HTML pages on the web), and alright for basic business objects (calendar appointment, car maintenance record) but gets a lot trickier for transactional services like “change John's seat on the second jetBlue segment today to 13A, or else the window seat closest to the front of the cabin, or else fail fast and give me a set of alternate available seats.” Can this be done with REST? Yes … kinda sorta … but the call will not be one of those trivial “implicitly self-describing operations on an entity” that REST works very well for.

The good news is that, in reality, both camps are converging on a compromise: REST with (optional) metadata: WADL, OpenSearch, WRDL, even the much-maligned (and for good reason) WSDL 2.0. The metadata supports tooling, automated strong bindings, better testing, automatic integration to enterprise object buses etc.

This is a philosophical step away from REST, but this is actually what we’re seeing coming down the pike for enterprise work, and the SOAP and WS-* people will be just fine with it.

Wanted: A VIP (VPN?) Room for Web 2.0 Apps

I am working on a project with a team in New York, San Francisco, and Noosa, Australia. It's a bunch of really smart folks and we have a good time ... but collaboration and communication could always be better.

I would love to cook up a little social networking site for our project work using, say, Ning. In addition to the basic stuff like messaging and chat, we could embed this box filesharing widget, put up videos and photos (ok, our photos are mostly of whiteboards, but we count that as fun), audio recordings of meetings, maybe a gizmo or skype or grandcentral widget for click-to-call. Maybe plug in some WYSIWYG wiki editing.

But we can't do that because of security and nondisclosure concerns. IndustryNext doesn't harbor a lot of secrets, but our clients may -- especially when it concerns upcoming and unannounced products that we're building with them. And our confidentiality with clients means that we won't put their project data into a shared SaaS environment.

So what can we do? The other extreme (from fully shared Saas) is to acquire the apps to host in-house. But that's not an option with many of these services, for good reason.

I propose that a third party build a business hosting secured and partitioned areas where instances of these apps could live. Of course going down this road starts to break the business model that makes many web 2.0 services viable. Without shared hosting infrastructure, and with the added hassle of supporting a "customer" deployment (even if the hosting service is a very sophisticated customer), advertising won't pay all the bills anymore.

But that's ok: I'm willing to pay some money for secure, semi-private access to these apps. It's way cheaper than any alternative I'm aware of, and would have a positive impact on our productivity. Moreover, since the apps are already built and deployed, it's all gravy -- a new revenue line -- beyond the actual hosting and the maintenance (from the app provider to the host).

Does something like this exist? If not, any takers?

OpenKapow Fun: Scraping an AJAX Site

I'm interested in web services which represent operations that make a persistent change in the non-web world. Like buying a ordering food or checking in for a flight. These capabilities exist as human-powered web workflows today, but rarely as remixable web services. Sooner or later, that's going to change.

Many of these services resist initial attempts at scraping and remixing because they contain AJAX elements such as scripts that rewrite the DOM. Scraping such a site is more than a little challenging, since you either need to analyze exactly what the scripts do and try to grab and run just the scripts you want, or else you need to emulate a Javascript enabled browser and then scrape the screen when the script is finished and the DOM is in the "right" state.

One tool that seems promising in the quest to tame these sites is the openkapow service host and its Robomaker IDE, which both work by hosting a Javascript-enabled browsing engine. The IDE combines this engine with a set of tag-finding and flow-control tools so that you can point-and-click your way to a script that automates the target site.

I've been looking for an excuse to build something transactional with Robomaker, and I hacked up REST services that execute a checkin or an offload ("un-checkin") for a passenger on a United Airlines flight. It worked for me on a couple of flights. But without having a large sample of itineraries that I could abuse in the testing process, I was a little uncomfortable with how the robot might handle some multisegment flights. The source (".robot" XML files) are available here though if you want to try it out or tinker. Seat selection would be an interesting and nontrivial feature to add...

So I reined in my ambitions a little and created a service to get flight schedules, in order to add automation to a small Office 2007 tool I'm working on.

The Airwise flight schedule page seems simple enough at first glance, but turns out to be one of those pages that uses script to write the DOM data that the user ultimately sees. That makes it a perfect candidate for ... RoboMaker!

It was straightforward to configure my robot to enter travel dates and airports into the form, click "go," and find the table with the results. What I wanted to do was look through the table rows, create XML snippets for the data, and package them up into a response.

But here's where my inexperience with RoboMaker and impatience got the best of me: once I got beyond the point-and-click part of automating the web page, I wanted to just write some imperative code to pack up my XML. Since RoboMaker is a Java app, I wished I could just write a micro-plugin for this stage of my robot in Java. I found the deep spelunking in dialog boxes, squirrelly regular expressions, and mediocre help docs to be frustrating.

Maybe the idea is to give me a taste of Kapow so I'll license their enterprise technology, which isn't free. Not sure about that. But I did know that I could dump the entire flight schedule table as the service response and deal with it on the client. So I selected to return the whole table content as "advanced structured text" (which basically translates into plaintext with newlines in between every table cell).

Although on the client it's trivial to parse the resulting data set and find what I want, I feel a little guilty about the ugliness of the XML response. You can view/use/download/edit the REST robot on the openkapow portal, and if you run it with the defaults you can see the mildly embarrassing chunk of XML produced (in the browser, the newlines in XML are ignored, so it looks even worse). A REST call looks like this.

I got over my issues with the service, though, and moved on to using the data for my Office plugin, which I'll post about soon.