Re: "interface" attribute info item on service component

Thanks Tony, Arthur. That clarifies things a lot.
regards,
Ram


On 5/29/06, Rogers, Tony <Tony.Rogers@ca.com> wrote:
>
>   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
>



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

-Ramkumar Menon
A typical Macroprocessor