Jerry Cuomo: I see several common threads:
Twenty eight months ago, this bordered on heresy. And if that didn’t, this certainly did.
Jerry Cuomo: I see several common threads:
Twenty eight months ago, this bordered on heresy. And if that didn’t, this certainly did.
Now, it pretty much represents the baseline. At least for 3 of the 5 (or possibly 4 of the 6 if you count the “subtle” background image).
I’m still hopeful that at some point, people stop being passive consumers of content, and take control over their user experience with tools like GreaseMonkey, but the adoption curve for that and similar technologies seems rather slow, and I don’t see that changing in the near term.
As for continuations, a specialized form, namely closures, is central to Ruby and JavaScript, (and in a somewhat less explicit form: Python), is a part of Groovy, C#, and early exploration is underway for adding closures for Java.
I don’t particularly care whether or not I can count partial credit for that one; and in any case, I certainly didn’t expect to be where we are a mere 28 months later. But perhaps now would be a good time to look out the next 5 to 10 years.
Five years ago, the state of the art was app silos. Installing a new application on such a silo was accomplished via drag and drop of a WAR or EAR file. Now the focus is on Saas. The apps don’t move, the data does.
The next domino to drop is data silos. Which if you think about it is a bit ironic. Just as we move towards desktops with multiple CPU “cores”, and with direct access to terabytes of data storage, we are starting to find the notion that all the data you want is all is one place, all you have to do is form the right query to be increasingly a quaint one.
This makes SQL and components like ActiveRecord the weak link.
So, without further ado, here’s my long bets for the moment, with the only caveat that in some cases I pick specific implementations as exemplars of a larger field.
Yes, I realize that I’ve duplicated one there. I don’t believe that we have tapped that particular one sufficiently yet.
So you’re the one that’s been pushing Erlang so much lately, I guess I’ve waited long enough then.
Can you add more hours in a day to that list while you’re at it?
But your list of long bets doesn’t offer a stronger one.
Actually, it offers two. Map/Reduce and Mnesia. Follow the Hadoop and Erlang/OTP links for more detail.
Personally (as you’d guess) I’d add RDF. For direct weak link replacement, how about (distributed) SPARQL and components like Active RDF?
Independent of RDF itself, I believe that late binding the distribution won’t work. Imagine if a Google query were implemented in such a way that every request resulted in billions of pages being fetchted, even if those pages were fetched in parallel.
No, I believe that the query of the future has to be a bit anticipatory. Google is constantly crawling pages, and produces some form of index, and that index is replicated and distributed using techniques that Hadoop attempts to replicate.
Whether or not RDF is appropriate for that internal index may be worth exploring, and I would guess that that would depend on how ad-hoc the queries are, and how structured the data is. In many cases, given that this is a cache built up in anticipation of certain types of queries, it may make sense to heavily denormalize the data optimizing for the types of queries that are expected.
RE: Hadoop as a long bet
Is your bet that the programmatic approaches that underly MapReduce and BigTable will become more widespread or that the the proliferation of the specific implementation in Hadoop which is based on papers about Google’s MapReduce, BigTable, GFS, Sawzall, Chubby, etc will become as widespread as memcached (for example)?
I can see the former, I probably wouldn’t bet on the latter. Some of design choices made in Google’s architecture make sense for their problem space (e.g. “Moving Computation is Cheaper than Moving Data") but totally crap all over everything we’ve ever learned about decoupling services and isolation. A question to ask yourself is whether "EC2 instances running on the same machines as the S3 server their data is stored on” sounds like a good idea or not. It is , if you believe the Google way is always the right way. Me, I dunno yet. :)
“ but totally crap all over everything we’ve ever learned about decoupling services and isolation.”
It just totally craps over a particular class of application.
“A question to ask yourself is whether "EC2 instances running on the same machines as the S3 server their data is stored on” sounds like a good idea or not. It is , if you believe the Google way is always the right way.”
there’s more than one right way; it depends on the problem space. If you follow that link, the book that quote is taken is the first place I saw a program in the style that is now called mapred. Review here:
I’d encourage anyone that’s interested in this corner of the computing world and wants to step back a bit from web specific noise to pick up a copy.
Would Scala fall into the ErLang/OTP category?
Perhaps. Not knowing enough about the Scala, my fear is that it is just a language, i.e. without all the accoutrements. Mnesia looks really cool, Erlang may simply be an enabler.
Some of design choices made in Google’s architecture make sense for their problem space (e.g. “Moving Computation is Cheaper than Moving Data") but totally crap all over everything we’ve ever learned about decoupling services and isolation.
What Bill said. I remember when REST seemed like total crap (at least to me). And I wouldn’t call Google’s internal architecture RESTful. Nor would I call Mnesia RESTful.
Oh, and Bill’s latest post is well worth a read.
P.S. I corrected Dare’s errant signature line. And since this weblog is totally Unicode enabled, Bill, you might consider spelling your name correctly here. :-)
Gack, I typed a long response and seem to have closed the tab before doing the OpenId thing. Bit more concise this time...
“I believe that the query of the future has to be a bit anticipatory” - I agree. Triplestores (including RDF/XML documents) are caches of chunks of the Semantic Web.
As far as I’m aware, there is no obvious mapping between Map/Reduce or Mnesia and the resource-oriented structure of the Web. Of the Web or on the Web?
When using Google I often find that the immediate results aren’t what I’m after, I have to follow links manually (or run a fresh query). With a system where dereferenceable resources are exposed (i.e. as URIs in RDF), this “follow your nose” activity stands a better chance of being automatable.
One approach in this space (which I’ve in the process of doing a proper write-up on) is to use message-oriented agents which can, if both ends of the wire have the capability, use dedicated low-level comms for perrformance. But if the agents have a resource-oriented (REST+RDF) baseline comms facility, they will still have an interface compatible with the rest of the Web. Something like: slow things should be easy; fast things should be possible.
(btw, I ordered a copy of the Erlang book just the other day ;-)
Currently I am adding APP support to JSR 279.
APP is as restful as it can be and has everything needed
and nothing more, a perfect fit to be promoted
also in a mobile world.
I also see a value in having a formal description of a service(such as a WSDL). APP defines a specific service document that provides means for service discovery, that is categories.
Anyhow, I’d like to see something more to aid automatic service discovery, so that e.g. geographic location and the special keywords to find the service. It might be that agreed vocabularies, e.g. dc:author and using agreed extensions, e.g. georss, are enough. But these are details I see only while using the service (AFAIK) and not in service discovery phase.
In the book “RESTful Web Services” there were two approaches illustrated:
1.) platonic URI + metadata in HTTP headers
2.) URI with structure and predictability
The latter was recommended practice to ease the nesting the services and not to be dependant on various ways HTTP headers are treated. Having all the meaning in the URI does not expose semantics to get lost in transition.
Adding semantics to URI is not easy. You are not that free to express yourself within the max length of URI and prevented from using reserved chars. The beginning of the string - domain name and path are system specific, and there are static parts you are not able to influence. Having a long query string with different key-value pairs does not sound so restful.
So, my question is, are there any more means to do yet smarter service discovery of APP services?
- Pia Niemela
are there any more means to do yet smarter service discovery of APP services?
Per section 6.2, “Foreign markup can be used anywhere within a Category or Service Document unless it is explicitly forbidden”. JSR 279 could therefore either define, or point to, a standard Atom Publishing Protocol extension for discovering the information required to interact with identity based services, discovery, and authentication.
If this is something you wish to pursue, I’d recommend joining the atom-protocol mailing list.