Re: [service-orientated-architecture] Polymorphic Services

[Todd Biske]

As you describe, polymorphism isn't something that is easily explained.   I, too, went to the Wikipedia definition to think this one through.  I also went to the first blog you referenced, where the author describers polymorphism as "a geeky was of saying that different nouns can have the same verb applied to them."  Using this definition, you could say that the combination of REST services are polymorphic.  You can not, however, say that an individual service is polymorphic.  Here you can only say that an individual service adheres to the universal interface.   Back to Jeff's original question... Is it a good idea to have a polymorphic service, which I interpret as having an overloaded operation?  I have no issues with this, so long as the interface is explicit.  If the interface is explicit, then the polymorphic context should be implied in the message.  I've been racking my brain to come up with a scenario where placing it in the header would make sense, and haven't come up with any.  I usually shoot it down because I feel like the service consumer would need to know too much about internal decisions that the provider would be making. -tb On Sep 10, 2006, at 1:15 PM, Nick Gall wrote: Anne, I'm not following your distinction at all. [To grossly oversimplify...] If you CREATE an object, you'll always get a reference to an object. If you SERIALIZE an object, you'll always get a representation of the object. If you PRINT an object, you'll always get a printed representation of the object. If you DELETE an object, you'll always delete the object. CREATE, SERIALIZE, PRINT, and DELETE are paradigmatic examples of OO polymorphic methods. So what's different about REST's "uniform interface" generally, or HTTP verbs specifically? Your statement that "Each resource might exhibit slightly different behavior, but the behavior of a particular resource (identified by its URI) should not change" doesn't parse for me. Given how complex the concept of polymorphism is (see this Wikipedia entry), could you elaborate a bit? BTW, The equivalence of the REST uniform interface with OO polymorphism is pretty well accepted in the blogosphere. See these examples: http://naeblis.cx/articles/2004/12/12/rest-to-my-wife http://lists.xml.org/archives/xml-dev/200202/msg00607.html http://lambda-the-ultimate.org/node/1290#comment-14441 http://www.dehora.net/journal/2002/12/scott_sterling_on_versioning.html http://soundadvice.id.au/blog/2006/07/22#definingOO http://www.cs.helsinki.fi/u/chande/courses/cs/MWS/reports/MichaelPrzybilski_REST.pdf http://home.ccil.org/~cowan/restws.pdf I'm surprised you don't agree. -- Nick On 9/10/06, Anne Thomas Manes <[EMAIL PROTECTED]com> wrote: There's a difference between service polymorphism and a uniform interface. REST has a uniform interface, but it's not polymorphic. If you request a GET on a resource, you will always get the resource representation. If you request a PUT on a resource, you will always replace the resource representation. If you request a POST on a resource, you will always post new information to the resource. If you request a DELETE on a resource, you will always delete the resouce representation. Each resource might exhibit slightly different behavior, but the behavior of a particular resource (identified by its URI) should not change. Now -- if you are tunneling an RPC through a POST, then you can implement support for polymorphism -- requesting a variety of operations based on the type or content of information being posted -- but then you are violating REST principles. Anne On 9/10/06, Steve Jones <jones.steveg@gmail.com> wrote: > > On 10/09/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > > > > Steve Jones wrote: > > > > > > What do you mean by a polymorphic service? One that can handle > > > multiple message types, or one that is polymorphic in terms of the > > > contract it offers to consumers. > > > > > > If its the former then I don't see why not, if the service is > > > something like "DataCleansing" and you can pass in multiple different > > > data types for cleansing and it returns the cleansed data. > > > > > > If its the later then I think it might get a little tricky if the > > > service changes its behaviour based on what it is passed! > > > > > > Isn't this what REST does? > > > > > Oh boy, REST claims polymorphism. I thought REST stressed the > importance of the URI? Which was resource specific? This puts it in > the first case (which WS can certainly do as well) rather than the > later (which WS and REST can both do but I don't think its a bad > idea). > > Its what lots of MOM systems used to do, and was one of the reasons > they got complex as you had lots of individual message types that the > broker in the middle determined what should be done where, so the > whole MOM was ineffect polymorphic based on message type. > > > > -- Nick Gall Phone: +1.781.608.5871 AOL IM: Nicholas Gall Yahoo IM: nick_gall_1117 MSN IM: (same as email) Google Talk: (same as email) Email: nick.gall AT-SIGN gmail DOT com Weblog: http://ironick.typepad.com/ironick/ Furl: http://www.furl.net/members/ngall __._,_.___ SPONSORED LINKS Computer software program Computer software spy Computer job Database software Discount computer software Your email settings: Individual Email|Traditional Change settings via the Web (Yahoo! ID required) Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe __,_._,___