RSSBus is a suite of data Connectors and web server products for accessing data and building Simple Services from Enterprise and Internet information sources.
Power users can combine Simple Services to filter, move, and merge information. Business users can call Simple Services directly from browsers, SharePoint and other portals, and Excel - without custom client development.
The low learning curve and low cost of RSSBus will jumpstart your service oriented architecture and advance your portal functionality, while the built-in SOAP support will leverage and extend any prior services investment.
Q: What can you do with RSSBus? / Who can use RSSBus?
Business users can:
Use Simple Services from any client that can call URLs, including browsers, portals, Excel, and other office applications.
Use the RSSBus SharePoint Web Part to bi-directionally work with data from internal and external services and data sources.
Power users can define RSSBus Simple Services and/or RSSBus SharePoint Web Parts to:
Generate RSS feeds, spreadsheets and web pages from any data source.
Convert any data source to ATOM, SOAP, CSS, XLS, HTML, and any other desired format.
Transfer data between different kinds of data sources.
Build Enterprise and Internet mashups that combine data from multiple sources.
Convert existing SOAP and REST services to Simple Services.
Programmers can also:
Call Simple Services from any programming language.
Call any RSSBus Simple Service or RSSBus Connector using SOAP.
Create new reusable Simple Service data connectors.
Create new Simple Service output formatters.
Q: What are Simple Services?
RSSBus Simple Services are like regular web services, but they use consistent input and output formats that are easy to parse and process.
Requests are standard URL's with query strings or post data, like this:
http://myserver/getContacts?city=Chicago
And responses are name-value-pair item lists, like this:
Title - My Contacts
Item
Firstname - Bob
Lastname - Smith
Phone - 123-3445
City - Chicago
End Item
Item
Firstname - Suzie
Lastname - Jones
Phone - 345-5567
City - Chicago
End Item
. . .
Simple Services also accept lists as input, so it's easy to chain services together.
Q: Why is simple better?
Simpler interface standards mean simpler deployment, simpler integration, and simpler extension.
With RSSBus, you can easily:
Combine output from several services into "mashups".
Pipe the output of one service to the input of another.
Call services directly from browsers, portals, and office applications.
Add new data sources to applications and mashups.
Add new data fields to services without impacting existing callers.
SharePoint
Q: What is the RSSBus SharePoint Web Part?
The RSSBus SharePoint Web part is a no-code solution that can use any RSSBus Connector, RSSBus Simple Service, or standard data feed (e.g. RSS, Atom, CSV, XML, etc) and display and modify that data right inside SharePoint using simple HTML wiki-like templates. This enables Microsoft SharePoint page authors to access hundreds of Enterprise and Internet information sources from within their SharePoint pages.
Q: What are RSSBus Web Part Templates?
The RSSBus SharePoint Web Part: "One Web Part, hundreds of applications". To accomplish all this functionality, the Web Part itself relies on RSSBus Web Part Templates that tell RSSBus what to do. You can provide your own RSSBus Web Part Template, or you can try one from our Template Gallery.
Q: Who can use the RSSBus SharePoint Web Part, and what can they do with it?
SharePoint administrators can:
Install the RSSBus SharePoint Web Part once and not worry about any data access details,
ongoing configuration, or administrative overhead.
Activate the optional RSSBus HTTP Handlers feature to enable serving of Web Part contents and RSS feeds from within SharePoint Document Libraries.
SharePoint page authors can:
Configure instances of the RSSBus SharePoint Web Part on their pages without
special privileges or administrator assistance.
Use the Web Part to call RSS feeds, RSSBus Connectors, and RSSBus Simple Services.
Format the returned data using the Rich Text editor or familiar HTML markup.
Q: Do I need the RSSBus Server in order to use the RSSBus SharePoint Web Part?
No. You can use the RSSBus SharePoint Web Part in many ways:
By itself to call, format, sort, combine, filter, and completely customize the display of existing RSS or Atom feeds.
With RSSBus Connectors to access dozens of additional information sources. See the Connector library for a list of available RSSBus Connectors.
With RSSBus Server to define and call RSSBus Simple Services.
With the optional RSSBus HTTP Handlers feature to create Simple Services inside a SharePoint Document Library.
Q: How can I define Simple Services in SharePoint?
RSSBus for SharePoint comes with an optional feature called the RSSBus HTTP Handlers. This feature, when activated, allows you to create Simple Services (.rsb and/or .rst files) in SharePoint Document Libraries.
Architecture
Q: Does RSSBus interoperate with PHP, EJB, ASP.NET, Ruby, etc?
You can invoke RSSBus Simple Services from any language or platform. Services are called with regular URLs (e.g. http://myServer.net/getcontact?name=smith) and the results come back in your choice of formats that are easy to display and parse.
Q: What exactly do RSSBus Simple Services return? / What is a formatter?
RSSBus Simple Services can return several standard list-based formats, including:
RSS2.0 -
XML list of 'items' which are name-value-pair tables as above.
ATOM -
Another common format of lists of names and values.
XLS -
Interactive spreadsheet with embedded request and response.
CSV -
Comma separated values.
JSON -
Names and values as JavaScript Object Notation data.
HTML -
Data formatted into a web page, you supply the page template.
SOAP -
For compatibility with SOAP-based services.
Every RSSBus service can return any of these formats by appending a format specification to the end of the call URL, like this:
A service definition is a text file that defines a Simple Service. The service definition specifies the service URL, the service inputs and their defaults, the connector configuration and call, and optional result processing. In RSSBus, the connectors (described below) implement the details of information access, and the service definitions implement your business requirements. See the RSBScript Quick Start Guide and tutorials page for examples of service definitions.
Q: What is an RSSBus Connector?
RSSBus provides dozens of reusable Connectors that you can use to access various information sources when defining services. You don't have to write code to use these Connectors; you simply configure a service definition that will invoke the ready-to-use Connector for you.
There are Connectors for database access, cloud computing, financial services, shipping services, and more. Each Connector hides the complexity of the information source behind it, so all Connectors behave the same way, with a list of name-value pairs for input, and lists of name-value pairs for output. See the Connector library for a list of available Connectors.
Q: How do you call Simple Services?
Calls are standard URL's with query strings or post data, like this:
http://myserver/getContacts?city=Chicago
Q: How do you combine Simple Services?
Connectors and Simple Services use consistent input and output formats so it's easy to combine them to create more advanced functions. For example, a single service can call more than one data connector and then combine, filter, sort, and otherwise customize the results. Multiple services can call each other on the same server, or call from one server to another. Service definitions can contain loops and if statements to implement simple logic and branching. You can call Simple Services from any application, or create your own custom service processing in service definitions or custom connectors. See the RSBScript Quick Start Guide for more details.
Q: Why don't you just use SOAP?
We support SOAP for compatibility, but it's not the simplest format, and we're trying to be really simple.
SOAP is based on the remote procedure call model, where players agree on fixed message formats (the WSDL's), and register them in a common message repository (the UDDI). Up-front agreement sounds good in principle, but in practice this creates n-way dependencies between the applications, so extending a SOAP message for a new app can break existing apps.
Note also that SOAP requires tool support to find and read the WSDLs, and application code to assemble and parse the SOAP message envelopes. You'll need message directories, message architects, SOAP programmers, and in some cases, more patient users.
In comparison RSSBus has much lower overhead and complexity. With RSSBus the responder just sends the available data (or data allowed by security configuration) and the requestor looks through the name-value pairs for what he needs. And anyone can configure and call RSSBus services right from their browser or portal.
Q: What about REST?
Simple Services are more like REST than SOAP, and while we do support the four HTTP methods (GET, POST, PUT, and DELETE) for those cases when you need to strictly enforce the REST conventions, we do allow writes via GET URLs if the script author so desires. RSSBus services can call REST-based services as well. See an example of calling and creating RESTful services in the demos/ directory that comes with the RSSBus Server product.
Q: What about security?
RSSBus Server builds on top of security features of IIS and ASP.NET, providing authentication and authorization at the user and group level, and full SSL encryption support. Please see the chapter on RSSBus Security in the RSSBus Server User's Guide, which comes installed with the product.
Deployment
Q: How do you create a Simple Service?
First you identify the information that you want to serve and the read and write operations that you want to support. Use the RSSBus Admin Console to browse for the appropriate Connector in your local Connector library, or visit the RSSBus web site to download more Connectors. Use the Admin Console to test and configure the Connector against your information source, and when you're reading, click "create service" to invoke the service definition wizard. At this point a service definition will be automatically created for you, and you can optionally customize it to suit any additional needs you may have. See the RSBScript Quick Start Guide for more informations about this process.
Q: What is RSBScript?
RSBScript is used to define Simple Services. This XML scripting facility includes statements for setting input values and defaults, calling operations, and processing the results via an output loop. RSBScript also includes some basic flow control statements like if-else and error trapping. You can learn more in the RSBScript Quick Start Guide.
Q: What is an RSBTemplate?
An RSBTemplate is a service definition that returns a formatted HTML page instead of raw list data. You can call operations and insert the results directly into your template page, so that you can combine information access and display formatting in one step. Templates are ideal for surfacing information in browsers or portals. You can see sample templates in the RSBScript Quick Start Guide.
Q: Can I write my service definition in a language other than RSBScript?
Service definitions are implemented as script files that specify service inputs and their defaults, which Connector to call, and which results to stream back. Currently definitions can be specified in Python, Tcl, VB Script, PowerShell, Javascript, or RSBScript, but it is not hard to incorporate other script languages using the built-in language support feature as described in the RSSBus Extensions API included with the product kits. There is a sample Python service definition at the end of the RSBScript Quick Start Guide, and there is a summary of Python support on the RSBScript Reference.
Q: What's the difference between RSSBus Server™ and RSSBus Desktop™?
Both the RSSBus Server and the RSSBus Desktop include everything you need to develop Simple Services, including the RSSBus Admin Console for testing and deploying services, a selection of Connectors, full documentation, and a demo services directory. RSSBus Desktop can be called from your local machine and is intended for service development and personal service use. RSSBus Server can be called from remote computers and is designed for production use.
Q: What are the platform requirements for RSSBus?
RSSBus Server and RSSBus Desktop target the Windows platform and require the Microsoft .NET 2.0 Framework. If you are running Windows XP and above with Windows Update, you should already have Microsoft .NET 2.0 installed on your machine. RSSBus Desktop includes a built-in Web server, while the RSSBus Server runs on a standard IIS installation.
We also have a pure Java edition and a Google App Engine edition available on the beta downloads page. RSSBus for Java is a pure Java implementation of RSSBus Server and runs on Jetty, Apache Tomcat, WebSphere and other common Java platforms. RSSBus for Google App Engine is also a pure Java implementation, it is designed exclusively for deployment to Google's web infrastructure. These betas do not have as many Connectors as the more mature RSSBus for .NET edition.
Q: Are you going to build a Connector for ...?
We are constantly seeking to expand our Connector library, and we would be interested in hearing about your Connector idea for possible inclusion in our development queue. Note that you can write new Connectors yourself using Python/Tcl/VBScript/PowerShell/Javascript as documented in the RSBScript Reference, or using a .NET programming language as described in the RSSBus Extensions API, shipped with the product kits. Also remember to check the Connectors library from time to time for any new Connectors.
Q: Can I add new output formats?
RSSBus is very extensible, and includes .NET programming language support for developing new output formatters. Most of the processing details are taken care of for you; you only have supply string formatting for each output item. This is described in the RSSBus Extensions API shipped with the product kits.
Q: How well does it scale?
Response time and throughput for Simple Services is pretty much determined by the connected information source -- database, file system, remote API service, etc. RSSBus adds very little overhead itself.
For example, a Simple Service calling a local SQL db delivered 10,000 to 35,000 requests per minute, but a service making three Amazon searches delivered around one hundred requests per minute. RSSBus includes caching features that are particularly helpful for slower data sources, improving throughput for the database case by 150% and for the Amazon case by500%. For these tests RSSBus was running on an AMD Athlon 64 2.4 Ghz Dual Core with 3GB RAM.
Other
Q: Will RSSBus work for my application?
Send us an email or give us a call, and we'll discuss your application! We love to hear your ideas. Please visit the contact page to get in touch.
