Internet Platforms

Marc Andreessen has posted about the types of platforms you encounter on the internet.  You can read the post here.  He describes three types:

• The Access API
• The Plug-In API
• The Runtime Environment

The Access API is where a "traditional web" API is provided (probably a web service API exposed as SOAP or a RESTful interface.)  Your code runs outside the platform (think using the Flickr API on your blog.)

The Plug-In API, long common in desktop apps, is starting to appear on the web – e.g. Facebook apps.  Your code still runs outside the platform, but it appears within the platform.

The Runtime Environment provides an environment in which your code is hosted and runs.  Something like Popfly is an example of the third type – but, interestingly, allows you to consume and combine the first type.  This third type of platform lowers the barriers to programming – by providing a hosting and runtime environment and, in the case of Popfly at least, loads of examples – and sharing the results of your programming adventures.

.NET 3.5 source code available

In case you haven’t noticed the buzz, Microsoft are making the source code for .NET 3.5 available for download.  Full details can be found here on Scott Guthrie’s blog.

The Service Bus

In any reading or discussion about Service Oriented Architecture, it’s nearly impossible to avoid the concept of the Enterprise Service Bus.  First off, it has a great name – sounds like something Captain Kirk uses to get to work.  Secondly, it seems to be the Answer.  It connects everything together and routes and mediates and adapts and does other stuff like that.  In addition, some of these ESBs have automatic deployment and built-in development tools.

Of course, no-one can quite agree what an Enterprise Service Bus is.  Nicholas Allen, in a post about various definitions, notes:

“When I first read about ESBs in 2003, I didn’t expect to still be trying to understand them more than four years later. In comparison, there have been other technologies that in the same time frame were introduced, developed, matured, and obsolete.”

I’ve even read Enterprise Service Bus – which explains what an ESB could be in a java-centric way – and, yet, there’s this nagging doubt.  The first problem is the lack of consensus on what an ESB is or should be.  The second problem is the sheer scope of the included functionality.  I don’t like TVs that have integrated DVD players so I’m going to need some convincing that bundling the routing, transport, adapting, mediating, deployment and development into one piece of (often proprietary) software is a good idea.

Another problem with the ESB concept is the startling lack of ESBs in the .NET space.  There’s plenty in Javaland, but few, if any, in .NET.  At first, it’s easy to take this apparent gap as Microsoft missing something.  However, I’ve come to think that there may not be one in .NET because you don’t need one.  You do need transport.  You may need routing and mediating.  You might even need all the rest of the functionality of an ESB.  But you can get what you need and plug it together.  Doing so allows you to build as much infrastructure as you need when you need it, which means you can focus on delivering some useful software instead of an expensive infrastructure project.  There’s plenty of technologies you can use to implement this sort of approach (think WCF, MSMQ or JMS, BizTalk.)  There’s even guidance from Microsoft about building an ESB or you could look at Udi Dahan‘s NServiceBus project.

This modular approach has a lot to recommend it.  But it doesn’t have a cool name.  Now, if we can sort that out, it might just catch on.