Re: granularity/definition of a "service"

Thanks for your replies. Pls find my comments inline.
----- Original Message -----
From: <Joachim.Peer@unisg.ch>
To: "Monika Solanki" <monika@dmu.ac.uk>
Cc: <public-sws-ig@w3.org>
Sent: Sunday, September 19, 2004 4:38 PM
Subject: Re: granularity/definition of a "service"


> >However can the fundamental operations of sending and receiving
> >messages that any service is suppose to perform, irrespective of
> >the core functionalities it offers, be classified as a "service"
> >at its lowest level of granularity?
>
> i think the answer is yes, under certain circumstances,  *if* you assume a
> layered model ( like the ISO-OSI model, the TCP/IP internet protocol stack
> for instance )
>
> * each layer in the model provides a "service" to the layer above it and
> each layer consumes a "service" from the layer below, ie. "vertical
> communication". For instance an FTP or SMTP server (vertically) consumes
> the "services" of its underlying TCP/IP implementation. (i.e. the
> networking functionality it provides)

Even in this case, the layers themselves  have certain well defined
functionalities, which are different from just communicating with each
other. These may not be externally exposed, however there sre atill known to
the entities consuming them. It is the functionality that a layer offers
that can be classified as a service and not the mechanism that the layers
used to communicate amongst themselves (shared variables or message
passing).

In my opinion to be classified as  a "service" within the paradigm of
service-oriented computing, a system  needs to have a defined objective,
more that just communicating with other systems/services, even at the lowest
level of granularity.

> * Then, there is also the "horizontal communication", which is the
> interaction between two different instances on the *same logical layer*
> (e.g. an FTP server and its client, or two SMTP servers, etc.).
>
> now, if we have a high level application A , that uses HTTP to send or
> receive messages, then we can say that this application consumes a service
> (from its own network stack) that allows it to send and receive HTTP
> messages (see below).
>
> However, if we consider the horizontal communication between the instances
> 1 and 2 on level 3 (where only the application protocol "proto A" is
> relevant), then the elementary HTTP send/receive functionalitiy becomes
> irrelevant and i would not see any use in explicitely modeling the HTTP
> funcationality on that level. Similarily, when we go another level higher
> in the model (above level 3),, then the HTTP send/receive operations are
> not relevant anymore even for vertical communication (because level 4
> would access level 3, not level 2 directly)
>
>
>        instance 1                               instance 2
>   +------------------+                      +-----------------+
> 3 | Application A    |      <-proto A->     | Application A   |
>   +------------------+                      +-----------------+
> 2 | HTTP             |       <-http->       | HTTP            |
>   +------------------+                      +-----------------+
> 1 | network stack    |  <-tcp, ip, ppp..->  | network stack   |
>   +------------------+----------------------+-----------------+
> 0 |                pysical transmission of BITs               |
>   +-----------------------------------------------------------+
>
>
> so in short, i would say, that it depends of the layer you are modeling
> and wether you are modeling the vertical or the horizontal communication
> protocol
>
> cheers,
> Joachim
>

Received on Sunday, 19 September 2004 16:59:34 UTC