Jon
Hi, this is Jon Udell. The acronym RSS usually stands for really simple syndication. Gent Hito proposes another complementary expansion of the acronym: really simple services. He’s been developing a product called RSS Bus. It’s a .NET-based engine for desktops and for servers that aims to simplify both the production and consumption of data expressed in terms of name-value pairs and exchanged by way of RSS or Atom feeds. By normalizing all data feeds to flattened sets of name-value pairs, RSS Bus trades away some of the power of advanced data modeling in order to reach a broad population of developers and even, ideally, ordinary information workers who will be able to pull feeds into their spreadsheets, combine and filter them, and publish their transformed feeds back out to the net.
What we want to talk about specifically is this RSS Bus thing that you guys have cooked up, and I think more generally we want to talk about ways in which lightweight mechanisms of service coordination can be constructed by developers and can be made available for use by ordinary people.
What we’re trying to do with this product is make a case for simple web services. Just like you have a standard SOA architecture that people are talking about, where you have different kinds of services inside a corporation or outside a business that are secured in certain ways and architected in certain ways, we want to make a case that there’s room in that architecture for simple web services—services that can be consumed by a wide variety of tools and understood by a wider range of people than what we normally mean today by web services.
Do you think it’s an uphill battle to explain it to developers?
Gent
Not necessarily. You have some barriers that people put in front of you sometimes that are more related to the way they’re used to doing things. However, as you go up the chain—if you look at development managers and people that are trying to solve the problems and are closer to the end user or the line-of-business managers—you see a lot more understanding because they feel the pain. It’s impossible to have IT solve every problem for a particular business. You need to involve the other users—the domain experts, the people who work with the tools—and the more capabilities you give them, the easier it is for them to do their job. It reflects better on IT as well because they enable people, as opposed to just delivering solutions.
Jon
Maybe I can start here. I’m looking at your overview page. You say RSS Bus provides an infrastructure for generating, maintaining, combining, manipulating, and visualizing feeds—that is, RSS feeds. You say items and feeds are orchestrated by the engine and help create a loosely integrated application architecture, which we like to refer to as “RSS web.” Stuff that’s near and dear to my heart—I’m somebody who’s been in my own way practicing this approach for probably quite a while. You have, as I understand it, two versions of RSS Bus. There’s a version that lives on the desktop and a version that lives in the cloud, right?
Gent
Well, I wouldn’t say the cloud. There’s a version that works on the server.
Jon
Okay, you can install it.
Gent
Yes. The division there is purely licensing. We have the RSS Bus desktop product that people can install on their machines and we would like to keep it free forever, so that if you want to expose services or feeds or consume feeds or work with them on your desktop, you have the ability to do so and feed them back to the network. The server version is more managed, more controlled—fully supported, etc.—that we’re going to sell as a commercial product.
Jon
Given that lots of us for quite a while have, in our own ways, been pretty easily able to combine, generate, manipulate RSS feeds to do all sorts of things, what’s the value add here? What are you bringing to the picture that isn’t otherwise available pretty straightforwardly to anyone who’s handy with programming or scripting and with data?
Gent
Well, there is a little wordplay in the name of the product. The “RSS” in RSS Bus stands for “really simple service” that uses RSS—really simple syndication—as the format for disseminating data. We try to use RSS or syndication, because the product works with Atom and other formats as well, as a way to distribute data and also as a way to normalize APIs for web services.
The way RSS Bus looks at services is you look at a URL—everything is accessible through a URL that takes a series of inputs, name-value pairs—and then what you produce is a series of items. In RSS, items normally have just text, but if you look at services like the Yahoo Weather feeds, for instance, you’ll see that in addition to text, they also have data points. They’re going to give you things like temperature, the time the measurement was taken, wind speed, humidity, etc.
Jon
Are they doing that in an extended namespace?
Gent
Yes, they do that through RSS extensions or Atom extensions. What we do with RSS Bus is make that process very easy. You can point the product to one of the connectors in RSS Bus to a database and quickly select, point and click, whatever fields of the database you want to expose. You define what text you want to put on these items, and then you publish that as a feed or as a simple service.
Jon
So the idea here would be if you were someone who wanted to produce an effect like Yahoo has produced, where there’s an RSS feed that has namespace extensions for specific kinds of extra data, you would use this to simplify the task of producing that kind of feed.
Gent
Exactly, and you’d be able to do this without writing code. In the future, you’ll be able to do it without understanding development or programming. That’s our goal, and we’ve gone quite a ways there. But today, you can do it without writing any code. RSS Bus comes with more than a hundred connectors that can access various things—various services, databases, mail systems, directory systems. You can take the standard connectors and modify them to create feeds or lightweight web services, or you can create your own if you’re a developer and you’re trying to access a data source we haven’t provided a connector for.
Jon
What would be a good example of a kind of integration that someone who is inclined to do this but is not necessarily a programmer could accomplish codelessly?
Gent
For instance, you’re receiving leads from various sources—people interested in your product, and you’re receiving leads from websites, emails, etc. If you architect these as feeds, you get aggregation for free. You could pull these all into a master feed, then do some filtering from one to another and distribute the data. Now you can take that feed with, say, the cleaned leads, connect it to one of our email-sending web services. By connecting the data that comes from the client to the data that sends an email through a template, you can send an automatic follow-up email to all these people. Your scenario can be described in RSS Bus with very little scripting at this point.
Jon
So it’s done declaratively?
Gent
Exactly.
Jon
And the declaration takes the form of a kind of script language you’ve developed?
Gent
We call it RSBScript. It’s an XML-based configuration language. I would say it’s the equivalent in text form of what you have in a graphical form with Yahoo Pipes, except that we give you a lot more capabilities and a lot more power than what you can see on Yahoo Pipes today. Now we’re looking at graphical ways of representing the same declarative statements in the future, but right now what we have is just the scripting language. These scripts can execute client side or server side.
Jon
I think the scenario you just described would involve both of those, right?
Gent
Yes, you can run the script on the RSS Bus server, or you can do the same in the RSS Bus desktop version, which is essentially an embedded version of the server.
Jon
What would be the point of having the desktop version versus using a server-based version?
Gent
It’s a playground, first and foremost, where you can create things without having to deal with something that’s remote. However, if you look at the desktop as your main point of contact with the web—where you do your aggregation, get your data—it just makes sense to define all the feeds that make sense to you personally on the desktop. Now, in addition to that, there’s a concept we like to call triangulation, where you want to connect more than one service, and there are no connectors. Let’s say you do business with Company A, which does selling for you online, and you do business with Company B. Normally, the critical piece—what Tim O’Reilly calls the new Intel inside—is data. Company A wants to keep your data there, Company B wants to keep it there, and they’re not necessarily incentivized to communicate with each other.
If a third party tries to enable that communication between the two companies, they might be in a tricky legal position. If you take this same data that actually belongs to you and pull it to your desktop, you can manipulate it, and there’s no reason you can’t invite third parties to do that for you.
Jon
When you say “on my desktop,” that could just be a proxy for some server instance I control, right?
Gent
Exactly. It could be the desktop is running on a server instance. But in another sense, that instance might be considered a third-party provider. If you’re producing data that come from a source—your data—and those sources aren’t happy with combining them on an external platform, you probably want them on your own platform.
Jon
Right, and what I consider my own platform isn’t necessarily relevant to whether it lives on my desktop or in a server instance I control. But I guess there are also situations where you want to integrate local files or local PC resources, which you might not want to entrust to a server, right?
Gent
Oh, yes. That’s the area where some data you cannot trust a third party with. Here’s an example I personally use every day: there’s a connector in RSS Bus for getting credit card data from various credit card companies—American Express and so forth. I monitor American Express for new charges. To do this, I need to supply my account number, username, and password. I don’t necessarily trust a third party with that, but I can handle it safely and securely on my desktop.
Jon
That’s a nice example of a service that leverages the privacy of the desktop but also orchestrates other services in the cloud.
Gent
Exactly. You get data from the cloud, or get capabilities from the cloud, and bring them together in a normalized way so they look similar to one another. That makes them much easier to combine, and that’s where the “bus” part in RSS Bus comes from.
Jon
I wanted to explore a little bit about using WebDAV relative to office applications, because I think that might also be interesting.
Gent
WebDAV? We do have a WebDAV connector, but I believe in your example we actually used ODBC to connect with Office. But yes, .NET provides a few different mechanisms. What’s important on the desktop is that security-wise, you’re the one logged in, so you have access to your data.
Jon
Right, maybe the example I’m thinking of was pointing Excel to a local web folder. That might not have been WebDAV per se. Anyway, you definitely have an Excel connector, right?
Gent
Yes, we have an Excel connector. We can do it both ways—pull data from Excel into RSS Bus as a feed or push feeds from RSS Bus into Excel using the external data capability. And because we reduce everything to name-value pairs in items, that translates well into rows and columns in Excel.
Jon
So it lands in someone’s spreadsheet as a flattened list of name-value pairs, which makes it easy to combine with another flattened list of name-value pairs, particularly if any names match.
Gent
Yes. By flattening, you lose some of the flexible modeling, but you gain a lot of accessibility for a wider audience. It’s much simpler for non-developers.
Jon
All right. Let’s talk about the architecture in terms of what this actually is, how it runs, how it relates to the desktop, and what kind of server implementations you have.
Gent
Sure. The main server—the RSS Bus engine—is implemented in Microsoft .NET, 2.0 and above. It’s just an ASP.NET application, nothing unusual there. When you call into RSS Bus, you have the ASP.NET runtime available.
Jon
Framework 3.0 then?
Gent
2.0 and above.
Jon
Okay.
Gent
We started at 1.1 but needed features in 2.0. That platform is widely available now, so that’s what we use.
Jon
For people on XP, presumably they’ll need to install the .NET framework to make this work?
Gent
Yes, and in the RSS Bus desktop setup, if you don’t have it, you get prompted to install ASP.NET.
Jon
So from the user’s standpoint, they’re effectively running a local web server that they interact with through a browser?
Gent
Exactly. Everything is over HTTP. We have a small AJAX-based front end that’s fed by RSS Bus. Under the covers, the engine orchestrates everything, and underneath that engine, there are one or more connectors—.NET assemblies that we provide for accessing data sources. We have a simple interface: each connector implements two methods, info for metadata, exec for execution.
Jon
Could these be written in .NET dynamic languages like IronPython?
Gent
Yes, we have an IronPython provider included. You can also call native components, so you can do VBScript, etc. That’s fairly popular on the Microsoft platform. The engine and connectors are in both the feed server and the desktop; they’re just tuned differently. One is multi-user with more management and control for servers; the other is single-user on a desktop.
Jon
And the desktop version is free, while the commercial server product is not?
Gent
Correct. We’re still in beta, but you can get them now at rssbus.com.
Jon
You mentioned another part of the architecture is the suite of RSS Tools that allow you to consume or produce feeds from a variety of languages. Could you explain that?
Gent
Yes. Let’s say you have a legacy Visual Basic 6 application from ten years ago that suddenly needs data from an RSS feed. We make that a drag-and-drop scenario. Or if you want that same legacy application to publish data, we have an embedded web server component you can drop in. Then that app can respond to feed requests—somebody calls a URL, and you provide an RSS feed in response. So it makes these legacy apps first-class citizens on the bus.
Jon
Yes, that’s very straightforward for people. You said you’ve been working on this for a while. Why has it taken so long?
Gent
As developers, we see the possibilities of these platforms right away, but it takes time for everyone else to get it. We tried something similar back in ’97 or ’98 with a product called Virtual Grid, basically an embedded HTTP server behind a visual component. People wanted an actual grid, though. It was too new. Also, back then, making machines talk to each other was specialized. Now it’s expected.
Jon
Yes, I was experimenting with local web servers in ’97. The possibility blew my mind. But like you say, it was a small niche at the time.
Gent
Exactly, and we want to democratize that.
Jon
Right. Let’s talk for a moment about WS-* web services at the enterprise level. How do you see RSS Bus coexisting with that?
Gent
We see a place for both. We’re on .NET, so you can consume or produce WS-* services as connectors in RSS Bus. We think a “feed garden” approach can coexist with more enterprise-level WS-* deployments.
Jon
So if I have WSDL-defined services, I can just roll them into RSS Bus as well?
Gent
Yes, absolutely.
Jon
You mentioned that you’re near shipping; you have a beta out now?
Gent
Yes, we’re on beta 4D, which is the sixth beta. We’re hoping to ship soon. Our feed server is the first official product—mainly just a tool that creates feeds. People don’t have to buy into our entire vision; it’s already useful as a way to publish RSS feeds easily. But of course we see it as more of a platform for applications. Also, we have a partnership with NewsGator, and we’re talking to other folks about distribution.
Jon
People always ask, “Why RSS and not Atom?” or “Why not something else?”—but that kind of misses the point, right?
Gent
Yes, it’s about really simple services, not just the format. We can’t do everything, but you can do a lot with a lightweight approach—give people tools they can easily adopt.
Jon
Absolutely. And I’m not a WS-* detractor. I’m happy to do both. It’s never been either-or.
Gent
Exactly.
Jon
Is there going to be a playground for this at your site?
Gent
We’re not running a full cloud service, but we’re talking with partners to possibly do something like live.rssbus.com. Another approach is letting the desktop install push out feeds in a scheduled way via FTP or whatever. A lot of people want local control but still want to publish to the net.
Jon
I do that a lot myself. For instance, I have an RSS feed that alerts me whenever a book on my Amazon wishlist shows up at my local library. I run a daily scheduled task on my PC, scrape the library website, generate the feed, and push it to my site.
Gent
Yes, we might do a connector for OCLC or something similar, because it’s a great pattern. Often it’s screen scraping if the site doesn’t already provide a feed. The same applies within the firewall—many installed apps still have no service interface.
Jon
Right, that’s exactly how WebMethods started—providing a screen scraper for services. Great. Well, thank you for talking, and I hope we can meet in person soon.
Gent
Likewise. Take care.