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

Works for me.

arkin

Champion, Mike wrote:

>
>  
>
>>-----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 15:55:27 UTC