Errai and Message-Oriented Programming - A Q&A with Mike Brock

DZone recently caught up with Project Lead Mike Brock to learn about the JBoss Errai project, a GWT-based framework for building rich web applications using next-generation web technologies. Built on-top of ErraiBus, the framework provides a unified federation and RPC infrastructure that provides uniform, asynchronous messaging across the client and server.  In this interview, Mike describes the various components of Errai, how it fits into the larger JBoss ecosystem, and provides a project roadmap.

A complete transcript of the interview has been provided below. 

DZone: Mike, what exactly is the Errai project comprised of?

  Mike: Errai really is comprised of three primary components. The part we call ErraiBus, another part we call ErraiWorkspaces, and another part we call ErraiWidgets. And what we're trying to do with these three components ‑‑ and principally it's part of our internal strategy at JBoss ‑‑ is to build a really powerful platform that leverages the fact that GWT is a Java based technology that allows us to leverage knowledge in Java and take advantage of all of the tooling and the IDE support that goes with it. And be able to really, simply and straightforwardly, build out web tooling without having to worry about a lot of the traditional problems associated with building web applications.

And part of that has been founded primarily on our ErraiBus system, which really is a real serious attempt, and I think one of the first major attempts by any technology to create a programming model that permeates both the client and the server. 

And in so doing, it removes the need to think of things in terms of server and client, where we can think of the client as this serious place to actually do real business. And the server is just another part of the application infrastructure, a place to store information, and then come back to it and get that information later.

But Errai is really, I think, a different direction for JBoss and also for the industry as a whole, in the way that we're approaching things. And I think that we're really excited to be able to be doing something like this.

DZone: You mentioned that Errai leverages GWT. How does Errai fit into the larger ecosystem of Ajax frameworks currently out there?

Mike:  We certainly overlap with them in terms of certain use cases. But I think that we're very different in terms of the philosophy behind where we're coming from. We enter this world from a very fresh perspective. So we have this really powerful technology GWT, which Google has built. For those who aren't familiar with it, it's essentially a Java to JavaScript compiler, with also this emulation library that you're able to code against. So essentially, you're able to build serious applications in a browser by programming purely in Java. You never touch JavaScript. You can if you want to, but for the most part you're able to just program in Java. And it has very Swing‑like interface to it, APIs to it, when it comes to building out GUI components.

We took a look at this and we were thinking about how we were going to solve this problem. And we felt that with modern JavaScript engines that we're seeing in browsers today, it's becoming a real serious application platform. That is the browser, where we can do real work, where we can really crunch numbers and do real serious things without having to round trip to the server every time: to ask the server to do the calculations for us or something like that. Or the server suddenly becomes the touch point for building out these large applications.

There are a lot of implications to this and Errai has really kind of pushed forward in that direction, in that philosophy, saying build the functionality in the client and then worry about storing that information persistently on the server where you need to or setting up these special things that synchronize information in real time between the server and the client.

Mike:  So with ErraiBus, what we did was, following the philosophy that we would do serious work in the browser, we literally went out there and we defined our interface for this message bus service. What we originally did was we implemented a full message bus service that runs in the browser. We implemented a full bus service that runs in the server, and they both implement the same interface and the same APIs. The only difference is one runs in the browser, and one runs in the client. But from the perspective of the user, they don't really care. They are different implementations that federate to each other, but there's really no difference for the end user who's working with this.

So the way it works is that we have this, like I just said, a message bus service that runs in the browser and it's obviously compiled down to JavaScript. It handles all the different little endpoints that people declare. They either get to pick declared implicitly or explicitly depending on the program model that you're using. And the same thing on the server.

And when a client downloads its code from the server and it connects, they federate between each other. So you essentially create this flat hierarchical federation between the server and the client. So there suddenly becomes no difference between, say, declaring an endpoint called "hello world" on the server or one on the client.

If you declare one on the client, which will be the same with what you do on the server, and you send a message to it from the client, it gets there. If you have one called down from the server and the server calls on the client, it gets to both places. If you had one called on the server and you try to send a message to that endpoint from the server, it gets back to the client.

And this is interesting because essentially there's actually no way of telling from looking at the declaration code or the calling code where the message will be coming from, whether it will be from the server or the client code or from the calling code or where the message will be going to.

And so really, there's really this emphasis on removing thinking about where the service actually lies. And there's implications for that when it comes to doing offline applications with HTML5 technology, down the road. So that's another important aspect of it.

DZone:  Do you have any interesting examples of how Errai is currently being used in production?  Financial trading systems, social networking applications, and chat applications immediately come to mind.

