[OpenAjaxInterop] Minutes 2008-12-15

Howard Weingram weingram at tibco.com
Tue Dec 16 17:14:26 PST 2008

Comments on the getParameters() point:

Alternatives include:

1. Every container (plus every MH) must be redundantly
    instantiated with params by the manager application.
    The manager application must keep track of associations between
    parameter values and MH or Container. GetParameters() goes away.

2. Current approach (container uses MH.getParameters().<someParameter>
    to get parameters shared by MH and containers.

3. MH has a set of new getter functions to get each specific object
    that are re-used by containers (e.g. GetSecurityAlertHandler())

I could live with #1. It then becomes the manager application code's problem
to instantiate every Container with all required parameters, and it becomes
the manager application's job to keep track of the relationship between
parameters and hub components if it needs them. With approach #1, different
Containers could be configured to have different scopes or security alert
callbacks, if desired. We could always add getParameters() to MH, HC, and
Container interface in a later release if we need them.

    Advantage: smaller Hub interface, because tracking parameters is the
    application's problem. Can always do #2 / #3 later.

    Disadvantage: more complex application code

#2 is what we have now. Objects in the hub carry their own parameter
information around with them rather than requiring application code to keep
track of the associations between that parameters info and hub objects. If
scope and callback objects must be retrieved and cleaned up while the
application is destroying a ManagedHub, the application code will be cleaner
with #2 or #3 (because it can get these values from the associated MH rather
than having to maintain an external hub-wrapper object that ties them
together) than it will be with #1. Containers can also be instantiated by a
toolkit without having to worry about getting the MH parameters into the
toolkit calls. The hub carries this information internally.

    Advantage: Hub provides access to parameters, keeping application/
    toolkit code simpler.

    Disadvantage: one extra function in Hub interface

#3 would add a bunch of getters into the Hub interface. I could live with
this. It is very similar to #2. It would represent only a tiny increase in
code size over #2 (utterly insignificant compared to a typical FIM
implementation). ManagedHub and HubClient might not have the same set of
parameters, so the set of functions might differ in the 2 cases.

    Advantage: similar to #2 but slightly more OO.

    Disadvantage: several extra functions in MH and HC interfaces

There are some other possibilities, but they result in greater run-time
complexity, which is not helpful.

More information about the interop mailing list