Stevey’s Google Platforms Rant
I just read the post that everyone’s talking about: Steve Yegge’s Google Platform Rant, and it is fantastic. If you haven’t already read it, go read it now and come back. I’ll wait…
Wasn’t that great? He just did a better job of demonstrating the real world benefits of SOA than anything I’ve ever seen. This “eat your own dog food” mantra that demands “no cheating” is exactly the reason why your business processes should use the the same service interfaces that everything else does. The process and the services must not be tightly coupled.
But more than that, the process itself contains critical logic that should be reusable, so the process itself must provide its capabilities as a service. This is what service-oriented BPM is all about.
The one thing that he missed is the importance of a good, strongly-typed interface definition — one that can truly be treated as a contract. You can’t understand an interface well enough to create solid code that uses it by just prodding it through an exposed REST API (hmm… I wonder what this does). Take a look at the way that Google exposes its APIs. You get a one-line description of a few simple string input parameters. Then you put in some test data, click the “execute” button and see what comes out. That is how you are supposed to determine what the service does and what the result looks like. Test and check.
Are you really going to figure out all the right tests to run to understand the semantics of the service, or even just the syntax of the result document? Also, what happens when they change it? There is no document that says: “this has now changed and here is how”. Yes, some generic announcement might tell you that the service has changed, but to know the precise impact of the change on each of the operations of the API, you would have to go back and redo all your test-and-check experiments. It is completely unmaintainable.
So, I guess I have a problem with the leniency of one line of the otherwise impressively strict edict from Bezos:
“4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care”
I expect this was a bit of an exaggeration. And even if Bezos didn’t really care about the technology used, I hope his ex-Army Ranger enforcer did. It matters. Some approaches are untyped, not conducive to rigorous documentation and/or non-standards-based. Any of those things will get the people who depend on your platform into trouble and so they won’t depend on it. They will go somewhere else.
So, what is the standards-based approach to declaring a good strongly-type API that your users can depend on? If you’ve ever read anything else I’ve written, you know the answer: WSDL and XML Schema. Include that in your edict and you will really see your platform blossom. And what is a service-oriented BPM that you can use to create processes that fit with this architectural approach? You guessed that too.
Post from: VOSibilities, the Active Endpoints BPMS blog
Learn more about ActiveVOS
Stevey’s Google Platforms Rant
Leave a Comment
You must be logged in to post a comment.
