Stefan Tilkov wrote:
> I see no reason at all why service orientation would have to be based
> on components. For example, components not only have a contract with
> their caller, but also with a component environment into which they
> are deployed. Services don't (although service implementations may).
I think that implicitly services do have contracts that are invisible to the
users. It's only through good service design that the limits these contracts
present to the services operation can be monitored and altered over time to not
be a burden to the service users.
1. Only through design of the underlying software systems can a service
be fault tolerant, multi-homed or otherwise present most types of
QOS related behavior. The 4th, 5th or 6th 9 of uptime is not free.
2. Only through the use of specific hardware with specifically supporting
software architectures, can certain performance limits be realized.
Speed is not free.
There are lots of other examples. Saying that SOA gives you all of these
things
sets unrealizable expectations which is exactly what causes markets to crash
when the goods don't meet their billing.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> 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/
