FW: Picking up the "WSDL conceptual model" discussion

[copy of my response from the admin list]

-----Original Message-----
From: Ugo Corda 
Sent: Tuesday, June 10, 2003 12:44 PM
To: Mike Champion; www-ws-arch@w3.org
Subject: RE: Picking up the "WSDL conceptual model" discussion



If the real question here is about which ones of these concepts need an associated URI, I would like to take a minimalist approach and only list those concepts for which I can think of an actual use for the corresponding URI. So my list would be something like:

F - obviously I need a URI to invoke the endpoint
E - the URI comes out automatically from the fragment identifier mechanism applied to the WSDL document, and it's useful to have a unique identifier for a particular WSDL service independently from the actual binding used (i.e. specific endpoint)
G - this would be required in the context of a routing mechanism
D - since it's required by the latest WSDL spec (but the discussion within WSD is still in progress, so it's not completely certain that in the end this will actually be required)

For all the remaining cases, I have a hard time seeing how the definition of an associated URI would help me in any way. (I would of course reconsider my position if some useful use cases came up that required the use of such URIs).

Ugo
 

> -----Original Message-----
> From: Mike Champion [mailto:mike.champion@softwareag-usa.com]
> Sent: Tuesday, June 10, 2003 11:35 AM
> To: www-ws-arch@w3.org
> Subject: Picking up the "WSDL conceptual model" discussion
> 
> 
> 
> We were having a good discussion of the "UML diagram" of the WSDL 
> conceptual model on the telcon 2 weeks ago.
> http://www.w3.org/2002/ws/arch/3/05/2003-05-29-ws-arch.htm
> 
> Toward the end, Chris said (as I scribed it anyway) "we need 
> to identify 
> what needs to be identified ... one is clearly wsdl:service, 
> but we need to 
> identify other things, like deployed service, and sort out 
> which have which 
> URIs ... we may need to be able to identify SPECIFIC deployed 
> services, 
> having scenarios would help."
> 
> I'd like to see some discussion of:
> 
> - What needs to be identified (i.e., usefully has a separate 
> identity) 
> inside the little cloud we call "service".
> 
> - How do these abstractions relate to physical "things" like printers?
> 
> - How do these relate to the WSDL "targetResource" discussion?
> 
> Here's a strawman list of things we might want to identify:  
> Flame away!
> 
> A) The identifier of the unique object (physical or software 
> object with 
> identity) that the service operates on.  In the printer 
> example, it's a 
> physical printer.  In the ERP example, it's not clear.
> 
> B) The actual code that does something in the real world.  In 
> the printer 
> scenario, it's a printer driver.  In the ERP scenario, it's 
> the various 
> bits of code that handle the purchase order approval process. 
>  In general 
> this code will expose proprietary APIs to 3rd parties.  This 
> is what we 
> called the "turtle" in Rennes.
> 
> C) The code that implements the SOAP interface to B).  This 
> is what we 
> called the "agent" in Rennes.
> 
> D) The targetResource, whatever that URI in a wsdl:service 
> identifies.  It 
> may correspond to A), B) or C), or it may be an abstraction 
> that is useful 
> only in the context of a specific application.
> 
> E) A wsdl:service element
> 
> F) A wsdl:endpoint
> 
> G) A soap:ultimateReceiver (?)
> 
> H) a managed / deployed service from the management point of 
> view.  I think 
> this is probably equivalent to C) but I'm not sure.
> 
> 
> -- 
> Mike Champion
> 
>

Received on Wednesday, 11 June 2003 21:37:11 UTC