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

_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Reply via email to