> Therefore I'm with Stefan. I see no reason why service orientation
> needs to be based on either components or objects.
I concur. Objects and components can be useful ways of organizing
implementation internals (and a common one at that, at least these
days), but "services" don't strictly require components or object
orientation.
['modularity' isn't inherently required, though few people enjoy
working on such systems ;-]
I heard a great description years ago which is crude, coarse,
inherently flawed and wrong, but a useful fiction for a simple
distinction to get the key idea:
There are 3 levels of 'things' (design/code-organization/etc):
1. Services
2. Components
3. Objects
#3 Objects = Anything your programming language says is an object.
Usually everything with the 'class' keyword, though not only (see
Javascript, or Python functions, among others).
#2 Components = Aggregate set of 1+ objects providing a set of
functionality, e.g. a "grid control" in a UI is a component; it's
likely implemented using multiple types of objects, but
the 'component' is the level of functionality and abstraction for
the behavior provided. You think "I've got a grid control",
not "I've got a render widget which interacts with a text widget and
a header widget and the data binder widgets and..."
#1 Services = High-level, coarse-grained functionality.
For instance, "printf()" is a horrible service, but "Make Airline
Reservation" is a good one.
In addition, 'context' and 'style' (for lack of a better word)
further discriminate components from services:
* Components run in their caller's context; Services provide the
context for execution.
* Components can (and often do) be exposed with an OO face; Services
can (and should) be exposed with a functional- or message-oriented
face.
As I said, a very flawed description, but a useful fiction that most
people quickly understand and start to grasp the key issues.
"Objects" may not have been popular in CICS (or most sytems,
actually, prior to the 90s), but assuming a component- or object-
oriented view of the world is required to provide 'services' is a
rather narrow and flawed perspective.
FWIW, I find people who've worked in C++ or Python (and others, no
doubt) more likely to understand both models (OO and functional),
and Java folks to have a strong OO bias with a weaker sense of non-
OO models. Not surprising (when all you have is a hammer...). I
thought Steve Yegge did a great job illustrating why this is so
("Execution in the Kingdom of Nouns" at http://steve-
yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html).
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/
