I should have been clear, I meant the functional contract of the service, rather than the total service contract. Non-functional elements like security, response times etc aren't directly related to the functional contract so I'd say its okay to have different policies for different users. What I'd say would add a great deal of complexity for little value would be something like a (lets use REST for a laugh) service of
In which when customer A "PUTS" <name>fred</name> it creates a new customer called fred and when customer A "PUTS" <day>wednesday</day> it creates a yearly calendar starting from next wednesday. Equally if B "PUTS" <name>fred</name> this should behave in the same way as for A and not result in a contract being issued against all people called fred.
Polymorphism is tricky, if you don't keep the functional contract the same (the semantics of the call) then you might as well just do a command pattern and be damned.
On 12/09/06, Hitoshi Ozawa <[EMAIL PROTECTED]> wrote:
Steve,
If two consumers have a different policies such as encryption, should
they be made into two separate services?
H.Ozawa
Steve Jones wrote:
>
> What I'm saying is that a service that has a polymorphic contract is a
> bad idea. One that acts in a polymorphic manner on data but applies
> the same contract to them is just good design.
>
>
>
>
__._,_.___![]()
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
__,_._,___
- Re: [service-orientated-architecture] Polymorphic Services Steve Jones
Reply via email to
