Matt,
Thanks for the spelling out the analogies to EJBHandle. Given the use
cases for ControlHandles, I think that is 100% a reqt that the
implementations be Serializable, so if this is true, then perhaps the
best way to express this is by making it explicit via the
ControlHandle interface. The Javadoc and associated Control
Containment design doc (still a WIP at
http://incubator.apache.org/beehive/controls/controlsContainment.html),
can emphasize this well.
With respect to whether a ControlHandle is or is not a "network
reference", my take is that it can be, but should not be required to
be. There are potential containment scenarios for Controls, such as
a standalone VM, applet, ... where the ability to dispatch an network
event from the outside in might be problematic (no externalized
listeners), but where using a handle to enable a local async event
dispatch might still be interesting.
This being said, I get your point that this particular 'property' of a
ControlHandle might be useful and interesting. I can envision an API
like:
public interface ControlHandle {
...
public boolean isLocalHandle()
...
}
if 'true', this might indicate that the serialization/deserialization
context must be the same (from a container perspective) for the handle
to be able to properly dispatch events, or, if 'false' indicates that
the handle could actually be passed out externally w.r.t. the
constructing container with enough information (and a dispatch path)
to call back in (ala EJBHandle).
-- Kyle
On 4/27/05, Matthew Stevens <[EMAIL PROTECTED]> wrote:
> Kyle,
>
> It may be worth noting here that EJB Handle interface does extend
> Serializable. However, it is clearly noted that EJB Handles are
> considered "network references" and are only available to EJB clients of
> remote EJBs. In my opinion the term "handle" implies a network
> reference. Also, the asynchronous nature of the "event" use case for
> ControlHandle, in practical server topologies, demands a "network"
> aspect. For example, if someone wanted to create a Alarm Control which
> acted as a business delegate to an EJB Timer Service, its worth noting
> that the TimerHandle interface and the "info" property of Timer
> interface are both Serializable. If ControlHandle does not prescribe
> Serializable then a portable Alarm Control implementation would need to
> not only assert that a ControlHandle was available, but that it was
> Serializable as well.
>
> If it is the intent of ControlHandle to be used for intra-VM
> coordination of async events then I can understand why it does not
> demand Serializable. In that case, there should be an API on
> ControlHandle or a documented convention (e.g. checking for
> serializable) which a control author can rely on to discern the
> capability/policy of the ControlHandle in support of portable
> implementations.
>
> matt
>
> Kyle Marvin wrote:
>
> >ControlHandle itself is just an interface... but you are 100% that
> >concrete implementations of ControlHandle should mplement
> >java.io.Serializable to enable them to be persisted, enqueued, passed
> >over a wire, etc.
> >
> >In general, it's probably not a good idea to have an interface
> >implement Serializable and then have a corresponding impl pick it up
> >via an 'implements' inheritance relationship. You generally want a
> >class author to be thinking more explicitly about serialization in the
> >design of class state.
> >
> >I'll add something to the Javadoc for Control Handle that states
> >"classes implementing this interface should be serializable". This
> >will make it more explicit, less implied.
> >
> >-- Kyle
> >
> >On 4/27/05, Mridul Muralidharan <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Hi all,
> >>
> >> Is there any particular reason why ControlHandle does not implement
> >>java.io.Serializable interface ?
> >> From what I read , I would guess it is envisioned to be used in
> >>situations which will need serialization/deserialization ...
> >>
> >>Thanks and Regards
> >>Mridul
> >>
> >>
> >>
>
>
