Ok Nick, For me REST is polymorphic but I don't think it is a good description of what REST is because the fundamental particularity in REST is that there is a limited number of generic (should I say standard?) operations. I think that is more meaningful than "polymorphic".
Next to this, with the OO background I have, I know 2 concrete use cases of polymorphism: 1) Method overriding 2) Abstract classes I think the Abstract class polymorphism does not make any sense in a SOA for messages. The reason is that the full message structure should be contractually defined. In that context, abstracting a message does not make any sense, does it? If I look now at the method overriding, it means we could invoke a single operation on a single service with several different messages. I think WSDL does not support that, am I right? Robin --- In [email protected], "Nick Gall" <[EMAIL PROTECTED]> wrote: > > Your distinction between polymorphic and generic services makes no sense to > me. Please elaborate. Perhaps a few examples of each. > > REST is about a "is about a limited set of generic services". Yes. And in > this context, its about a limited number of polymorphic services. Or if you > prefer, about a limited number of > overloaded<http://en.wikipedia.org/wiki/Operator_overloading>services. > > -- Nick Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
