Gregg,
Sorry, but I'm not following you. While I absolutely agree with the
points you make below, I'm not sure what they have to do with the
discussion as to whether services must be based on components. Folks
have been extremely successful building highly reliable, performant,
and scalable service-oriented systems using CICS/COBOL and IMS/PLI.
Therefore I'm with Stefan. I see no reason why service orientation
needs to be based on either components or objects.
Anne
On 8/23/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>
> 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/
