[Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

We need it because we need to maintain that separation of services even for service characteristics that do not need to be exposed to an actual REST implementation. It is this conceptual separation that keeps the "post routing service" separable from the "admin-by-mail service" and the "mailing list archive service".

Remember that, as Barry has acknowledged, the IXxx interfaces are an implementation-level interface.
If we don't maintain the separation at the "service level", interactions between the services which happen to share a common implementation interface MIGHT end up bypassing the service level by using capabilities which are available in the implementation level, but not in the service level. If they do so, it will not be possible to provide an alternate implementation of one of those services without also having to provide the alternate for the other service.

At present, there is  only an implementation level specification of the interface between the "user service" and the other services presently in "core". In order to create an alternate implementation of the "user service", it will be necessary to unravel these services and assure that they are not interacting via any method which is not reflected in the service level.

We should not be required to repeat this in the future. Therefore, we need to have a service level interface for ALL inter-service interactions, even if we do not require the RESTful implementation of those interactions at this time.


On Jul 14, 2012, at 12:00 AM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> I think that you have missed a level of abstraction.
> 
> Why do we need it?  AFAICS, at this point we have a bunch of services
> that need to be specified somehow.  We *need* a RESTful interface for
> some functions because they make the most sense if accessed remotely,
> and there doesn't seem to be a good reason to go beyond HTTP and
> specify individual transport protocols for these remote services.

Perhaps you still fail to understand what I mean by a service-level interface.

The service-level interface describes the functional interaction between objects and controllers.
It deals with conceptual objects and operations. It is not language or protocol specific.

ALL transport protocols are below this level.

Consider what is involved when someone wants to change a password:

The storage of the passwords and the later verification of them is handled by the "user service".
(That is a statement is a part of the service-level specification.)

There is another service, which is processing the request (hands waived about how we get to that point in the data flow, but it is in a service other than the user service). How does it accomplish its task?

For discussion, I will call this service the "admin service". After doing whatever it needs to do to decide that it is ready,

The (admin) service presents a "user identifier" and the "new password" to the "user service" in a "request to change password".
This is another service level specification.

Note that there is no mention of REST interface, or python objects, etc.

It is an implementation detail as to the format in which the "user identifier" is presented. It might be a string with the user's Id, a python object of class IUser, etc. In fact, the implementation MAY provide multiple signatures for this action. The important thing is that the ADMIN service DOES NOT "change the password field in the user object".

"change the password field in the user object" might be an internal method within the user service, but it is not visible to the admin object.

> Given that, and that REST is a pretty severe restriction, it seems
> likely to me that if we actually need to go beyond REST for
> performance reasons (eg), that can easily enough be done later.  We
> may as well specify using REST now, and have everything target that
> protocol until we need something more powerful or efficient.

Conceptually, I agree. All along, I have been advocating that the service level interface be organized in a manner which would allow it to be implemented in a RESTful manner.

I suspect that we will find some inefficiencies that would result if every operation were actually carried out in that manner and, as a result, in a particular implementation, we will group some services and allow them to bypass the strict requirement of interacting with each other only through the methods exposed in the service-level interface. However, in doing so, we must acknowledge that any replacement for one service of that implementation will have to replace the entire service group.

Richard