In "Google Map 'Documents'", Stefan Tilkov notes:
In a comment, Patrick Mueller asks whether I'd consider Google Maps "document-oriented".
w/r/t "document oriented", the term is used on the Lively page, but I think Stefan ismisinterpreting it. I can onlyinfer from Stefan's post that he believes a web application is "document oriented" if you can generatea URL to somewhere in the middle of it. Like he did with two map links he included.
I'd refer to this capability as having addressable pages. Addressable in terms of URLsthat I can paste into a browser window, email to my mom, or post in a blog entry. Important quality.It's especially nice if you can just scrape the URL from the address bar of your browser,but not critical, as Google Maps proves; a button to generate a link is an acceptable, but lessfriendly substitute. Being addressable is especially hard for "web 2.0" apps, which is why I mentionit at all.
My read of the Lively page's usage of "document-oriented" is more a thought on application flow.In particular, pseudo-conversationalprocessing. Which is both the way CICS "green screen" applications are written, as well as the wayWeb 1.0 applications are written. Turns out to be an incredible performant and scalable style of buildingapplications that can run on fairly dumb clients. The reason I infer this as "document-oriented" is that,in the web case, you literally are going from document (one URL) to another document (another URL)as you progress through the application towards your final goal. Compared to the style of imperative and event driven programming you apparently do with Lively.
So, with that thought in mind, Google Maps is clearly not "document oriented". The means bywhich you navigate through the map is 'live'; you aren't traversing pages like you did in old school MapQuest (which, btw, is also now "live").
But even still, given my interpretation of Stefan's definition, I'd say there's no reasonwhy a Lively app can be just as "document-oriented" as Google Maps given his definition; that is, exposinglinks to application state inside itself as URLs. You may need to work at it, like you would with any Web 2.0 app, but I don't see technical reason why it can't be done. Hint: client code running in your browser can inspect your URLs.
Back to Stefan's original note about Lively: "it might be a good idea to work with the Web as opposed to fight against it".I think I missed Stefan's complaints about Google Maps fighting against the web. Becauseif Lively is fighting against the web, then so is Google Maps.
In "What is SOA?",Pete Lacey notes:
Another problem with the SOA name is the "service" bit. At least for me, the term "service" connotes a collection of non-uniform operations. I don't even like the phrase "REST Web services." Certainly, SOAP/WS-*, CORBA, DCOM, etc. fit this definition. But REST? Not so much. In REST the key abstraction is the resource, not the service interface. Therefore SOA (and I know this is not anyone's strict definition) encompasses the above mind set, but includes SOAP and similar technologies and excludes REST.
If you change Pete's definition of "service" to be "a collection of operations", independentof whether they are uniform or not, then REST fits the definition of service. Next, you can simply say the resource (URL) is the service interface, for REST. Just a bunch of constraints / simplifications / specializationsof the more generic 'service' story.
Sure there are plenty of other details that separate REST from those other ... things.But you can say that about all of them; they're ALL different from each other, in thedetails. And at 10K feet, they're all doing generally the same thing.
As a colleague mentioned to me the other day, REST is just another form of RPC.
I feel like we might be throwing out the baby with the bath water here. It's truethat I never want to go back to the CORBA or SOAP/WS-* worlds (I have the scars to proveI was there), but that doesn't mean there's nothing to learn from them. For instance, the client-facing story for REST seems a bit ugly to me. I know this isn't real REST,but if thisis the kind of 'programming interface' that we have to look forward to, in terms of documentation and artifacts tohelp me as a programmer ... we got some problems.
I look forward toseeing what Steve Vinoskibrings to the table, as a fellow scar-bearer.