Introducing Rugby

Rugby is package of client and server components that enable powerful networked applications with as little as a one or two lines of program code.

With Rugby you can build popular types of applications like these:

Web Services - Clients and Servers.

REBOL Client/Server communications.

REBOL Peer-to-peer applications.

Rugby can make your applications run across multiple machines, using secure communications, via http tunnelling. Using Rugby you can do this for existing applications in minutes.

Status Update

The author or Maarten Koopmans is not further developing or supporting Rugby. However Rugby is fairly stable and a number of users appear to be still using Rugby for commercial projects because it is a very easy way to get up and running in this area.

What is Rugby?

Rugby is middleware

Middleware is software that is used to glue other software together. Rugby's author Maarten describes Rugby as X-Internet middleware. This means that Rugby is glue to make the executable internet a reality.

Rugby is a request broker

Rugby at heart is a small Request Broker - a remote procedure call mechanism. That means one program on one machine can call a function defined by another program on another machine. The job of a Request Broker is to enable you to do this without you having to write lots of complex communications code.

Calling a function on a server should be transparent to your program code. It should seem as if the function resides in the same program that you are calling it from.

For a light hearted description of Request Brokers read:

Request Brokers and The dark times of distributed computing

What Rugby does

Say you have a script with some functions defined and the main execution code. Rugby allows you to split that script up to run across more than one Rebol process (usually on different machines). You could put all the functions in one script and place that on a server machine for example. Then your remaining script can call the functions that now live on the other machine.

It can do this even over a HTTP connection. So your server based function can be on the other side of a firewall and proxy server.

There are two sides to Rugby. Client and Server. Rugby turns function calls made on the client into network requests. On the server machine Rugby creates a listening port (server) and converts the network requests it receives into function calls to the functions you wrote. The results of those function calls are converted back to network responses and sent back to the client. Back on the client Rugby receives the network responses from the server and converts them into function results.

Your program code appears to have just called a single function and received a result. That is, without doubt, really cool.

What Rugby does not do

It will not brush you teeth for you, nor will it take out the garbage. In addition to these important limitations it:

does not provide replication;

does not come with pre-built customised applications (though other people may release these);

does not provide a comprehensive enterprise standard work group collaboration framework

Why point these things out? Because those are things Rebol/IOS does well and those things are important.

Rugby is important in its own right and has its own niche This should be clear from the introduction of this document.

Rugby also has value in promoting IOS and REBOL. It can be used to do early prototypes, proof of concept applications that will demonstrate suitability of REBOL as an application development language and REBOL/IOS as a solution for corporate messaging needs.

Rugby in action

Enough verbosity for a moment. Let's look at Rugby actually doing some magic.

Seven line client / Five line server

Imagine you have a device connected a machine and you want to turn it on and off remotely. Let's look at some Rebol code using Rugby to achieve this goal.

First the machine that controls the device. We will need to create a Rugby server. That is done by the last line of this script:

REBOL [Title: "Device controller"] do load-thru http://www.reboltech.com/library/scripts/rugby4.r device-on: does [ print "switch device on" ] device-off: does [ print "switch device off"] serve [ device-on device-off ]

Next we need to write the remote control application. To do this we need to ask Rugby to provide the remote procedure call functions. This is done with the third line of the script here:

REBOL [Title: "Remote control"] do load-thru http://www.reboltech.com/library/scripts/rugby4.r do get-rugby-service tcp://localhost:8001 view layout [ button "Turn On" [device-on] button "Turn Off" [device-off] ]

These two example programs work. To try them out save each into a seperate script file, run the server in one Rebol session and then run the client in another instance of Rebol. If you want to try these programs on seperate machines you will need to change the address of the server in the third line of the "Remote control" program.

Other scenarios

Think of a script you have written. Does it make sense to put some of it's functions on a server? If so you could use Rugby to do it in probably 5 minutes or less.

For example an intensive calculation server. Maybe some really grunty machine (or server farm) can do some intensive calculations - you just call a function for the answer.

Rugby can do peer-to-peer as well.

You can use Rugby to make a chat/game type program (Gorim2 at the Compkarori rebsite uses Rugby for this).

A whiteboard example. You could have one person drawing on a whiteboard and various observers watching the changes.

Security

Exposing Rugby services on your machine necessarily exposes your machines to heightened security risks.

Read X-Internet Security - An Introduction for an introductory article on some of the issues when you provide Rugby services. This article describes some easy to fall into traps when processing executable code over the net.

Rugby security support

Rugby offers a couple of security features that you can use to improve the security of your applications.

On the server side. You can use SECURE-SERVE to enable encrypted communications between the server and the client (for those clients with licensed version of Rebol).

Another thing you can do to protect your server is to use the /RESTRICT refinement of SERVE and SERVE-SECURE. /RESTRICT allows you to specify a block of ip addresses. Only machines with one of these ip addresses will be able to make successful Rugby requests against the server.

On the client, if you have a licensed version of Rebol (for the encryption support), it will automatically encryption communications when it connects to a server that has published services via SECURE-SERVE.

Rugby Links

Rugby download

The author's distribution has a disturbing tendency to spontaneously dissappear. If it does so again, then the try REBOL.org library which contains a number of versions and related scripts.

Related Links

Patrick Philipot has written Rugby: getting started. He also has a demonstration tic-tac-toe game using Rugby on his REBOL/View rebsite "Pat665".

X-Internet Security is an article I've written pointing out some security issues you should think about when publishing any web services including Rugby.