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:
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:

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:
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:
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:
  1. 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.
  2. Action Definition. It's to write the Interface Definition Manual for each interface including Actions, Status and Return Code definitions.
  3. 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".
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.