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