Re: [DAML-S] About grounding of services

I see that there is a diference in my approach with the approach followed by 
Web Services.  In my approach there are agents running in user's context 
which provide some services.  The description of the agents and the services 
provided by them is published to a distributed context management service. 
The user can choose from among the available services and make use of them 
without seeing the agents.  The system, however, knows the agent profiles 
and delegates tasks to them on behalf of the user. So, it must know which 
grounding is supported by the agent for which service.  I am providing a 
FIPA grounding in my paper for that purpose.  Hence, my few points below 
must be seen in the light of this approach.

David Martin wrote:
 >
 > Saied Tazari wrote:
 > .
 > .
 >>Is it right that a concrete SW component may provide several services?  In
 >>my opinion, yes! (e.g.
 >>http://www.daml.org/services/daml-s/0.9/Service.daml#provides has no
 >>cardinality restrictions)
 >
 > Thanks for your comments.
 >
 > I certainly agree that a SW component may provide several Services.  But I
 > should point out, by way of clarification, the domain of the DAML-S
 > "provides" property is "rdfs:Resource", which doesn't necessarily indicate
 > a concrete SW component. We've never made it precisely clear what kind of
 > "resource" "provides" a service - and I don't think it's terribly
 > important that we do make it clear.  The original idea was just to be able
 > to associate a service with some web site that hosts the service.

I see that it was confusing to suggest "SW components provide services"; the 
more correct statement is "SW components implement services" (although it is
not wrong to define a new class that adopts the DAML-S "provides" property, 
as its domain is "rdfs:Resource").  So, I agree that web sites provide 
services by hosting concrete SW components implementing them.

 >>Is that right that service groundings are supported by concrete SW
 >>components and not by the service itself?  In my opinion, yes!
 >
 > I get the impression you're trying to ensure that the term "supports" is
 > used correctly; that is, the use is consistent with English usage.   If
 > so, I'm somewhat sympathetic.  That is, I agree perhaps the word "support"
 > isn't a perfect choice to indicate the relationship between a Service and
 > one of its groundings.  However, I'd be more inclined just to change the
 > name of the property, rather than introduce SWComponent into the ontology,
 > as you propose below.  I don't think there's any need to refer to the
 > concrete software components that implement the Services.  In fact, I
 > think it goes against the spirit of Web services.  That is, the concrete
 > software components should be invisible; those are private,
 > system-specific implementation details that users of the service don't
 > need to know about.

I agree that users of the service don't need to know about the concrete SW 
component, but the point is that after selecting a service (in my approach 
the matchmaking is performed by a broker agent that shows the list of 
matched services to the user) a request (received by the broker agent) must 
be converted to a request message to be routed to a concrete SW component 
(or an agent as a special type of SW components) in a way that is convenient 
for the receiver.  So, it must be decidable for the broker to find a SW 
component that implements the service and find out which groundings are 
supported for the service by that SW component.

 > Also, the purpose of the service profile is largely to support the
 > construction of advertisements for a service - and I think it's clear you
 > might want to have multiple different advertisements for the same service.
 > Therefore, I don't think it's helpful to merge ServiceProfile with
 > Service.

In my approach, because the class 'SWComponent' (instead of 'Service') 
adopts the property 'supports' with a service grounding as the range, the 
service will have only to point to its profile and its service model.  So, I 
thought, the content of service profile may be given directly in the service 
description.  Even if there are several advertisements of the service, we 
only need to repeat the URI reference of the service model (and not more) 
which is anyway "constant", since each service has only one service model.

Regards,

-- Saied Tazari

 > Regards,
 > David Martin
 >
 >>If we accept my answers to the above questions, it seems to me that we'd
 >>better to add a new class called SWComponent (or ServiceProvider if it
 >>isn't confusing) that provides as many services as it likes, merge
 >>ServiceProfile and Service into one class called Service, and eliminate
 >>the properties 'presentedBy' and 'presents'.  Then, we must redefine
 >>'supports' with SWComponent as its domain and ServiceGrounding as its
 >>range and add a new property called
 >>theService/binds/enacts/utilizes/employs with ServiceGrounding as its
 >>domain and Service as its range.  The attached class diagram summarizes
 >>this idea putting aside many details, such as classes modeling the
 >>information about the code base of SWComponent and access rights.

Received on Friday, 23 May 2003 05:34:00 UTC