You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Pat Monardo <pa...@cox.net> on 2002/07/29 10:55:12 UTC
Composable and Servicable
>From the Servicable javadoc:
The contract surrounding a Serviceable is that it is a user. The
Serviceable is able to use Objects managed by the ServiceManager it was
initialized with. As part of the contract with the system, the
instantiating entity must call the <compose> method before the
Serviceable can be considered valid
Shouldn't that read must call the <service> method?
So I have been introduced to Composable and Servicable and roles. It
seems Avalon is a dual-interface system as well.
Now I need to learn how components get associated with Component
Managers and Service Managers, not to mention learn more about roles. I
must admit, having struggled through COM+, and finally having come
around to Java Components, it help having everything happen in the
language, so to speak.
Pat
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Pat Monardo <pa...@cox.net>.
Some philosophical concerns:
A component is an object of knowledge. A message is a medium of
knowledge. Meaning only comes from registering the state of a component
into a knowledge base -- meaning flashes.
Pat Monardo
-----Original Message-----
From: Leo Simons [mailto:leosimons@apache.org]
Sent: Monday, July 29, 2002 12:09 PM
To: Avalon Users
Cc: Turbine Development
Subject: RE: Composable and Servicable (self and other)
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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Pat Monardo <pa...@cox.net>.
Now that they have a real J2EE engine, I think they are moving away from
that direction. But J2SE remains in the database.
Pat Monardo
-----Original Message-----
From: Leo Simons [mailto:leosimons@apache.org]
Sent: Wednesday, July 31, 2002 1:37 AM
To: Turbine Developers List
Subject: RE: Composable and Servicable (self and other)
On Tue, 2002-07-30 at 23:53, Pat Monardo wrote:
> The method you demonstrated is the method Oracle 9i recommends.
Depending on what you read where =)
> Oracle 9i is a work in progress, no doubt, so what 9i recommends is
> cloudy. Currently 9i has a tool to publish an object model specified
in
> PL/SQL as Java (I think it is called JPublish). But I think stored
> procedures are best left as 'workflow' like things or
> higher-level/externally controlled constraint processing and the sic
> object model should be coded as 9i Object Types. It is these that are
> easily published as Java object model.
Oracle is absolute horror, and the java support in 8i and 9i is just
horribly done.
Just an opinion from someone who was told to fix an 8i database
containing model, procedure and object definitions in I think 6
languages for a set of 10 tables.
Embed J2EE java in the database layer....anyone know of a bigger design
error?
cheers =)
LSD
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-07-30 at 23:53, Pat Monardo wrote:
> The method you demonstrated is the method Oracle 9i recommends.
Depending on what you read where =)
> Oracle 9i is a work in progress, no doubt, so what 9i recommends is
> cloudy. Currently 9i has a tool to publish an object model specified in
> PL/SQL as Java (I think it is called JPublish). But I think stored
> procedures are best left as 'workflow' like things or
> higher-level/externally controlled constraint processing and the sic
> object model should be coded as 9i Object Types. It is these that are
> easily published as Java object model.
Oracle is absolute horror, and the java support in 8i and 9i is just
horribly done.
Just an opinion from someone who was told to fix an 8i database
containing model, procedure and object definitions in I think 6
languages for a set of 10 tables.
Embed J2EE java in the database layer....anyone know of a bigger design
error?
cheers =)
LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Pat Monardo <pa...@cox.net>.
The method you demonstrated is the method Oracle 9i recommends.
Oracle 9i is a work in progress, no doubt, so what 9i recommends is
cloudy. Currently 9i has a tool to publish an object model specified in
PL/SQL as Java (I think it is called JPublish). But I think stored
procedures are best left as 'workflow' like things or
higher-level/externally controlled constraint processing and the sic
object model should be coded as 9i Object Types. It is these that are
easily published as Java object model.
Keep rockin!
Pat Monardo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Pat Monardo <pa...@cox.net>.
Thanks, Leo, I really appreciate your genorosity. I will read your
message again after breakfast; it's interesting. One thing I noticed
after rereading the article on object-structure brittleness, is that
they seem to imply that the brittleness comes from the object/method
style results in "fixing" the namespace, which seems true enough. So
then the example they give is to move more towards a functional style? I
have to reread that article. It seems that would support what components
are about -- message oriented functional style of programming! I wonder
why COP never happened in the Lisp world? Oh well. Your article mentions
it is difficult to do. Well, I'll read it again in an hour.
Thanks,
Pat
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Leo Simons <le...@apache.org>.
Hi Pat,
issue with event-oriented (ie mature message-oriented) software is that
it is somewhat difficult to do atm. Have a look at the event packages in
excalibur CVS, and at the by-now-famous SEDA paper for promising work.
> What do you think component-structure fragility means?
that's the nice thing about high-level thinking: it can mean anything.
> As we move to Intelligent Apps (???),
marketing terms yada yada yada
> Servlets/Web Services seem too
> busy/too chatty {presentation layer}
a lot of software needs a presentation layer. Servlets is really neat
for that. Web Services as advocated by MS/IBM is a presentation layer
towards other software, which means web services is nothing more than
enabling your applications to use a communication protocol based on XML.
Which is nice, but definately not as much of a revolution as it sounds.
Leave the buzz already =)
> and EJB seems legacy oriented
> (legacy oriented programming ;-) {business layer}.
yep. All of the java "enterprise" platform is very much "enterprise". In
99% of cases I suspect enterprise solutions are in use because no
"middleware" solutions exist.
> So what is the
> intelligent platform? Something like EOB? I peeked at that and it seemed
> early/rough.
it is, very much early, and somewhat like my 'vision' for the future.
What will happen is that JSR 111 (the Services proposal, partly based on
avalon) will rock the java world, and then we will see architectures
like EOB replace EJB. This is if everything goes as planned....
> You seemed to imply you really like the separation of behavior and
> structure.
uh...the separation of behaviour and data. Separation of behaviour from
structure leaves you with either functional programming or procedureal
programming which we know is not cool =)
> I've been learning SQL3 and do you think SQL3's object types
> would be going in the wrong direction?
dunno; I only use SQL92. I do know the oracle extensions to that for
support of objects are yucky.
> It seems we need to compose a real relational/logic
> system augmented with a behavior system as a separate dimension of
> concern.
Systems I design generally have a pure relational setup at the database
level (ie tables with relational constraints), and then an abstraction
from that for flexibility (ie views), and then a procedureal library on
top of that.
In the middleware, the first thing you do is abstract away from SQL to
create a data module based on that procedureal library, preferably using
an automated tool.
The middleware uses COP, with the data module as a vital piece.
The middleware is 'included' in a servlet via a central component (the
container). The servlet then couples presentation layer (ie uses
VelocityService) to the middleware.
Example Setup
=============
CREATE TABLE bla
{
id,
name,
}
CREATE TABLE blaDecorator
{
content
}
CREATE VIEW blaView
{
id,
name,
content
}
CREATE PROCEDURE getBla
{
return select * from blaView;
}
CREATE PROCEDURE setBla( id, name, content )
{
insert into blaView (id, name, content)
}
[JDBC LAYER]
[OJB-style LAYER]
class ContextBuilderImpl implements ContextBuilder
{
DataModuleComponent dm;
service( ServiceManager sm )
{
dm = (DataModuleComponent)sm.lookup(
DataModuleComponent.ROLE );
}
getContext( ResultData rd )
{
// figure out which methods to call on dm based on rd,
// use result of method calls to fill in context
}
}
class MyServlet
{
static MyContainer mc;
static
{
mc = new MyContainer();
}
handleRequest( request, response )
{
RequestProcessor rp =
(RequestProcessor)mc.getServiceManager().lookup(
RequestProcessor.ROLE );
ContextBuilder cb =
(ContextBuilder)mc.getServiceManager().lookup(
ContextBuilder.ROLE );
TemplateStore ts =
(TemplateStore)mc.getServiceManager().lookup(
TemplateStore.ROLE );
VelocityService vs =
(VelocityService)mc.getServiceManager().lookup(
VelocityService.ROLE );
ResultData rd = rp.process( request, response );
Context c = cb.getContext( rd );
Template t = ts.getTemplate( rd );
vs.process( c, t, request, response );
}
}
My hope is that at one point Turbine will follow this general pattern
(though it should be a lot more powerful, of course =). You'll replace
"MyContainer" with "Plexus", "MyServlet" with "TurbineServlet", and all
the other stuff referenced like RequestProcessor exists as a service
within Fulcrum.
In current in-house setups we do not use OJB but hand-built data
modules, firebird as the RDMDS, and wrappers around Turbine 2.1 fulcrum
stuff to implement the various components required, and a custom
container based on a version of phoenix that embeds the standalone
turbine.
For more complex setups you add another layer between middleware and
data, this could be EOB. EJB is to
> Knowledge is *neither* power nor behavior.
yup =)
LSD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Pat Monardo <pa...@cox.net>.
Another great message! I read the hyperspace link. Looked at SAGE and
MessageCentral. These are MessageCentral concerns:
Issues in moving to message-oriented software
Successfully supporting a programming style that eliminated
component-structure fragility requires addressing several issues:
What to do instead of interfaces?
What happens to object references?
What about multiple servers?
How do we avoid "message not understood"?
Good support for message-oriented programming will rely upon a broker
and a composition system capable of great flexibility, like that
provided by MessageCentral.
What do you think component-structure fragility means?
I appreciate the link to Separation of Concerns. I didn't fully
appreciate that.
As we move to Intelligent Apps (???), Servlets/Web Services seem too
busy/too chatty {presentation layer} and EJB seems legacy oriented
(legacy oriented programming ;-) {business layer}. So what is the
intelligent platform? Something like EOB? I peeked at that and it seemed
early/rough.
You seemed to imply you really like the separation of behavior and
structure. I've been learning SQL3 and do you think SQL3's object types
would be going in the wrong direction? (no cheap shots ;-) I think I
know your answer. It seems we need to compose a real relational/logic
system augmented with a behavior system as a separate dimension of
concern. Knowledge is *neither* power nor behavior.
Pat Monardo
-----Original Message-----
From: Leo Simons [mailto:leosimons@apache.org]
Sent: Monday, July 29, 2002 12:09 PM
To: Avalon Users
Cc: Turbine Development
Subject: RE: Composable and Servicable (self and other)
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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Leo Simons <le...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Pat Monardo <pa...@cox.net>.
Well sort of. But I will start watching avalon-dev soon and that would
be a better place for learning about Avalon perhaps. 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?
Pat Monardo
-----Original Message-----
From: Leo Simons [mailto:leosimons@apache.org]
Sent: Monday, July 29, 2002 3:11 AM
To: Turbine Developers List
Subject: RE: Composable and Servicable (self and other)
Pat,
you find additional meaning in the existence of both Composable and
Serviceable that is not there.
The service package is a replacement for the component package. Quoting
Stephen McConnell from a recent thread on avalon-users:
"The service package was introduced as a candidate replacement of the
coponent package in order to eliminate artifical implications introduced
my the Component interface. In all respects the component package and
service package are equivilent with the exception that Component is
replaced by java.lang.Object in the service package.
(...)
the service package is functionally the smae as the component package -
no semantic differences. The service package is the preferred approach
and as work on the container side of things nears completion, wel will
probably deprecate the component package and clearly document the
reasons, rationale and replacements under the service package."
hope that helps,
- Leo Simons
On Mon, 2002-07-29 at 11:13, Pat Monardo wrote:
>
> I notice that a ServiceManager manages Objects not Components (only a
> ComponentManager does that). That makes sense. So a Composable is
able
> to incorporate components into itself (the self). To access a service,
> then that is an object (the other). I like that. My stomach is a
> component of myself not a service. A service can refer to a composable
> object but I don't care if the service has components or not, it's an
> object.
>
> Pat
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Leo Simons <le...@apache.org>.
Pat,
you find additional meaning in the existence of both Composable and
Serviceable that is not there.
The service package is a replacement for the component package. Quoting
Stephen McConnell from a recent thread on avalon-users:
"The service package was introduced as a candidate replacement of the
coponent package in order to eliminate artifical implications introduced
my the Component interface. In all respects the component package and
service package are equivilent with the exception that Component is
replaced by java.lang.Object in the service package.
(...)
the service package is functionally the smae as the component package -
no semantic differences. The service package is the preferred approach
and as work on the container side of things nears completion, wel will
probably deprecate the component package and clearly document the
reasons, rationale and replacements under the service package."
hope that helps,
- Leo Simons
On Mon, 2002-07-29 at 11:13, Pat Monardo wrote:
>
> I notice that a ServiceManager manages Objects not Components (only a
> ComponentManager does that). That makes sense. So a Composable is able
> to incorporate components into itself (the self). To access a service,
> then that is an object (the other). I like that. My stomach is a
> component of myself not a service. A service can refer to a composable
> object but I don't care if the service has components or not, it's an
> object.
>
> Pat
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Composable and Servicable (self and other)
Posted by Pat Monardo <pa...@cox.net>.
I notice that a ServiceManager manages Objects not Components (only a
ComponentManager does that). That makes sense. So a Composable is able
to incorporate components into itself (the self). To access a service,
then that is an object (the other). I like that. My stomach is a
component of myself not a service. A service can refer to a composable
object but I don't care if the service has components or not, it's an
object.
Pat
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>