W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2006

RE: "interface" attribute info item on service component

From: Rogers, Tony <Tony.Rogers@ca.com>
Date: Tue, 30 May 2006 14:26:33 +1000
Message-ID: <BEE2BD647C052D4FA59B42F5E2D946B317B51E@AUSYMS12.ca.com>
To: "Ramkumar Menon" <ramkumar.menon@gmail.com>, "Arthur Ryman" <ryman@ca.ibm.com>
Cc: <www-ws-desc@w3.org>, <www-ws-desc-request@w3.org>
As far as the bindings referenced by endpoints, no, these need not refer to interfaces. If you read about "reusable" bindings in the Primer you'll see that there's a good case for using bindings that do not refer to interfaces - that's what Arthur was referring to by "generic" bindings.
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com
co-chair UDDI TC at OASIS
co-chair WS-Desc WG at W3C

________________________________

From: www-ws-desc-request@w3.org on behalf of Ramkumar Menon
Sent: Tue 30-May-06 13:41
To: Arthur Ryman
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: "interface" attribute info item on service component


Hi Arthur,
 
Thanks for the detailed explanation.
Maybe I was not clear in my question (1) .
I was explicitly referring to the "interface" attribute on the <service> nodes. Woudnt the interfaces that are referred to as attributes on the <service> nodes need to have atleast one operation within them, either declared / inherited ? Would it make sense to explicitly state this in the spec ? 
Similarly, for the second question, I was referring to those bindings that are referred to from within the <endpoint> node as an attribute - wdnt these referred bindings need to be referring to an interface mandatorily ? Again, if it makes sense, would it better if we explicitly state ithis in the spec ? 
 
I would also appreciate your thoughts on point (3).
 
Thanks again!
 
rgds,
Ram

 
On 5/29/06, Arthur Ryman <ryman@ca.ibm.com> wrote: 


	Ram, 
	
	It might be useful to have an interface that just defined faults, so -1 to requiring one or more operations. 
	
	An endpoint refers to a single binding. If the binding refers to an interface, it must be the same as the service's interface. Note that generic "interfaceless" bindings are possible. 
	
	Arthur Ryman,
	IBM Software Group, Rational Division
	
	blog: http://ryman.eclipsedevelopersjournal.com/ 
	phone: +1-905-413-3077, TL 969-3077
	assistant: +1-905-413-2411, TL 969-2411
	fax: +1-905-413-4920, TL 969-4920
	mobile: +1-416-939-5063, text: 4169395063@fido.ca 
	
	
	
"Ramkumar Menon" <ramkumar.menon@gmail.com > 
Sent by: www-ws-desc-request@w3.org 

05/23/2006 02:36 PM 

To
www-ws-desc@w3.org 
cc
Subject
"interface" attribute info item on service component	

		


	
	
	
	
	Three fundamental questions.
	
	Would it be useful to add a clause for the <service> component stating
	The "interface" attribute information item should point to an 
	interface that has non zero number of "operation" element information
	items within it.
	If not, we cd as well have service components that could possible be
	empty, and allow them to extend other service components, reflecting 
	the same semantics we have defined for interface inheritance -
	considering that one service component is related to exactly one
	interface.
	
	Am I right if I state that if all "binding" attribute info items that 
	had been defined on the endpoint node should have been associated with
	an  "interface" attribute information item? What does it mean to be
	otherwise ?
	
	Moreover, if the service component has an interface attribute info 
	item that extends from two other interfaces, can the endpoint defined
	within it refer to bindings that were defined for the parent
	interfaces ? If yes/no, should this be reflected in the core language
	spec ?
	
	rgds,
	Ram
	-- 
	Shift to the left, shift to the right!
	Pop up, push down, byte, byte, byte!
	
	-Ramkumar Menon
	A typical Macroprocessor
	
	
	




-- 
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

-Ramkumar Menon
A typical Macroprocessor 
Received on Tuesday, 30 May 2006 04:30:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:40 GMT