Date: 2004-03-03T05:00:07
Editor: 203.121.47.163 <>
Wiki: Apache Avalon Wiki
Page: AvailabilityContract
URL: http://wiki.apache.org/avalon/AvailabilityContract
no comment
New Page:
= Availability Contract : What is that ? =
In a static, single-JVM application it is assumed that the structure of the
application itself doesn't change during the course of execution. Objects are linked
to other objects by the JVM itself, and things is rigid and safe.
In more dynamic environments, such as many J2EE containers, Servlet containers and
network/distributed applications, such a solution is either not desirable (perhaps due
to reloading requirements) or not possible (network can be temporary down).
Avalon should support dynamic environment more than the current Avalon 4 Framework
does. And it is required that the Framework has explicit support for it, so the proper
contract between the container and the various components can be established.
Availability Contract is all about that one component is INFORMED when another
component becomes available and unavailable for access. The contract DOES NOT concern
itself about the loading/unloading of components and all the related issues around
that.
== Availability in Avalon 4 ==
In Avalon 4, the ServiceManager is closely related to the Availability Contract. The
current contract is, when
{{{ void service( ServiceManager manager ) throws ServiceException }}}
is called, all serviced components ARE AVAILABLE for lookup. Furthermore, the Avalon 4
Framework also stipulates that components are not removed or disappear during
execution.
So what would be needed?
First of all we need the AvailablityAware interface, which is both the marker
interface for that the component is capable of handling components that disappears and
reappears. But the interface may as well contain the callback methods for the
Availabilty notifications. So we end up with something like this;
{{{
public interface AvailabilityAware
{
void available( String lookupKey, Object instance );
void unavailable( String lookupKey, Object instance );
}
}}}
Secondly, we need a mechanism to '''''subscribe ''''' to the component. This should
be done with the exact same query mechanism being used for the lookup(), which in
Avalon 4's ServiceManager is just a String, potentially meaning anything. Any more
advanced query or query template is beyond this contract and should be addressed
elsewhere.
But how do we inform what we are interested in?
Well, we can't add methods to the ServcieManager interface, as this would break
compatibility. So we can either extend the ServiceManager, and downcast in the
service() method, or we could pass the AvailabilityManager in a separate method call
to the component. Such call could then be bundled into the above AvailabilityAware
interface, but one could imagine that you have listeners that doesn't receives the
Manager.
I leave this choice out of the discussion. What is important is that the Manager in
question has two methods;
{{{
void registerAvailibiltyObserver( AvailabilityAware observer );
void unregisterAvailibiltyObserver( AvailabilityAware observer );
}}}
And of course the names can be discussed, as well as whether the JavaBean Event
pattern should be used instead, and many other picky details. I am just trying to
describe the principle.
What compatibility effects would the introduction of this contract have?
* First of all, no container and no component support it today.
* Secondly, if a non-AvailabilityAware component is used in a capable container, there
are no issues what so ever.
* Thirdly, if a new Availability-aware component is used in a non-capable container,
then it is required that the container is updated with the new avalon-framework JAR,
so that the component can be loaded, but otherwise no issues.
Conclusion: It would be possible to introduce the Availability Contract in Avalon 4
Framework without much impact on existing containers and no impact on existing
components, and slowly upgrade the supported containers.
== Availability in Avalon 5 ==
Instead of doing an extension of Avalon 4's ServiceManager, there are several ways an
Availability Contract can be implemented in a ''fresh'' framework. One should probably
address this hand-in-hand with ComponentQuery contract, since they are closely
related. That includes registering a ServiceTemplate with the ServiceManager of what
is of interest, which is the same template used for lookups, which may return more
than one component.
Another related issue in a new framework would be that the Availability contract
becomes the center of all dependency resolution, and the ServiceManager is modified
accordingly.
== Container Issues ==
It is not straight forward for the containers to support the Availability Contract,
especially if non-AvailabilityAware components are allowed to depend on components
that may be removed. In such case, some form of interceptor between the non-capable
component and the removable component has to be put in place. For Merlin, such
functionality would go into an existing Proxy that typically wraps all components
today.
Furthermore, the Availability Contract would only be needed if components can be added
and removed on-the-fly. Such process has its own pitfalls and tricky bits, which needs
to be addressed elsewhere. Merlin has in February 2004 got the ability to modify the
components used during runtime, but at the time of this writing, it still has a long
way to go before it is a solid functionality.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