Mike:  Well, those are all good use cases, and they've been ones that I've personally used. I'm trying to describe to people how this type of framework, the stock trading application is a perfect one, because our framework is designed from the ground up to do that type of thing, streaming information. One of the interesting aspects of Errai compared to other frameworks like DWR, is that because it uses this bus concept where they're looking at a service going to a client, this channel of communication is completely removed from the user.

You don't think about the actual I/O channel. It's completely encapsulated. And one of the interesting things that we found about taking this approach, this design approach, is actually we're able to get a lot more performance out of sending these asynchronous messages back and forth.

There are a few reasons for that. One is that ‑ and I will try and get to more examples in a second, I know you mentioned something about performance in the last question ‑ one of the interesting things is we're able to really tune the communication between the client and the server in real time.

For example, we have this concept called a transmission window. So if five messages are to arrive headed for one client, which might all be stock ticker updates or stock price updates, then they get captured in this transmission window.

Then they basically get transmitted across in one communication. So you don't get these five different TCP requests. In fact, we use a sticky keep‑alive when supported, and we basically are able to glob these things together moving across, and deliver them really efficiently on the other side.

And so one of the greatest things about our approach, is because it is this single channel of communication handled by the bus, we can really optimize the straining of information back and forth to the server, and actually minimize I/O activity.

This has been something that's been really interesting. We've proved this actually, in demos. In fact, I recently did a demo at a recent Toronto Java User's Group where,  using some more advanced engines like Chrome and Safari, I was literally able to show ‑ and I'm not exaggerating here ‑ sending 400, 500 messages per second from the server, to the client.

DZone:  That's impressive.

Mike:  Obviously those types of numbers aren't achievable with more arcane engines, like you find that on Internet Explorer. But, what it does show is that there's a huge future potential here as these engines become more optimized and efficient. And so one of the applications that ‑ actually, almost any application that you can think of ‑ can be used on top of Errai, and one thing that Errai starts to do, is it starts to bring back a lot of the paradigms to the software programming model that were not available to you before in the old request/response paradigm.

Because the request‑response paradigm really imposed upon us a limit to the types of architectures that we could employ. And I think that technology like Errai kind of opens that field up a little bit more and we can start thinking about different programming models and different patterns. And I think that's one of the interesting things that our technology does.

DZone:  How does Errai differ from JBossESB?

Mike:  Well, it's not an integration platform, it's almost like a closed system that's for doing the types of things that we've been talking about so far. I think the really interesting thing about something like Errai, is it actually functions as kind of a great platform to extend the functionality of something like that, a SOA architecture. If you go and actually look at what we do, we don't provide integration with legacy systems. We have this very simple "send a message, receive a message" paradigm. But at the end of the day, you're functioning within this bus paradigm, we're not doing anything to provide functionality to basically talk with an FTP protocol or over CORBA or anything like that. There's no integration for things like that in Errai and there never will be.

In fact, if we want that type of integration, we'll tell people to look at the ESB integration that we'll be providing at some point in the future. Or we'll tell them to look at integration for something like HornetQ or JMS in general. Errai doesn't support reliable messaging, this will shock some people; we don't guarantee message delivery. It's a very thin kind of I/O‑centric system that deals with providing a messaging‑based approach to programming distributed applications.

And I know that that sounds like, you know, "This sounds like JMS, " or "This sounds like ESB," but at the end of the day, we're talking about a pattern that I think applies to more than just those things.

When you look at some of the example applications we do, we're not just sending a message from the client to the server, or from the server to the client, sometimes we're sending some messages from the client to the client. Within the client we might be sending, we might be using this as a way of basically federating differently built components, because Quid is a statically linked technology.

If you build two Quid applications and try and put them in the same browser, there's no way to make them talk to each other. Well, as it turns out with Errai there is, because it basically, it talks to the dom, and enables kind of a federation within the client, and it also allows federation through the server, and through the server to other clients.

And so there's a very strong focus on web applications that's just kind of inescapable, and everything that we do is through that perspective. We don't even care about ‑‑ well, I'm not going to say I don't care about enterprise applications, because we're an enterprise applications company.

But from our architecture perspective, we don't deal with the same problems that ESB and JMS does. I know that's kind of hard to get your hands around because we're so used to hearing the word "messaging" and automatically gravitating towards things like JMS and ESB in our head, but that's just simply not the case.

This is kind of a tried and true software paradigm which has been around for 30 years and we just so happen to be applying it to this particular use case because I think it works really well.

DZone:  Does Errai provide any hooks to integrate with JBoss Application Server?

Mike:  Yes, actually. We do have specific AIO integration for the JBoss web container, but we don't have any specific integration beyond that. We don't need it, to be quite honest with you. Because all we really need is a ACGP server, and hopefully an API that we can build against to basically do to support asynchronous I/O, which we do support. We support that for a whole plethora of application servers now. And our jobs will be made easier in the future, as Servlet 3.0 becomes more available, because obviously it supports asynchronous I/O as part of the API, so that's actually the only support that we need.

