RSSBus Feed Server is primarily an infrastructure to host simple web services. It allows one to quickly write scripts that take HTTP requests as input and produce simple feeds as a response. The extensive number of Connectors already available makes it possible to access data from many different sources. Today we will share our thoughts on some of the features that simplify the creation of service oriented architectures based on RSSBus.

Before we delve deeper into various options, let us remind ourselves of some guiding principles. We would like the solution to be simple, quick to implement, and benefit from the core promises of service oriented architectures. In doing so our solution should maintain:

• loose coupling: making sure that a service does not depend on implementation details of another service,
• reusability: consistent use of simple and extensible modules, patterns and formats, and
• composability: ability to create new services by assembling composite services.  

RSSBus Connectors

RSSBus Connectors are .NET assemblies (modules) that are dynamically discovered by the RSSBus Engine upon installation. They take advantage of the .NET Framework and are extremely flexible in their capabilities. Each Connector is composed of one or more operations for accessing data from a specific data source.  Operations include only two functions, an Info function that describes the allowed inputs and outputs, and an Exec function that does the work.  The RSSBus API also allows an operation to call another operation, facilitating composability. Partitioning data access and business logic into individual operations and formally defining their service contract can help you implement new Connectors quickly in a predictable, extensible way.  RSSBus Feed Server ships with 70 Connectors to common Internet and Enterprise Data Sources, and you can easily create new Connectors using a simple API and .NET development tools (see the example in the White Paper).

RSBScript

The operations included in RSSBus Connectors are written to accept a variety of HTTP requests and host configuration inputs (for example the name of a SQL table to access or the username of a POP mailbox to read) and they can produce a rich variety of response output.  RSSBus makes it easy to configure operation inputs and outputs by wrapping those calls inside RSBScript.  Besides manipulating input and output, the script can be used to define user and role based security, manipulate response headers and data format, enhance performance with built-in caching, and more.  RSBScript allows invocation of one or more local or remote operations, and also has a number of simple control logic features.  RSBscript makes it easy for an administrator publishing the services to make the deployment decisions, while relying on developers to build core data access functionality within the Connectors.

RSBScript can also call other programming languages for implementation of more extensive business logic. RSSBus currently supports Python, Tcl, VBscript, Jscript and PowerShell, through an extensible API that allows easy creation of plug-ins for other languages.

RSSTools and Client Side Processing

Though RSS feeds can be consumed by RSS readers, email clients, and browsers; feeds generated with RSSBus also have data points that other programs can use. The format of data feeds generated by RSSBus is very simple, and most programming languages with basic XML libraries can easily work with them. To make this even easier we supply a set of tools for common development technologies. The ability to compute with feeds on the client side makes it possible to publish services that are suitable for a broader audience.

In addition to facilitating client side processing of feeds, RSSBus can alter the service response using RSSBus Feed Formatters. It is a simple matter to present the response of a service as HTML, CSV (comma-separated values), ATOM, JSON, etc, using existing feed formatters.  These formatters can be used by supplying parameters like (@json, @html, @csv) in the HTTP request. Moreover, extensibility via the Feed Formatter API makes it possible to expand the existing set of response formats.

To summarize: what we have laid out in this post are some of the options RSSBus offers to move towards a more service oriented architecture. The benefits of SOA are well known, and we hope we can help reduce the costs and accelerating uptake of SOA.  There will be more details in future posts.