Subject: [P2PSIP] What is a Service?

From: Dean Willis <[email-masked]>
Date: Tue, 27 Feb 2007 16:10:07 -0600

Starting from Henry's request that P2PSIP differentiate between   
"service" and "data" models, we seem to have gotten a bit tangled up  
on the concept of "service".

An excellent discussion of the term, from the economic perspective,  
can be found at:

http://en.wikipedia.org/wiki/Service

A closer-to-home definition is that of a "Web Service":

http://en.wikipedia.org/wiki/Web_service

Henry, I believe, was attempting to use the term in a similar vein to  
"Web Service". He was proposing that the P2P lookup and routing  
functionality could be provided independently of the real-time call  
setup functionality. In other words, a "P2P service provider" would  
provide the distributed database, and we would just use the  
distributed database as-is to set up calls. We might need to define  
some new building blocks, but we should make use of the existing  
blocks where possible.

This is an example of what one might call a "Service Oriented  
Architecture". In this approach, an application loosely-couples  
various services, possibly adding new services to existing ones, in  
order to achieve the goal of the application. This application might  
then be exported as a "service".

But this raises questions. Does there need to be a standardized set  
of "services"? If so, which ones?

For example, is "voice mail" a service, and if so, does it need to be  
standardized?

I'd argue that the answer to both of the above is "probably not, at  
least for now". I'd much rather concentrate on the really reusable  
prices of functionality we've discussed -- like inserting a peer into  
an overlay and or routing a request between peers, as the "services"  
of interest.

--
Dean

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Feb 2007 17:08:24 -0600

On Feb 27, 2007, at 4:10 PM, Dean Willis wrote:

>  I'd much rather concentrate on the really reusable prices of  
> functionality we've discussed -- like inserting a peer into an  
> overlay and or routing a request between peers, as the "services"  
> of interest.

Of course, I meant "pieces of functionality". Not "prices". Although  
my therapist has asked me to discuss this slip in detail during my  
next session . . .

--
Dean

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 27 Feb 2007 15:53:48 -0800

Dean,

Thanks for keeping the topic alive (the interface to the DHT)!

Actually, going right to the original source would be better.
Please see:

OpenDHT: "A Public DHT Service and Its Uses" by S. Rhea et al., 

http://www.intel-research.net/Publications/Pittsburgh/092620050725_326.p
df 

Section 3 on the Interface (to the DHT) says it all.

The 3rd interface, the one that provides access to the DHT routing is
also very interesting, for example to provide large scale application
layer multicast for very large conferences.

Thanks again,

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 4:10 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] What is a Service?

--
Dean

---

From: Peili Xu <[email-masked]>
Date: Thu, 01 Mar 2007 10:24:32 +0800

I can't agree more with Dean. 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, February 28, 2007 6:10 AM
To: P2PSIP Mailing List
Subject: [P2PSIP] What is a Service?

Starting from Henry's request that P2PSIP differentiate between   
"service" and "data" models, we seem to have gotten a bit tangled up on the
concept of "service".

An excellent discussion of the term, from the economic perspective, can be
found at:

Henry, I believe, was attempting to use the term in a similar vein to "Web
Service". He was proposing that the P2P lookup and routing functionality
could be provided independently of the real-time call setup functionality.
In other words, a "P2P service provider" would provide the distributed
database, and we would just use the distributed database as-is to set up
calls. We might need to define some new building blocks, but we should make
use of the existing blocks where possible.

This is an example of what one might call a "Service Oriented Architecture".
In this approach, an application loosely-couples various services, possibly
adding new services to existing ones, in order to achieve the goal of the
application. This application might then be exported as a "service".

But this raises questions. Does there need to be a standardized set of
"services"? If so, which ones?

I'd argue that the answer to both of the above is "probably not, at least
for now". I'd much rather concentrate on the really reusable prices of
functionality we've discussed -- like inserting a peer into an overlay and
or routing a request between peers, as the "services"  
of interest.

--
Dean