|
In previous blog posts on peer networking, I have talked about the various ways in which you can build a peer application, the ways to share state in peer networks, and even the ways that peer networking applications fall short. Namely, the biggest problem with a true peer-to-peer networking application is that it requires 2 instances of the application to be online at the same time in order for shared state to be synchronized. There are other issues with peer networking as well, such as the publication and discovery of peer services (this is where I talked about Bonjour and PNRP) and the problem with publishing a service from behind a firewall that creates "false positives" - you think you can reach a peer because you can see their service publication but you can't actually talk to the peer because you can't push through their firewall on a given port.
Enter Windows Live Mesh. I'm not going to talk about Live Desktop or any of the GUI nonsense that you see floating around there. It's still beta, and GUI is subject to change. The important thing to remember is that Live Desktop and the file sharing aspect of Live Mesh are nothing more than implementations of applications written using the MOE SDK. So what is MOE?
MOE is the Mesh Operating Environment. This is the guts of the entire Live Mesh feature set. Without going into too much detail, the MOE is built around the concept of feeds. In fact, your mesh is really a feed of feeds, which is used to create a hierarchy of information pushing and pulling. In addition, Microsoft makes use of FeedSync, something they created a while back that uses ATOM standards to synchronize data changes between two peers using feed-style data. So, under the hood what you're looking at is information publication and retrieval using extremely powerful, very flexible, industry standard XMl-based feeds. Other parts of the MOE, from what I can tell from the limited information I have, include the ability to establish peer connections through the MOE that will work regardless of whatever firewall/NAT may be in place between the peers. This is a ridiculously powerful feature that cannot possibly be hyped as much as its true value indicates.
So now put yourself in the position of an application developer and you're building an application sometime in the next couple of months. You want this application to be able to talk to other instances of your application on the internet, globally, and you want to do that without having to worry about hassling with PNRP or Bonjour. You also want to be able to send direct data to peers on demand based on user action, and those peers could be "Joe Internet User" types who are sitting behind a typical Linksys firewall/router in a standard port-blocking scenario who also have a 192.168.x.x address that is different than their public-facing address. Finally, you want your application to be able to modify data while no one else is currently using the application, but you want that data to be available to other instances as soon as they start up.
Let's take the bank ledger example I talked about for the state sharing scenario, but let's "Meshify" it and see if it becomes more appealing. You start the application up and immediately you see new transactions appearing. Looking at the transactions you see that your spouse entered a bunch last night from their smart phone. There is a little "news" style panel that shows what your spouse did, including a note indicating that there's a discrepancy between you and the bank for a transaction - your spouse wants you to call the bank about it. You enter a couple of your own transactions and then shut down. Later, you log in from another laptop and all of the transactions that were missing from your laptop are downloaded. You see the items created by you and your spouse, including where they were entered (e.g. office, mobile, home, etc). You call the bank and find out you were wrong and so you go back and edit the transaction in question. Your spouse, who is now online from home, immediately receives the change - the modified number swells a little and bounces with a WPF animation and the news panel indicates that you changed the value along with a note indicating you talked to the bank.
Microsoft may be approaching pie-in-the-sky territory with their grand vision of software and services and the whole "apps are in the cloud" concept, but, let me just say this: If Live Mesh works as advertised, it will quite literally change the way we think applications should talk to each other. Applications that do not do what I just described in my sample scenario will be considered broken and/or old-school.
Personally, I can't wait until I get my hands on the MOE SDK and write my first "Meshed" application.
Atom isn't capitalised generally, as it's not an acronym.
http://www.atomenabled.org for those that want more.
Security should be pretty easily taken care of. You can't get into a mesh
without being invited. The user has control over what applications can do
on the mesh, and the user needs to provide credentials in order to get
things done. Sorry about the Atom caps, APP (Atom Publishing Protocol) is
what I was thinking of when I typed that... and that's usually capitalized.
I would be really surprised if there were security holes in this thing. I
can't say for sure until I get my hands on the MOE SDK, but it looks pretty
solid from what I've seen of the architecture.
Just reading what you wrote here, it sounds like this would be a
server-based solution, and it also sounds like it would be hosted by
Microsoft.
Right, to me Live Mesh is the sign of what should be called Web 3.0. Cloud
enabled applications. You can imagine a bank prioviding an Atom feed for
transactions authenticated by a specific Live ID tied to the account. That
Live ID could just provide a readonly view.
The potential is huge - but questions remain. Like defining schema,
indexing cloud and local storage engines etc...
This is a hybrid. Think of the "cloud" as one of the peers in your mesh.
You can either sync directly with peers (which I've discussed in previous
posts), or you can sync to the cloud for offline / transient storage and
synchronization. To me, it _could be_ the best of both worlds, the perfect
Web 3.0 peer network. Only time will tell if their implementation lives up
to the potential.