Re: [service-orientated-architecture] Polymorphic Services

[Nick Gall]

"In a REST scenario, you will also have multiple resources that all
implement POST and do different things, both based on their internal
state as well as based on the data they're passed. I don't think this
has got much to do with polymorphism, though."

Stefan, I think you overstate the case for how similarly two objects must behave wrt a overloaded operation. Here's an excerpt from Wikipedia's operator overloading entry:

======================================

Criticisms

Operator overloading has been criticized because it allows programmers to give operators completely different functionality depending on the types of their operands. C++'s usage of the << operator is an example of this problem. The _expression_

a << 1

will return twice the value of a if a is an integer variable, but if a is an output stream instead this will write "1" to it. Because operator overloading allows the original programmer to change the usual semantics of an operator and to catch any subsequent programmers by surprise, it is usually considered good practice to use operator overloading with care.

The common reply to this criticism, given by programmers who favor operator overloading, is that the same argument applies to function overloading as well. Further, even in absence of overloading, a programmer can define a function to do something totally different from what would be expected from its name. An issue that remains is that languages such as C++ provide a limited set of operator symbols, thus removing from programmers the option of choosing a more suitable operator symbol for their new operation.

Another, more subtle issue with operators is that certain rules from mathematics can be expected or unintentionally assumed. For example, a + b usually (but not always) means the same as b + a, but "school" + "bag" is different from "bag" + "school" in languages that overload + for string concatenation. The same kind of difference exists in the world of mathematics, where matrix operations are not commutative.

======================================

So the polymorphic "<<" does something very different depending on the target object. The same is true of an operator like "+". Sometimes it means add, sometimes catenate, sometimes set union, etc.

So in REST, the operators always share some minimal semantics, eg, it would be a violation of HTTP verbs to have GET change the state of the resource. But all the other verbs can have, in addition to their shared semantics, widely different side effects. But how is this different from how widely different the side effects of constructors can be, even though they are all overloaded on the CREATE verb?

I do agree that given the murkiness of the issues involved, we should now wait for Jeff to clarify his orginal question.

On 9/11/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote:

  



    

            
The essential aspect of polymorphism is that one can write an  

algorithm that walks equally well for all possible subtypes (in a  

typed language, that is).



For example (some pseudo-syntax)



rotateAllShapes(Shape[] shapes)

    foreach (s: shapes)

       s.rotate()



This makes sense for REST resources, too:



deleteAllResources(Resource[] r)

    foreach (r: resources)

       r.DELETE()



In both cases, the call is dispatched based on the type - all shapes  

implement rotate(), all resources implement delete(). And in both  

cases I'm operating on instances.



In a REST scenario, you will also have multiple resources that all  

implement POST and do different things, both based on their internal  

state as well as based on the data they're passed. I don't think this  

has got much to do with polymorphism, though.



With services, you usually do not model identity the same way - i.e.,  

the service acts as a facade without identity. Of course one could  

create a set of services - say, OrderManagement, Archiving, Billing -  

and have them implement the same service operation (e.g. "processOrder 

()". While this is possible, I haven't seen it in practice. I can't  

think of an obvious example where you'd write a generic algorithm  

that would act on a set of services, for example.



Now to address Jeff's original questions:



An alternative would be to follow a purely message-driven approach  

and have services that only offer a processMessage "operation" (or  

none at all, however you prefer to describe it). My assumption is  

that you are talking about this kind - right? If so, see below ...




On Sep 9, 2006, at 5:14 PM, jeffrschneider wrote:



> Are polymorphic services a good idea?

>

In general, no, unless you want to call the processMessage() approach  

polymorphic.


> If they are implemented in a message oriented manner, should you:

> - Use the header or the body to indicate the polymorphic context

>

That would, IMHO, violate expectations - it's non-functional aspects  

that are supposed to be influenced by headers, not semantics.


> - If it is in the body, should it be implicit (based on type) or

> explicit based on content?

>

If it's explicit (based on content), I can honestly no longer see any  

trace of polymorphism. If I assume that by "type" you mean the  

outermost XML element, that alternative sounds reasonable - it fits  

with the document/literal/wrapped SOAP calling convention.



Stefan

--

Stefan Tilkov, http://www.innoq.com/blog/st/



> :-)

> Jeff

>

>

> 




    
  

    
    

--
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

__,_._,___