This is the part most people that read blogs see. Why? Well, it’s “The air that we breathe” – if you didn’t already have an interest in this space then you probably wouldn’t be reading this. (Isn’t circular justification fun?)
Anyway, the online components that I’m starting with are going to be:
If you don’t know what this is – you’ve probably not been paying attention to the Social Computing Scene (or online at all for that matter.) Twitter is the current darling of the Hyper Connected crowd and as I write this has just really hit mainstream.
Twitter is a basic messaging system, the behavior of which tracks all the way back to mainframe chat systems written in COBOL and Assembly in the 60’s. (Status) Messages are limited to 140 characters and can be entered from the twitter web site, SMS messaging, or through the Twitter web API that has been published. Messages are highly unstructured, though unofficial structures are formed, refined and abandoned in almost real time. One of the major features of Twitter is that all messages have a permalink and can be referenced by anyone. It has been noted that a quick twitter app is in danger of supplanting “Hello World” as a demo/quick intro program.
This is the foundation of the Azure cloud platform, basically the compute and storage layer, plus the group of development tools to make it simple to work with the capabilities (and develop offline until you’re ready to deploy.) Azure is basically a way to have control over code that can be executed remotely without worrying about setting up hardware or provisioning systems. It has been designed to be a platform where code of a wide variety can be executed securely and without the need for system level maintenance and monitoring. I’ll be using this to provide both web interfaces, always on services, and the ability to store data remotely to handle situations where connectivity with my offline components may be intermittent or bandwidth constrained.
This is another set of online services that builds upon the Azure capabilities, providing pre-built features that are commonly needed. .Net Services currently provides capabilities around Access Control, Internet Service Bus, and Workflow Services. These are resources that can be used either by themselves, with Azure hosted code, or with local code to make development quicker and simplify those nasty code maintenance costs. I’ll be using all of these component, starting with the Internet Services Bus and then expanding out through the Workflow Services for state management and ending up with a foray into security.
Live Services are a set of services that many people are already using and familiar with through such offerings as Live Messenger, Live Mesh, LiveID and the like. I’ll be focusing here on some of the Live Mesh features, but spreading out through the rest for capabilities such as geospatial, search, presence and other functionality to take advantage of.
Note this isn’t a comprehensive list. As this project is a work in progress, I’m sure I’ll tie some other components in, and may change my mind on some of the ones listed above. There’s a lot going on in the Online space and things change faster than I can keep up, so I’m assuming I’ll get notified somewhere along the way about something really cool that I’ll need to add which will expand or take the place of something I’ve listed above.
Next – The offline component.