> Behalf Of Keith Harrison-Broninski
> Gervas Douglas wrote:
>
[...]
> >At the end of the day, a component can be as high-level, 'business
> >level', and of the same 'granularity' as any service. Or a
> service can
> >be easily as fine-grained as a component.
> >CBA and SOA are indeed different as they address very different
> >issues. If you work with components you work with code; while if you
> >work with services you use some remote functionality over network
> >under some contract.
> >
> >
> FYI, this definition of "service" and "component" is the same as that
> used by Martin Fowler - I posted a link to Fowler's definition to the
> group a while back.
>
> [FWIW, seems a sensible distinction to me]
Sysperski claimed the following distinction: "a service is a component
paired with an operator". Seems to sit with the above.
As a minimal distinction I think it is useful (i.e. it may not be the
only distinction). The notion of "provision" (and that there is a real
person or organisation behind that providor) is a central and critical
aspect of service orientation. It may appear a subtle distinction at
first - but it has many profound implications (such as services should
not leak technical exceptions).
This is also BTW the reason why code mobility violates
service-orientation IMO - because the notion of provision *by someone
else* is removed. [cue Greg ;-)] That is not to say code mobility is not
useful in some cases - but for me the provision aspect is central to the
concerns that service-orientation seeks to address. Mobile code
frameworks address a different (no less valid) set of concerns.
As always - architecture is about tradeoffs.
Cheers,
Murray
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/
