Regular Statement String (RSS) 2.0
By Liu Rui
Nov. 2003
This document is about Regular Statement String (RSS),
which will bring you (application architects, senior developers or software
product managers) new ideas of how to build simple but powerful application
interfaces. Further more, you can use RSS to integrate your C/C++, Java
and COM applications with ease. I believe you will have fun along with
it. Following are the major topics:
Process Oriented Interface (POI)
Everyone talk about Object Oriented Programming, and it seems that all
application interfaces should be designed as an OO interface. But it is
not always the real world. For example, if you want to add a user to the
operating system or delete a file from the system, do you care much about
the component models of operating systems, users, files, securities, or
something else? Usually not. I prefer taking it as a simple action
to the methods of complicated object components. For another example, if
you are going to a city in another country for sight-seeing, what should
you do? You may prepare money, get visa, buy airline tickets, and reserve
hotel. What I have said is just a process or an action list.
Anyhow we usually do not want to go deep into all object components. We
only want to use a few of their functions. At this time, I think it is
better to describe these things as actions of a process rather than methods
of a lot of object components. In other words, we only need an activated
Process Oriented Interface which has no relationship with any component
models.So, what is the so called "Action"? Action
is a clear defined task of a clear defined Process. For examples,
a shell command is likely an Action, which may be executed on UNIX,
Linux, Windows, or even executed cross different systems. A SQL command
is also an Action, which can be run on any relational database or a non
relational database supporting SQL, or even cross a lot of databases. To
get data from a registry is an Action, too, which can worked on any kind
of registries. Action is different from the Method of an OO interface for
the following reasons:
-
Action acts as a major role of a Process Oriented Interface (also
known as Action Based Interface), which does not belongs to any
object components.
-
Action needs more expressive definitions than OO method.
-
Action has more polymorphism features than OO method.
Now I have introduced a new conception named "Process Oriented Interface".
Process Oriented Interface uses actions to describe, define and implement
the process provided by a service vendor. There's not an object or class
behind the Process Oriented Interface. But Process Oriented Interface also
has its own lifecycle. The lifecycle conception in OO is related with an
instance of a class or object. According to the Process Oriented Interface,
the lifecycle begins at the time when the interface is activated,
ends at the time when the interface is deactivated.Another point
of Process Oriented Interface is that sometimes we can find actions of
different hierarchies. For example, if we define sight-seeing process as
a Process Oriented Interface, to reserve hotel will be an Action of that
interface, and to check hotel list is only a sub-step of to reserve hotel.
So we can define a sub-interface named "reserving hotel" which has an action
named "checking hotel list".
OK, by now, I can explain how to define a Process Oriented Interface:
-
After analyze the service provided by a vendor, if you find a series of
Actions (Process) of the same hierarchy, you may define a Process
Oriented Interface including all of these Actions.
-
The lifecycle of a Process Oriented Interface begins at the time
when the interface is activated, ends at the time when the interface is
deactivated.
-
If one "Action" of a Process Oriented Interface can be defined as a sub-process,
we can also define a sub-interface for it. When the parent interface
is deactivated, all of its sub-interfaces should also be deactivated automatically.
-
There's always an indicator named "Status" inside Process Oriented
Interface, which indicates the current state of the process. Usually only
Actions within the interface can change this "Status". So the Process Oriented
Interface can be treated as a state machine triggered by its Actions.
In the following chapters I will explain in detail that why Process Oriented
Interface is a good choice for us to construct excellent application interfaces.
Regular Statement String (RSS) and Regular Statement
String Interface (RSSI)
In last chapter, we know that the Actions of a Process Oriented Interface
need more expressive definitions and have more polymorphism features. So,
I invented a special format string named Regular Statement String
(RSS) in order to achieve these goals. Process Oriented Interface
by RSS is accordingly named Regular Statement String Interface
(RSSI).
So what is RSS? RSS is a simple but powerful container to maintain keys
and values used for an Action. You can learn more detail information of
RSS in the chapter "Inside RSS". You can
use almost any programming language to build server and client applications
with RSSI. I have C, Java and COM samples to show you how easy and simple
it is done. Perhaps RSSI is the simplest way to write the most flexible
applications. Following is my description for RSSI:
-
RSSI is the RSS function model used to describe a Process Oriented Interface,
A RSSI invocation is an Action of the interface. Application which provides
RSSI service is named RSSI server.
-
There's only one simple and standard entry in RSSI server. All data of
interaction between the client and server are kept in RSS.
-
There must be an Interface Definition Manual for each RSSI server
application. The Manual defines all Actions with its input and output keys.
The Interface Definition Manual plays the role of IDL files in CORBA and
COM applications. Except that it is much more flexible.
Development with RSS is very easy. Following is a sample showing how to
take an Action named "LocateNode" of a RSSI server to get the node name
from a XML document (Written in Java):
Rsst1.KeyPut "Path", "Helping/Jobs/Update/Salary"
Rsst1.CallRssi( "LocateNode" );
System.out.println( "The name is: " + new String( Rsst1.KeyGet("Name") ) );
Process Oriented Interface vs. Object Oriented Interface
OO Interface is widely used in software industry in recent years. It is
very successful to describe a complex system and build reusable code. But
OO is not cure-all as I explained in the RSS document. I invent Process
Oriented Interface (POI) in order to find an easy way to describe a process
system with clear action flow and system state. The technology is named
RSS (Regular Statement String) and RSSI (Regular Statement String Interface).
Now I will simply compare OO with POI/RSSI in different facets.
1. POI/RSSI is more expressive and easier to learn than OO.
POI/RSSI is much easier to understand because:
-
POI/RSSI is more like the real world because usually we just want to do
something rather than to learn the detail.
-
POI/RSSI can always tell you what it is doing through action names and
key names. It's hardly to know the meaning of the parameters of an OO method.
-
POI/RSSI has the same style. You will never be puzzled by diverse classes,
interfaces and types.
You can always use much less time to learn RSSI than other application
interfaces which can significantly increase productivity.
2. POI/RSSI has the best encapsulation and is most flexible.
Encapsulation is very important to show a tidy interface to the user.
Good encapsulation is essential to upgrade, customize and standardize an
interface. Good encapsulation is also helpful to portability. The reasons
are the same one. If you have too many unnecessary things opened to user,
to continuously support these things will be burdensome, so that to make
a change will be more difficult.
POI/RSSI has the best encapsulation I have seen before. There are no
structures, classes, predefined types, and specially implementations in
POI/RSSI definition manuals. The only entry in POI/RSSI is universal. All
implementations are hidden. POI/RSSI client can hardly break into the server
implementation. So POI/RSSI is very easy to upgrade, migrate, customize
and standardize. The Interface Definition Manual has good portability for
the same reason. It means you can easily write cross-platform and cross-language
applications based on POI/RSSI. POI/RSSI is also fit for team development
and application integration because of good encapsulation. If you want
to upgrade your POI/RSSI, you won't worry about the compatibility. RSS
provide a lot of features such multi-values and multi-levels.
On the contrary, OO is not so flexible. To change or upgrade an OO interface
is always a boring thing.
3. POI/RSSI is real language neutral.
Since POI/RSSI requires only one simple and universal function entry,
RSSI can be implemented with any programming language. I have already written
RSSI server and client applications with C, Java and Visual Basic with
ease and fun.
4. OO does better in inheritance.
Inheritance is very useful to code reuse. OO languages such as C++
and Java do well in this technique. You can declare one POI/RSSI to inherit
another POI/RSSI, or one POI/RSSI fully compatible with another POI/RSSI.
You may use the source code of the parent POI/RSSI, or only use the binary
code of the parent POI, or write a completely new implementation. This
is the free style inheritance of POI/RSSI. However I believe the inheritance
of OO languages are more powerful in general because there are more features.
5. OO does better in resource management.
Resource such as memory space and handles are always related with objects.
So it's more difficult to use POI/RSSI than OO for resource management.
6. OO does better in constructing objects.
If what you want to do is not to complete a process, but to construct
objects. OO is the right way.
So in my prospect, Process Oriented Interface or RSSI is of great benefit
to tremendous applications such as end user applications, system management
applications, application integration and middleware.
RSSI Programming Infrastructure
Development with RSSI is composed of three steps at least:
-
Interface Analysis. It's to find out the feasibility to use one or a number
of Process Oriented Interface(s)/sub-interface(s) to describe the application
system, and the relationship of these interface(s)/sub-interface(s). Usually
we should make clear the Status we may use inside the interfaces.
-
Action Definition. It's to write the Interface Definition Manual for each
interface including Actions, Status and Return Code definitions.
-
Implementation. It's to write the implementation code for RSSI server.
I have mentioned that the all RSSI server has only one exported function
as its entry, which has two arguments. One argument is RSST, a standard
structure holding RSS. The other argument is the name of the Action. You
can write RSSI server and client programs with C, Java, or Visual Basic.There
are two conventional Actions in each RSSI: "Activate" and”Deactivate".
-
The first Action should be "Activate", which will initialize current
RSSI and an inside handle. Usually the handle is a pointer to an internal
used RSST which hold the real life span of the current RSSI. At the end
of this Action, it will change the Status of the RSSI from 0 to 1 (RSS_STATUS_START).
-
The last Action should be "Deactivate", which will end current RSSI
and free all resource allocated by the RSSI. That is to say, the RSSI handle
will be closed in this Action. The Status of RSSI changes to 0.
-
Some Actions do not care about the Status of RSSI. These Actions can be
run at any time. These Actions are called static Actions.
Most of the Actions require the RSSI Handle, which is an integer,
and in fact it is the pointer to the internal used RSST at server side.
This handle is allocated in Action "Activate", and released in Action "Deactivate".
RSSI Handle is essential to hold data during the lifecycle of RSSI Process
(form Action "Activate" to Action "Deactivate").Each Action must have a
Return Code (named RtCode) to indicate its completion status.