On Mon, 2002-07-29 at 20:10, Pat Monardo wrote:
> Well sort of. But I will start watching avalon-dev soon and that would
> be a better place for learning about Avalon perhaps.
keep asking those questions tho =)
I'm not sure whether avalon-dev is the best place to be. The majority of
the people there are so used to talking about the various avalon
concepts they often throw a few out of the window or don't mention them
in a discussion. Don't let the architectural 'battles' we have drive you
to more confusion than neccessary.....
> But the bottom line
> is that the Component is what the software engineer uses to model the
> Service. So a Service is just a means of access a Component? I dunno. I
> guess my stomach is a service after all -- well off to lunch -- service
> or master?
=)
Component = part of model; Service = behaviour of model?
--------------------------------------------------------
The separation you see: the term 'component' describes a structure, the
term 'service' is about behaviour.
The catch: when we do proper multi-dimensional separation of concerns
[1], in the end whether we model our system using components or services
results in all but no practical difference.
Elaboration:
1 - you cannot model behaviour in any other way than by using some kind
of structure (well, you can do procedural programming with gotos but let
us disregard that).
2 - there are two basic structure types: data structures and behavioural
structures (well, there is also the javabean containing both data and
logic but it is undesirable)
3 - a component is not a data structure; thus it is a behavioural
structure.
1,2,3 --> even if service != component,
someService.equals( someComponent );
So, after quite a lot of thought, the conclusion you end up at is that
whether you think of your system as using components or using services
is largely irrelevant. Component-Oriented Programming (COP) is all but
the same as Service-Oriented Programming.
Decomposition is tricky
-----------------------
Let me try and also explain in another way:
Pat:
> But the bottom line is that the Component is what the software
> engineer uses to model the Service
an example of this line of thought: I am going to create a
ServletExecutionService by composing it of several components. For
example a ServletExecutionService might contain multiple
PortListenerComponents, multiple VirtualFileSystemComponents, a
BootstrapperComponent, a LoggerComponent, a ManagementComponent etc etc.
However, you can also consider the parts of your ServletExecutionService
Services of their own. A VFS offers read/write/navigaton access for a
set of data (a filesystem). It might model such access using a
FileComponent. You can consider a FileComponent to be a very small
service that offers read/write access to a single piece of data.
On a larger scale, the ServletExecutionService might be used as a part
of a larger J2EEService, and when you look at a system like that, it
might make more sense to you to call the ServletExecutionService a
component.
How to decompose a system into pieces soon becomes the biggest challenge
when you do COP. In the example above, your VirtualFileSystemComponent/
VirtualFileSystemService might be of use in other parts of the
J2EEService besides the ServletExecutionService.
If there is no practical difference (ie in code) between service and
component, it makes life much easier when you want to 'refactor your
decomposition'.
Conclusion
----------
There are some semantical differences between the concepts/terms
"service" and "component". However, these are mostly based on the
granularity you use when looking at the application; what is a component
at one 'zoom level' seems more like a service at another. There is
usually little to no actual difference in the actual source code.
Therefore, it is not so important to make a distinction between service
and component. The real challenge is finding the optimal decomposition
for an application.
regards,
Leo Simons
[1] - http://jakarta.apache.org/avalon/framework/guide-patterns-soc.html
http://www.research.ibm.com/hyperspace/MDSOC.htm
PS: Berin, Stephen, if you're reading....would you care to provide some
comments? You've got these nice analytical brains for this stuff 8)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
