As part of my job I am thinking deep thoughts about what protocols Windows Live should expose and right now I'm pushing hard for JSON to be a premier protocol data format. I like JSON because it makes it extremely easy to persist hierarchical data structures which account for the bulk of the messages that Windows Live needs to move around. But JSON does have a number of issues that I think need to be addressed, specifically: namespaces, extensibility, schema/type support and relative linking. In this article I make a proposal for how to address namespaces. I will address the other issues in future articles.
Category: SOA/Web/Etc.
Articles about SOA, the Web, Utility Computing, etc.
Building A Services Platform – An Ode To Redundancy
Microsoft is a platform company which means that we like to take re-usable bits of functionality, wrap them up and make them widely available. The problem is that when a bit of functionality is not well understood trying to create a platform feature to address it will almost certainly result in something that either functions badly or not at all. The trick to good platform design is to know what to leave out and anything that deserves the title "Research" must be in the 'leave out' category.
In the services world there are numerous problems that richly deserve the title "Research". Almost anything having to do with latency optimization for read/write or real time data, most interesting security problems, almost all interesting privacy problems, just about all worthy service development language/IDE problems, etc. These are all areas that everyone is grappling with but which aren't well understood and where the industry needs to experiment.
But as this experimentation goes on the end result is what looks like a lot of redundancy. As each service deals with its own variant of the previously listed issues they tend to re-invent what looks like the same functionality. This sort of thing drives management batty because redundancy == waste in their minds. But it a'int necessarily so. Redundancy can be incredibly useful when it is stimulating learning. It is exactly this sort of redundancy, both within Microsoft and across the industry, that gives us the experience we need to move a problem from 'Research' to 'Development' and then into the platform.
Nevertheless I get more than a few odd looks from my fellow Microsofties when I explicitly say "Yes, I know your feature Y looks like something Group X is doing but Group X hasn't shipped their feature and anyway feature Y isn't well understood. So please, ship! Ship! SHIP!"
But really, my fellow Microsofties shouldn't be at all confused. A true platform maven doesn't believe in 'do it once', a true platform maven believes in 'do it right'. Until we know what 'right' is we need to experiment.
AJAX is great, except for the J and the X
AJAX has been great for the services community. By adding asynchrony it's possible to build services that can retrieve data in the background and remain interactive with the user. This is not only great for building more powerful service interfaces but it also provides us with a critical tool in defeating latency by allowing for services to be built out of other services down on the client instead of having to mash things up on the server. I suppose life would be good then if it weren't for one tiny problem – writing code in AJAX sucks. It is, I believe, time to move beyond Javascript to a byte code environment and beyond XML to a data language that can be reasonably versioned and is truly performant.
Windows Live – It's About Services (or maybe ads)
Sigh…. I know… I know… Microsoft… evil… proprietary… no cross platform… Windows über alles… etc. Whatever. Look folks, this is really easy. I work for Windows Live and my mission as handed to me by my boss, his boss and his boss's boss is simple – Make money on services.
Continue reading Windows Live – It's About Services (or maybe ads)
What My Group Does For Microsoft
My daughter just went to bed and I need to go to sleep too since I have the night feeding so I'll keep this relatively brief (for me). My group at MS (which is led by Bill Zissimopoulos (Dev Lead) and myself (Group Program Manager)) has the following responsibilities:
-
Provide guidance to Windows Live groups on how to design their external interfaces
-
Provide a software as a service platform for Windows Live properties
-
Provide a software as a service platform for external properties
-
Hire "A" Players
SOA Lifecycle (SOAL) – How to Make SOA Work In the Enterprise
The Enterprise SOA vision is all about composite applications. These are applications formed out of numerous independent web services all working together to provide some greater functionality. Except, how exactly do you define how 20 or 30 loosely coupled services interact to form a composite application? How do you deploy 20 or 30 services written in 20 or 30 languages for 20 or 30 different platforms in a sane way? And if you do manage to actually design and deploy the beast, how do you monitor it? The tools needed to make SOA work in the real world mostly don't exist yet. That's o.k. though because most Enterprises are just taking their first baby steps down the road to SOA. So we have a little time to get our act together. This article lays out a vision for how an architecture that will allow enterprises to maximize SOA's benefits.
Continue reading SOA Lifecycle (SOAL) – How to Make SOA Work In the
Enterprise
End-To-End Confusion – The Changing Meaning of End-To-End in Transport and Application Protocols
In a previous article I had argued that the end-to-end model was a bad one for SOA. In comments on that article Nick Gall made the point that I was using the term end-to-end incorrectly. I countered that the meaning of the term was different for application protocols than for transport protocols (where Nick's usage came from). Below I explain how HTTP's violation of the 'end-to-end principle' sent application protocols on a path where the very idea of 'end-to-end' changed with unfortunate consequences for SOA.
SOA Security – Encryption
In this article I first look at the use cases for encryption in SOA and explore three scenarios: hop-by-hop, end-to-end and beyond messaging. I conclude that most folks just need hop-by-hop messaging, specifically SSL. I then look at issues relating to encrypting messages outside of the enterprise and conclude that most services probably don't need encryption but they'll use it anyway so to reduce harm they should at least use SSL enabled proxies in order to make the unencrypted messages available within the corporate network. I then look at using encryption within the enterprise and strongly caution most companies to avoid it if at all possible. The bottom line is that SSL is enough for almost everything, GPG cleans up the rest and XML Encryption and the WS-Security framework are almost certainly more trouble than they are worth.
SOA Security – The Myth of Non-Repudiation
In this article I explain why (in my non-qualified opinion as a non-lawyer) I think most people are wasting their time when they worry about non-repudiation of SOA messages.
Web Services, SOA and RPC Encoded – the Exception that Proves the Rule
In my search for how real people are implementing SOA I just about never see SOAP, and WSDL seems unheard of. But when I point this out I inevitably get yelled at and told SOAP and WSDL are used all the time. Which is true, but misses the point. Because what SOAP and WSDL are generally being used for is not SOA but rather RPC, specifically RPC-Encoded. Of course RPC is the text book definition of "Not SOA". So I tip my hat to Web Service's major success – as Not SOA.
Continue reading Web Services, SOA and RPC Encoded – the Exception that Proves
the Rule