Constrained around simple web protocols, data formats and SQL
Focused on Rich User Interfaces with Javascript
App server is natural extension of the Web Server
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.
“towards desktops with multiple CPU "cores”, and with direct access to terrabytes of data..., 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...
Sam Ruby: Long Bets “towards desktops with multiple CPU “cores”, and with direct access to terrabytes of data…, 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...
Jeremy Zawodny : Long Bets - Long Bets: Sam is one of the smartest people I’ve ever met in computing. I suspect he’s right about most of these... Tags : links...
“This makes SQL and components like ActiveRecord the weak link.”. Yup. But your list of long bets doesn’t offer a stronger one. Personally (as you’d guess) I’d add RDF. For direct weak link replacement, how about (distributed) [link] SPARQL and components like Active RDF? [link]
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.
Via Sam Ruby , a post from Jerry Cuomo who asks (rhetorically) : It is worth standardizing an agile platform for our generation’s dynamic web applications? Doesn’t sound unreasonable. He has in mind a particular stack of tools: Ajax, REST, Atom,...
Selected links related to Semantic Web technologies for the week ending 2007-08-12 In the Media Aug. 7, 1991: Ladies and Gentlemen, the World Wide Web - the Web’s 16th year celebrated at Wired.com Using Wikipedia as a Web Database -......
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:
Data trumps processing For the last few years, I’ve been hearing that multicore will change everything. Everything. The programming world will be turned on its head because we can’t piggy back on faster chipsets. The hardware guys have called time......
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.
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. :-)
Sam Ruby’s “long bets” don’t seem so far off considering how quickly changes are happening on the internets.... 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...
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 ;-)
An interesting posting from Sam here. He asserts, for next gen web architectures, the following are the long terms bets (with my commentary, in italics): REST (yes) Hadoop (yes. Map/Reduce (which to my biased database eyes is just group by......
My Long Bets post attracted some interesting reactions. A number of supporters of various items in my list, as well as a few pushbacks. There’s not much to say about the former, except thanks for the validation....
[more]
I’m back from vacations. I was in Gaspésie, a wonderful region of the Québec province in Canada, with my family. We had a really great time. But it’s over. Now back to work! I noticed that Erlang is getting more and more attention . Even Sam Ruby is...
Sam and Tim are peering into the future to place their bets on what technologies will be hot. It’s like Fantasy Baseball for the Insanely Geeky. So… what the hell, here are mine: I rarely get excited about any specific technologies; when I do, it’s...
I have to say, I’m with James in his response to Sam’s long bets; To say, as Sam and Tim both do, that REST is important is like saying the fan in my laptop is “important”. There’s really nothing to discuss about it. RESTful services are...
Two of my favorite bloggers select technologies to keep an eye on for the future. Sam Ruby REST Hadoop Erlang/OTP Jabber Microformats Tim Bray Green infrastructure The Atom Protocol, and REST Ruby and Python AJAX Jabber Ubiquitous functional...
Sam Ruby has a post up about his long bets and Tim Bray replied with comments and his own set of prognostications. Tim’s comments around concurrency trends (particularly with respect to Erlang and Hadoop) were interesting as I think there is...
found some interesting posts today on the notion of “standardizing an agile platform.” jerry cuomo and sam ruby have some pithy comments about the following set of tools: Scripting based programming methodology Constrained around simple web...
Earlier I asked: “I’m wondering how would one produce a URL space for a blog style archive, using Servlets+JSP, and do so in a way that isn’t a CGI/RPC explicit call?” I got some answers, all good: Sam Ruby: "Perhaps......
We complain when we see valentine’s chocolates in January, halloween costumes in September and Christmas stuff mid-November, yet here we are already making bets on the next year or future early August. I usually skip the five songs, five things...
I was checking up on Anant Jhingran’s blog and noted that he mentioned Erlang so going back up to the top realized that he was discussing a post from Sam Ruby . Sam is discussing a set of “long bets” although some seem pretty short bets to me. It...
1. Download [Erlang][erlang] 2. Setup [TextMate][textmate] with a [bundle for Erlang][erlang-bundle] 3. Read the [white paper][whitepaper] and the [book][programming-erlang] 4. Understand what [the]([link])...
Sam Ruby and Tim Bray have each picked messaging systems as a trend to watch in the future. In particular, they are naming Jabber/XMPP as something to watch. While I think XMPP is a great way to connect people to systems or other people, I think...
Sam Ruby includes Jabber in his recent long bets for the five technologies that will be especially influential over the next five to ten years. Tim Bray concurs . Sam further explains : Jabber I didn’t get much pushback here, but I’m finding that...
Mike Herrick: "Clearly Atom can’t replace ALL pub/sub use cases, but for every day integration architecture where you want business events / EDA why can’t we use Atom feeds? In an extreme case, you might have an event sink......
Chesspark.com is built on a Jabber platform, fyi. Sam Ruby includes Jabber in his recent long bets for the five technologies that will be especially influential over the next five to ten years. Tim Bray concurs. From https://stpeter.im/?p=2030...
The professional architect, Part 2: Overcoming professional challenges in data architectureAgileEvents - A group calendar for posting/finding Agile-related events.GPASS: A generalized publish and subscribe solution using WS-Notification...
Recent Code and the Culture of Code Links for Sept 5th
Accordion Magic Will has taken stickman’s accordion and added the ability to close panels, and code to keep contents hidden while page loads. Outstanding!!! Common Prototype mistakes and how to avoid them : Here’s another list of things that...
Mashups als EAI 2.0, Atom, REST, Hadoop, Jabber und Erlang/OTP — dieses Mal wagen wir mit der Blogosphäre einen Blick in die Kristallkugel. Sam Ruby zeigt, wie man auch ohne XML und SOAP elegant “Web Services” bauen kann. Der...
Sam Ruby occasionally does an article about his long bets and I really respect his ability to predict the future. This time I feel that he was focusing too close and forgot the long part of the ‘long bet’. REST is already important, and...
Sam Ruby - Long Bets : “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. REST Hadoop Erlang/OTP Jabber Microformats ”...
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?
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.
Sam Ruby - Long Bets : “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. REST Hadoop Erlang/OTP Jabber Microformats ”...
I Recently a took stock of items in the world of technology and computing that were occupying my attention. Looking at things like my feed subscription list, I attempted to boil the list to a managable few — to further capture the ideas/items, I...
I was checking up on Anant Jhingran’s blog and noted that he mentioned Erlang so going back up to the top realized that he was discussing a post from Sam Ruby . Sam is discussing a set of “long bets” although some seem pretty short bets to me. It...
Scaling out messaging applications with Scala Actors and AMQP
We have been sandboxing various alternatives towards scaling out Java/JMS based services that we implemented for our clients quite some time back. The services that form the stack comprise of dispatchers and routers meant to handle heavy load and...
One of the presentations I was most disappointed to miss at OSCON was Evan Henshaw-Plath and Kellan Elliott-McCrea’s talk entitled “Beyond REST? Building Data Services with XMPP PubSub.” Not because I’ve somehow given up on the REST architectural...
if you enjoyed Kellan Elliott-McCrea and Evan Henshaw-Plath’s presentation “ Beyond REST? Building data services with XMPP ”, here’s a dose of links: Extensible Messaging and Presence Protocol - Wikipedia ActiveMQ+XMPP : ( "We have support for XMPP...
Three Things That People Get Wrong About Cisco’s Jabber Acquisition
Another week, another RedMonk client acquired. This time around it was Jabber, acquired by Cisco. In doing so, they follow in the footsteps of other RedMonk Graduates like Covalent (SpringSource), IONA (Progress), MySQL (Sun), OpenedHand (Intel),...
The professional architect, Part 2: Overcoming professional challenges in data architectureAgileEvents - A group calendar for posting/finding Agile-related events.GPASS: A generalized publish and subscribe solution using WS-Notification...
Automatic concurrency management is the new thing, like automatic garbage collection was in the 90s
This is a great interview between Bill Venners and Rich Hickey. Hickey is the guy behind Clojure, the new JVM language that brings Lisp to the world of Java. I have so far only heard good things about Clojure. Hickey makes the argument that what is...