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)
• Regular Statement String (RSS) and Regular Statement String Interface (RSSI)
• Process Oriented Interface vs. Object Oriented Interface
• RSSI Programming Infrastructure
• Learn From RSS Samples Step By Step
• Inside RSS

Process Oriented Interface (POI)

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.

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.

 

Regular Statement String (RSS) and Regular Statement String Interface (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.

 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

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.

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

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.

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.

Each Action must have a Return Code (named RtCode) to indicate its completion status.