[DotGNU]The service level

[Peter Minten]

Hi folks,

I did some thinking on the design of DotGNU on the service level. Following a
slightly Goldwater like approach I came to the following idea.

--

Every function, procedure and method which can be called from the outside is
called a service method. This is comparable to a Goldwater Service (GWService).

Service methods are grouped together into a service. This is a bit comparable to
a Goldwater Server (GWServer).

Services can use sessions. Sessions are a way of identifying a user between 2
calls with a connection-less protocol. I'll explain this in depth later.
Goldwater doesn't have an equivalent part.

Services can be hidden from the user by encapsulating services. I'll explain
these more in depth later too. Goldwater does not have an equivalent part.

--

A problem with protocols like XML-RPC is that they are connectionless. It's hard
to know who a user is unless they identify every call again. Also it's hard to
store large amounts of data needed internally between calls since every call
appears like from a new user so that the user has to send all data for a call
over the network.

The solution to this is using sessions. A session is basically a way to remember
a user during a working session of the user on the service. To the user a
session is mostly transparent, the usual work needed is done by the DotGNU
software.

A session starts by logging in with certain credentials (mostly using a DotGNU
VI compatible system) and ends by logging out. During work a session handle is
send over for every call to a service method. On the server side the handle can
be used to store user data, simply create a hash with as key the handle and as
value a pointer to the data of the user. This way you can call service method A
which creates a complex structure and delivers an error code and service method
B which uses the structure, without having to send the structure along. Service
method A simply stores the structure in a hash with the key as the value of
session handle, and session B gets the structure from the hash.

Sessions also allow bookkeeping programs to run to charge the user for every
call made or time being logged in or whatever.

--

Encapsulating services are a solution to a common problem: access levels. Say
you have 2 persons working with a webservice component doing the personel
administration, the first one (say Alice) has full access except for the payment
data, the second one (say Bob) only has access to basic info (like name and
address) and payment data. Alice and Bob use the same software however and for
paranoid security considerations no unnecessary data should be send over the
network. 

The way to tackle this in the service level model is to first create two
services, say levelA (for Alice) and levelB (for Bob). Since service methods are
not directly connected to services levelA and levelB can use the same service
methods (and/or different service methods). The services are not directly
accessible by users, but have to be called using a frontdoor service (the
encapsulating service). The frontdoor service first checks by credentials the
access level of the user and then pretends to be the service intended for the
user. The important part is that after login the frontdoor service simply
becomes an interface for the right service. The advantage here is that the
frontdoor is completely invisible to the user.

--

Encrypted service calls are important, you don't want your opponents to see
secret data when it is send to a remote webservice for processing. Some
protocols like XML-RPC don't have support for encryption. This can be
circumvented however. The idea is that instead of making a direct call to a
service method you call a special method with 2 arguments: the session handle
and the encrypted real method call. The special method then looks up who you are
using the session handle and decrypts the message, after that the real call is
send through internally to the service method with one extra argument at the
beginning: the session handle.

Schematically it looks like this:
+------+  special_method(session id, encrypted call)  +----------------+
| user | -------------------------------------------> | special method |
+------+                                              +----------------+
                                                              |
                    service_method(session id, rest of args)  |
                                                              V
                                                      +----------------+
                                                      | service method |
                                                      +----------------+

The return from the service method is then wrapped in the special method into a
single encrypted binary value.

--

Greetings,

Peter