DZone:  What is the Errai workspaces framework?

Mike: The workspaces framework is an ancillary component that brings together our bus technology, and some of our widget technology that we've built. It basically provides a rapid application development platform, kind of like the Eclipse platform, but really for the web, and built purely in GWT. And takes advantage of all these things, and provides a lot of meta‑database programming approach that even removes the need to, in some cases, even deal with the bus directly.

So we're trying to provide this really concise, simple way to build really powerful web tooling for different things. There's, like I already told you, we have the REST‑style platform, using the workspaces stuff.

Workspaces long term could be a really platform for building out of Internet applications, or even building a trading desk application. So that's going to be where our focus is, and there's a lot to be done there. There's a lot of open questions as to how we'll approach that.

This is kind of the interesting thing about our project, is our project really does live in a few different sub‑projects. The bus itself is a fully functional framework, in and of itself. There's people using that today, and I think that there's a lot of interesting things that we'll be doing in the coming months to shore that up and make that even easier, and to support even more app servers better.

The workspaces stuff, there's is a lot more UI focused in the workspaces stuff than there is in the bus. The bus isn't really a UI centered thing at all. It's a very I/O centered thing.

DZone: You mentioned another Errai sub-project, the widgets framework? How does that work? 

Mike: Our widgets framework is something that is is really important to us long term. We have this framework that we're building called Widget Bindings, which is really an attempt to make it really easy to bind data objects or pojos to widgets, or map collections of widgets to grids and have there be a bi‑directional relationship between those. So you don't have to worry about wiring in data and taking an object and going "Set text pojo.getname."

We've been working on building things like that in there, too. So what we'd really like to see long term is to bring together this new paradigm of working in this purely asynchronous world, but also provide a very declarative way of building applications that gets you a lot closer to that panacea that people want, which is to build these powerful rich applications, but to focus almost primarily on the business logic and not have to worry about the boiler plate code and worrying about specific caveats of doing this with Ajax or things like that. We want to abstract all those problems away.

Mike:  It's kind of hard to answer that directly. Errai doesn't have its own product roadmap at this time. What it does have is the fact that a lot of products are looking toward Errai to fulfill their product goals. The most important of which is creating a more unified console system for our web based technology, and that is the role that Errai is playing there.

So Errai is playing a very important role in our product strategy at Red Hat/JBoss, but it's currently not on the product road map itself. We would hope that, I mean as a young project, we haven't really gotten to that point of having to think about that. Long term of course, certainly, that would be a question that we would continue to ask ourselves.

DZone: Given your work on Errai, how do you see web applicaiton development evolving over the next three to five years?

Mike:  I think the next three to five years will be far more revolutionary and evolutionary than web applications have been in the last ten years. I think that there's a paradigm shift that's occurring and that has a lot to do with the move towards more rich applications, but it also have to do with the arrival of technology like HTML5‑based technology that are enabling a new kind of web development model. And I think that technologies like GWC will begin to play a much larger role in how we do web development. I think that the old days of template‑based web application frameworks are kind of behind us now. Obviously they're still relevant for a lot of people on a day‑to‑day basis.

But I think that going forward. I think that they're on the way out. I think the truth is that the browser is now is no longer an HTML renderer. It's now a serious application development platform. I think it has a lot of implications. I think that things like Flash and Flex and Silverlight will start to play a less and less prevalent role in the web developer's space as HTML5 becomes the dominant technology.

Errai started from a very almost HTML‑centric worldview when we began this project, as opposed to kind of looking back and figuring out how we adopt previous paradigms. We just kind of cut all that old baggage and started new. And that's an interesting thing about the Errai framework. When people ask us how is this relevant to Ajax or to JSF -- we treat it as if though it isn't. It is completely outside those worlds. And it's very much attached to where the web is going not where it has been.

DZone: How can people get involved with the Errai project?

Mike:  They can certainly get onto our mailing list, which they can find if they go to jboss.org/errai. We've actually been having lots of help from the community even in these early days. We've had some people who have been trying to do some pretty interesting things with it and actually going through our code and correcting us in places where we've been wrong. We certainly encourage that. We'd love to see more community involvement in something like this because it'd certainly help. And we're very responsive to those people who like looking at new, young technologies and playing with fire.

We're certainly very responsive; we try to fix bugs really quickly, often within a 24 hour period when people make us aware of them. So, we're really looking both for contributors and early adopters who are willing to help us iron out a lot of the problems.

DZone:  Mike, on behalf of the DZone community, thank you very much for your time today.

Mike:  Absolutely.