> > After all, the
> > Container-associated components are implicit services to the
> > Contained components and therefore should not need to be declared as
> > a dependency.
>
> what is an "implicit service"? It is often more transparent, and easier
> wrt reuse, if your components have no "implicit dependencies". If you
> need maximum cross-container reuse, it's best to declare the component
> its dependencies on the container-provided services, and then provide no
> implementation of those services (as the container already does). You
> could also design things so that these services are also declared, but
> using a special mechanism:
As far as I know, the current Avalon containers (except maybe EOB) do not
enable declarative services. Say I have an Account component with a
transfer( ) method. With the current Avalon containers, as a component
developer I would need to code the following...
public void transfer(Account to, double amount) {
SecurityManager sm = (SecurityManager)
manager.lookup(SecurityManager.ROLE);
if(sm.isUserInRole("AccountOwner") {
TransactionManager tm = (TransactionManager)
manager.lookup(TransactionManager.ROLE);
tm.begin();
account.deposit(amount);
this.withdraw(amount);
tm.commit();
manager.release(tm);
sm.release(sm);
}
}
However, if I could annotate these requirements in XML config, the Container
could pre- and post-process the request (assuming it controlled access to
intenal components) making the method...
public void transfer(Account to, double amount) {
account.deposit(amount);
this.withdraw(amount);
}
}
much like EJB offers...without actually being EJB. With a Container of this
sort, we could use it to host any type of component whether it be a web
component (servlet), a Swing component, or a distributed middleware
component. The Container would not need to be subclassed or rewritten, just
configured via XML to ensure internal components would have needed pre- and
post-request processing services available (using Interceptors to do the
actual work).
> > I think a component's ServiceManager should only provide peer
> > relationships and components related to a component's Container
> > should be part of a component's Context.
>
> this is a point of potential disagreement :D. My preference is to have
> the ServiceManager implementation delegate to the parent (container) its
> servicemanager. IOW:
First, ServiceManger exposes the hasService( ) method, implying that a
service may not be present...the component developer forgot to declare a
dependency.
Context has no such implication. Since the Container is providing the
service for its subcomponents, the presents of these services is implied.
Furthermore, since the Container provider (person who configures the
container component) may not also be the Component developer, there may be
discrepencies in the naming of the Container-provided services. The
Component developer can use a logical name which can be mapped to the
Container's actual service name and retrieve the desired service (if
necessary) from Context. If you were using hierarchical ServiceMangers, the
component would be required to know and use the same name as the Container
(violation of SOC?) in order to access (if necessary) the services of the
Container.
As I was thinking through all of this, and recalling previous list
discussions (Context vs. ServiceManager) I thought of something interesting.
When I first started working with Avalon, I was under the assumption that
ServiceManger was itself a Container that controlled the lifecycle of
referenced service...not so I think. If the ServiceManager only manages
access to peer-based components with which a component is associated, would
it not "AssociationManager" be a more appropriate name? Its role is clearly
that of a "reference resolver" rather than "managing the service".
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
