Motivation for REBOL/Services
In the next few weeks, as parts of REBOL/Services get released for feedback and review, I will be writing a lot more about it. Before beginning with the technical details, I wanted to talk a bit about the motivation behind the creation of REBOL/Services...
These days our company (RT) operates a number of servers and remote processes that are a crucial part of our business. Each one of these "services" consists of a custom-made REBOL program that includes its own unique network protocol, authentication technique, and command processor. In addition to these custom systems, we also run a variety of other network services that are part of our IOS or AltME communication systems, and both of those also have their own service methods.
One of the great benefits of REBOL as a messaging language is that these special types of network services can typically be written and debugged within a few hours or days at most. Unfortunately, that fact also leads to a proliferation of services, each one being slightly different in design and method of operation (often times improving the methods along the way). Normally, there is no standard design or interface for these services, other than their common use of REBOL for implementation.
Our primary motivation for REBOL/Services is to provide a standard service oriented architecture (SOA) that is capable of supporting a wide variety of applications. With such an SOA, REBOL processes on one system will be able to easily identify, validate, connect, and communicate with a variety of service processes on other systems (or even within the same system). This allows future application developers to take advantage of a standard, robust, embedded SOA but with less effort and cost than custom solutions or other more complex and expensive web service technologies.