 I'm going to talk today about WAVE, which is what I always talk about at Groovy Commons. WAVE started out life as an attempt to sort of get outside the MBC box and experiment with, instead of an application framework, an architectural framework. And so it sort of evolved. Some of you who were in some of the initial LA Groovy Group meetings remember I gave kind of a brief overview last summer. We had just come out of this sort of deep, dark cabin on a three-fact ring and it was sort of the first tentative thing to say, okay, here's kind of what we've come up with after a round of doing a release, getting feedback, doing some re-factoring. The exciting part for me is that we've actually made a fair amount of progress. It seems like the foundation for WAVE has gotten pretty solid. I gave a talk at the Orlando National Ruby Comp on WAVE and we haven't had any major restarts or re-think since then. So I'm not going to go over that same content in this talk. I'm going to focus a little bit more on some questions that I've been answering about WAVE quite often. That talk takes, again, to go as on the concrete's website. So rather than rehashed out, if you want to see that talk, you can go to concrete's and see if this talk intrigues you. In this talk I'm going to focus a little bit more on a question that I get a lot. There's sort of a Socratic dialogue that seems to be accompanying WAVE as it evolves and it started off with, well, why wouldn't I just use Rails? And the answer to that was, well, this is trying to go, this is if your apps define yourself kind of painting outside the NBC lines, then maybe WAVE is something I would look at because it's trying to help you and then you have to go do something a little bit unconventional. So then people would say, well, isn't that kind of like RAP does? It's an architectural framework for dealing with web applications. And there's a lot of synergy between RAP and WAVE, and the thing that RAP does or the WAVE does is it adds a lot of support for things over and above just the basics of handling an HTTP request that you typically find in frameworks. In fact, there's an NBC layer that's in WAVE that sort of demonstrates some of the richness of WAVE. So then the next question is, okay, I get that as kind of a layer on top of RAP really for defining application frameworks. And then we kind of got into this whole resource-oriented kick of saying, well, you know, the next thing beyond NBC that makes sense is to sort of help developers write more aggressive and fine applications. And that, you know, there's some support for doing that in NBC frameworks, but NBC frameworks by their nature sort of try to encapsulate a lot of what HTTP is really doing and make the covers. And so it's a little difficult sometimes to access all of it. I mean, it's doable, but it's not natural. So then the question came up, and I really felt good about that answer. But then the question started coming, well, why do I really need RAP? If the things that I'm doing go beyond what I find in the NBC frameworks and those frameworks are working really well for me, and what do I need to have, just because there's these sort of these constraints and rest, aren't they a little arbitrary? Are they really going to buy anything? So I'm going to try to address that question in this talk. We kind of talked a little bit about how Waves, hopefully, if time allows, I can get into sort of some of the specifics about how Waves addresses that. But I'd like to talk kind of a larger picture of what that buys. Before I go into that, let me just say, I'm the Director of Development at R&B at 1810 Interactive. I've been doing software development for the last 20 years, working with Ruby, like a lot of people, I came to it in 2005 with the emergence of Rails. Waves is about a year old. I've done a number of gems, mostly spin-outs from Waves. Our group at 1810 Interactive has released some apps, including the kind of amusing one that's a restroom locator called Half the Pee for your iPhone. There's some other nice little search utilities that go along with that. Half the Pee, half the drink. And we've released also one of the first Waves search applications, and all of these on the back end are actually powered by Rails. So that gives you a little idea of hopefully where I'm coming from. I think to understand resource-oriented architecture and why we're trying to focus on it so much with Waves, it's really useful to start off with an easy-to-overlook fact about the web, which is that it really is arguably the most successful in screening and computing architecture ever. And to put that into more concrete terms, we know it scales. There's millions and millions of clients, millions and millions of servers. There are different types, right? We have different types of web browsers, different types of web servers. You have different categories of clients, RSS readers versus web browsers. We have the sort of emerging domain of things like Adobe Air application, which are often actually HTTP-based, going to talk into a back end. It's based on open standards, which is something that, of course, for Ruby developers, it's near and dear to our heart. It's an open platform. It's not dependent or controlled by a single vendor. So it's a distributed computing platform. Unlike a lot of previous ones, it's not essentially, you say, like Thorba. There's some politics associated with the standards. They're so broad and there's so many different stakeholders. It seems to have gone beyond the old politicking and sort of profiteering strategies that used to handicap distributed computing platforms. The other thing that's really interesting about the web is the infrastructure that it provides. We have a lot of proxies and load balancers and all this stuff. It's already all out there and it allows us to factor a lot of logic that would normally have to be, we have to deal with in our own applications out into the networks, so the network starts to become more and more intelligent. What's really cool about this is that we can then leverage all of this infrastructure if we're building new types of clients or new types of servers. So the next time I've had conversations in the past quite often where there's a need for some reason for some kind of application-specific protocol and the tendency to say, oh, we'll just bang it out with ECP IP or UDP or something simple and that's not making it too complicated. But what you're doing is going to have any life beyond the sort of immediate application of it. There's all this infrastructure that you can sort of piggyback on to get things like load balancing for Stanley and so on. But the thing is, this is all kind of secondary things. It's all the things that we know about the web. Well, we don't really know or at least I'm going to assert that it's an area of some confusion. Some of you may feel like you know this, so I shouldn't say. I've touched on it a little bit, so I should say. Why is this really all work so well? And I think that the heart of this thing is the constraints of rest architecture. I don't think it's a coincidence that that's Fielding's dissertation and his name is at the top of the list of authors of HTTP specification, right? So if we can understand what breast is really trying to do and what these constraints are really talking about and then begin to apply them to what we're doing in web applications, hopefully we'll have the same emerging characteristics as the web has, right? Now you think that because the web is so successful and all the things I just talked about that this might have already happened. So anytime you sort of have this idea about, well, hey, let's do this. You know, it's often why you should kind of ask yourself, well, there's lots of smart people out there, why hasn't it already been done? And I think what we've been doing and the reason that NBC is so successful today is what we've been doing is we can essentially piggyback you off the web browser, right? We're stuffing our applications into an existing web application called the browser. Now the browser takes care of a lot of stuff for us. It takes care of content negotiation, for example. It takes care of caching. A lot of the things that Rast is talking about, the browsers are implementing sometimes not so well and in fact that's one of the reasons that you find people wanting to bust out of the browser or we talk about rich internet applications and there's sort of this ongoing debate as to whether or not they belong in the browser at all or if you need something like Adobe Air that allows you to just bypass the constraints and decisions that the browser makers are making for us. A couple of examples here real quick. A case is where we see the benefits of busting out of the browser, right? RSS feeds, there's some, you know, resources. The whole RDF idea there is embedded in the notion of a feed, right? It describes instead of me having to go figure out how to scrape every individual blog, I just have a little thing that describes how I'm supposed to get to that blog providing some metadata for me. It's content neutral, so we end up with this sort of unanticipated benefit down the road of podcasting, right? That comes out of the fact that the client, the RSS and the idea of RSS clients will build around at least some of the principles and constraints of Rast architecture. Another example, this is a little bit more, I haven't actually seen any of this something like this implemented, but this is an example of something that you could do. How many people are familiar or who began playing around with OAuth? So, OAuth is a sort of, what are you guys talking about? That's what you think we're working on right now. Oh, that's funny. I shouldn't have realized that because I actually told you. Anyway, it's essentially a kind of a workflow or process for, you know, two sites cooperating to share information. So, one site basically can ask permission from another site to access certain information and the user can kind of grant that permission. Now, if you were to use the strategy that we see all over the place in web architecture for dealing with documents, what we could do is we could actually implement this as a smart proxy that knows how to deal with OAuth. And now, if I just simply implementing a login page and a permission granting page on our web app, you know, we'd get OAuth across the board for all of our apps without having to do it one at a time. Another example is the use of edge caching. If you have a really compute intensive server activity, it doesn't really buy you a whole lot to put the, to try to, you know, obviously you need to use caching in a situation like that. But even more importantly, you want to actually push the cache all the way off the edge as close to the client as you can. And that's another property of web architecture. So, taking a step back, the question that, you know, that we were trying to answer is, why does this really work? And, you know, why do these different architectures, I mean, so there's some examples of cool things you can do by following those principles. And we're still not getting at what is really going on here. And what I'm going to submit to you is that what breast constraints describe are sort of the necessary constraints for a distributed object system. Okay, and I'm not sure, you know, if we're in building this here, you might start going around tomatoes at this point. This is my own speculation on this, but this is helping me kind of understand. So, it's sort of a coarse-grained sense. If you say resource equals object, you're sort of halfway there of understanding why this really works underneath the cover. So, this of course is, it's not a new problem, right? We've seen this many times before through RPC and RMI and the core of law, you know, and all of these attempts never really took off, and yet the web is phenomenally successful, relatively speaking. And the reason is that I believe that the people that were involved in developing the HTTP specification were obviously very well aware of the past history of a lot of these attempts to create distributed computing platforms and they learned from the past mistakes. The first thing that they learned is, you know what? Don't pin down the platforms. Don't try to come up with a format for marshalling objects and fix it because there's too many cases where either technology evolves in new formats that are more appropriate for some applications become available, or, you know, we have the case where, you know, the formats, you know, are just, they're not new necessarily, but they're maybe a little surprising for some applications. So, for example, if you're trying to access a movie object, if you want to play it, if the client is trying to play the movie, it just wants the movie itself, right? A quick-time file or whatever. If it's trying to display, you know, information about the movie, maybe it wants a JSON file that describes the movie. And so I don't want to prescribe or dictate how that, you know, what format, so that's the separation in RAS between a resource and a representation, right? I don't want to dictate the format. I want the client to tell me what it's looking for. I want to be wire neutral. This is something that's really interesting to me about RAS, is the fact that it actually says, look, I'm not even sure what the protocol is going to be. And you see this with the evolution, you know, we use HTTP a lot, but we see that, you know, okay, now we need security, so we might pay HTTPS. And the future, who knows where it'll go. Maybe if I want a mail to a resource or if I want to FTP something, I can use those protocols. I just say, you know, what protocol this resource is going to understand or is most appropriate for what I'm trying to do, and I use that in the URL. Another thing we've learned is you have to have very consistent met-object protocol so that you can do all the things that you see in HTTP that would get close to the leader. You need a simple set of verbs that works everywhere. And if you don't, and that's the whole thing about uniform stateless interfaces. If you don't have that, then you start coupling the client and server together on a case-by-case basis. The more generic it is, you know, sometimes it's less efficient, but in the end, you end up benefiting because it's far more scalable and flexible. And that's where you get these disemergent property of web architectures. Performance, obviously. If you're going to start moving objects over the wire, one of the big objections that held up a lot of transition over to messaging-based architectures was the fact that, hey, I don't really want to move the whole, what if I don't need the whole object? We're not just bandwidth constrained today as we've worked then, so it's a little bit more feasible, but we're still worried about performance. So you still need to have, you know, edge caching. You still need to be able to move code over to the client. So, again, that's one of the principles of REST is, you know, being able to move client over. Layered architectures is another issue. This is the whole thing, having things like smart proxies. So in, even in a service-oriented architectural world, you see this. You know, the idea is you make an intelligent network, or a network boundary or something that has a lot of the intelligence for things like security policies, you know, delivery policies, and so on. And you can bake those right into the fabric of the network instead of burdening each of the applications or APIs. So that's kind of the big picture. Now, what, again, the premise here for Waves is that more and more we're going to want to bust out of the web browser, or even when we're in the web browser, we're going to want to try to take control more and more of the communication between the client and the server. And the goal of Waves is to try to help you do that. So I'm going to try to talk, I don't know, there's going to be a time I don't want to shoot. You got 10 minutes? Okay, that should be about right. So I'm going to try to go over a few of the Waves, just a few highlights of Waves and how it kind of connects to this whole idea of resource-oriented architecture. So the first thing is that, and this is where we did a lot of refactoring over the summer and came out with this, the first thing is this idea of having a DSL that allows you to naturally talk about the entire HTTP request and isn't URL-centric, domain-specific language. So, you know, like, probably one of the most famous DSLs is Active Records DSL for things like, you know, Hasmany and so on. So Waves has a DSL for dealing with the HTTP request. You see an example here, what this example does is allow me to have to trigger a piece of code based on what query parameters were included, whether they satisfy a particular format and, you know, what the accept format is that the client is asking for. So, you know, I know that these are the formats I know how to handle, so I don't really want to commit to anything else. So this is kind of a, you know, there's nothing terribly sophisticated here. It's just that it goes a little bit beyond what you see in a lot of frameworks that are very focused around the URI or URO. And you can match on pretty much anything in a request. We've had some fun kind of experimenting and enriching this and some of the apps that we've been building in the 1810 Record. But underneath the covers, one of the key points, and this, we've got one more detail in our land-over presentation, but it's on concrete. But the underneath the covers, we're still just talking about resources, methods on a resource, or methods on a resource instance. And those are just the things that you expect to get the post and the lead. So here's our, this is just a little fragment code demonstrating the fact that they're really just normal Ruby methods. The DSL is just helping you find those methods and handling all of the matching code and stuff that you would normally have to write. There, anyways, the resources are just, they're just classes, so all the normal things that you can do with Ruby apply. Now this was inspired actually by Blake's Sinatra framework. I wanted to see if I could actually accomplish something that was remotely similar to what Sinatra was doing in terms of being able to have a simple, small application and sort of start with a really simple, compact stub and be able to build up from there. So this is kind of an example of, you know, the simplest possible hello world that could work. And it's not quite as concise a Sinatra but it's about as close as we could come with the approach that we had. Now in terms of where we're going, so that was kind of, all that stuff is there and working. We recently implemented an HTTP caching. Roberto actually implemented that, makes the rack cache. And, you know, that's kind of interesting because that's that whole thing of being able to now push the cache out to the edge of the network rather than having it on the same server or even on the same cluster of servers locally. I just tell HTTP, I tell the network, hey, this is my caching policy for this data. But what we want to go is we want to actually start to get more of a true rest of DSL, not just a DSL for matching requests, but a DSL for describing resources. So this is an example of how that might look now this is still under development and if you jump on to the Google group for Rubyways, which is called Rubyways, you know, you can actually jump in on this discussion if you have ideas about how this might look or work. And that would be very welcome because we're still kind of trying to figure it out. But the idea here, if you sort of follow along of the logic here is that I can describe a number of resources as a part of a resource group. So I said, okay, here's my component, it's a server component and these are the resources that it knows about and these are the schemas. And you'll notice we're defining that independent of the representation which is again sort of a key precept of a rest-based architecture is the separation between the resource and the representation. So at the bottom there, I have the representations that I know how to deal with and define those, and it's very dry that way, right? I can define as many representations and as many resources as I need to, but I don't end up with sort of redundant cases or redundant codes sort of declaring every possible combination. And in there you also see the scheme element and the idea here is that we could automatically generate RDF to describe a service endpoint RDF which allows for machine introspection service and actually dynamic possibly dynamic composition which is a little bit out there but that's kind of the principle between the success of RSS and I have a description of the blog object or the podcast object. And that's kind of how I think about it is we're in this world where there was a document object and then these sort of stuffed applications through these document objects but now we're kind of getting more and more into different types of objects blogs, podcasts and it's starting to become important potentially to even have application-specific type of objects so I have a car line type that describes cars so now I can sort of have a client say I need this version of the line type for cars so we have the obligatory surfing bikini girl of all ways presentations always wrap up with that picture of a bikini girl surfing just sort of it's a different girl each time you know that's interesting that you asked that question I spent an embarrassing long amount of time trying to find a picture to follow up with this one it's the same one as before it's actually surprisingly hard to find like I'm almost thinking I'm going to make this part of the waves jobs to go out and take these photos because oh it's a rough job somebody's got to think of it so some of the vital stats the website the Goofy Groups who love to see people on there feedback it's this is not a solved problem we're not trying to say we understand it fully so if you have ideas or insights into how to map resource-oriented architecture that's computing into a Ruby framework we'd love to hear from you some acknowledgments some of the folks just real quick I wanted to mention Roberto is Pauli Mar who's mostly works on her videos but has done some work also with waves Peter Amar, KK, Matthew King a lot of other folks have done a lot of great work over the past six months on waves and hopefully that will get longer with some of you also jumping in and contributing so thank you