Re: [service-orientated-architecture] Polymorphic Services

[Nick Gall]

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]> 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 <[EMAIL PROTECTED]> 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

__,_._,___