RE: Proposed WSA doc language from RE: Separate concepts for "service " and "targetResource?"

+1
 --katia

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Champion, Mike
Sent: Thursday, May 22, 2003 11:55 AM
To: www-ws-arch@w3.org
Subject: Proposed WSA doc language from RE: Separate concepts for
"service " and "targetResource?"





> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Thursday, May 22, 2003 11:04 AM
> To: Assaf Arkin
> Cc: www-ws-arch@w3.org
> Subject: RE: Separate concepts for "service" and
> "targetResource?" (was
> RE : /service/@targetResource ?)
>
>


> concept might be needed to express services aggregation. My
> question is: do we have to go through the trouble of
> identifying all these concepts, clarify their meaning, assign
> them URIs, etc, just for the purpose of expressing
> aggregations that in many cases are just application-specific?

No, but we do need (IMHO) to make sure that concepts in WSDL such as
targetResource (or whatever they end up calling it) map on to concepts in
WSA, or propose a better conceptual model to the WSD group that meets their
needs and ours.

It would be very useful to see some pictures of proposed UML or "spaghetti
diagram" models of this. Trying to say this in words, and consider this a
strawman proposal:


wsdwg:targetResource is more or less  the "service" concept which is
described in 2.2.31.  Tweaking the words (I can't remember if we came up
with agreed upon wording
in Rennes), and inventing the label "deployedService" as a placeholder:

===================================================
A deployedService is a (2.2.1 Agent) that corresponds to a WSDL 1.2
targetResource and thus actually implements a Web service or Web service
interface to an existing software system.

2.2.31.2 Relationships to other elements
a deployedService implements
one or more Operations

a deployedService has
a service description that defines its interface to the world

a deployedService is deployed by a service provider.


a deployedService has a URI corresponding to the wsdl:targetResource URI in
its description.

a deployedService has semantics, explicitly described by a semantic
description language or implicitly defined by various design documents and
implementation code.

a deployedService is invoked by
exchanging messages
======================================================


A couple of points reponding to earlier critiques of similar ideas:

-- The "printer" example is a good one, but let's not get hung up on the
idea that the "objects" (physical or software) behind the deployedService
can be easily and uniquely identified.  Sure, a printer could be given a
URN, or (God help us) an http URI along the line's of Dan Connolly's
wretched car :-).  On the other hand, the deployedService may sit in front
of a legacy system (a monolithic COBOL program, perhaps) that has no
"objects" corresponding to the service that the deployedService performs.
That is, the deployedService may use the APIs and data structures of the
legacy program to present the illusion that there is a "purchase order
processing service" even though that just one of a bazillion tangled up
things that the program does.

-- the "don't want to get nice REST Resources covered with WSDL goo"
response from someone misses the point.  The agent implementing the
WSDL-defined interface *is* the only meaningful resource in a situation such
as the one above.

Received on Thursday, 22 May 2003 14:39:31 UTC