OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] PROPOSAL: More flexible ObjectRef


Monica,

I do not see comparable issues here with Late Binding.

The reason is that there is only one highly constrained
use case and context - namely - user issued an update
against an existing registry object using the LID aware
method.

Late Binding in BPSS has to cope with a minimum of
4 different use cases that we've identified for V2 - and
then obviously more beyond that - where the context
can be user defined.

Therefore - my conclusion is that registry here is
fine and does no need a seperate context management
mechanism as in the BPSS case.

Thanks, DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>
Cc: "Nikola Stojanovic" <Nikola.Stojanovic@RosettaNet.org>;
<regrep@lists.oasis-open.org>
Sent: Wednesday, June 16, 2004 12:29 PM
Subject: Re: [regrep] PROPOSAL: More flexible ObjectRef


> Farrukh Najmi wrote:
>
> > Nikola Stojanovic wrote:
> >
> >> <Farrukh>
> >>
> >> > My proposal is to add a new logical id attribute to the set of
> >> > registry versioning attributes, and otherwise improving ObjectRef to
> >> > allow selection of a particular version of an object.
> >>
> >> +1 on being able to reference a logical object in a version independent
> >> manner.
> >>
> >> This is exactly what the lid attribute is for in the versioning spec
> >> being added to version 2.6.
> >>
> >> I think that the use case you raise can (and should) be addressed very
> >> easily by extending the ObjectRef class to have a choice of:
> >>
> >> a) a static "hard-wired" reference to a specific version of a specific
> >> object (current capability)
> >>
> >> b) a dynamic "late-binding" reference to a logical object which is
> >> determined at run-time (de-refence time).
> >> I could see this being done via a second attribute named "dynamic".
When
> >> dynamic is false (default) the registry
> >> assumes that the id attribute references the referenced object. When
> >> dynamic is true, the registry assumes that the id attribute MUST be to
a
> >> stored query that dynamically determines the referenced objects.
> >>
> >> This is a very powerful concept. Thanks Matt for seeding this idea. I
> >> hope we can discuss this over email prior to next telecon. Thanks.
> >>
> >> </Farrukh>
> >>
> >> I also see this as a very valid and a needed Use Case and that
> >> LateBinding approach is interesting. However, I think that we have a
> >> solution that doesn't need LateBinding. It would be something like
this:
> >>
> >> - subscribe to relevant event(s); in this case it is Update of the
> >> objects that are members of the package.
> >>
> >> - implement "Web Service" that is going to be triggered by the above
> >> event and that is going to adjust relevant object references.
> >>
> >> As one looks at the context of the two, LateBinding would incur
> >> lookups whenever object references need to be resolved and
> >> EventNotification will be invoked when relevant events happen. One
> >> would assume that occurrence frequency of the first is higher then of
> >> the second.
> >>
> > Interesting point that Matt's use case is already addressable via the
> > Event Notification feature. So as I understand your suggestion the
> > reference that needs to always be to the latest version of an object
> > could be updated from one version  of an object to another by a web
> > service that is an Event Notification Listener  service that gets
> > invoked whenever a new version of the object is created.
> >
> > I agree with the point that your alternative is more efficient than
> > late binding Object Reference approach and requires no additional work.
> >
> > I now reconsider the idea of doing late binding of object references
> > now. Instead we should keep it in our future candidate work items and
> > rely on your Event Notification based approach to address Matt's use
> > case for now.
> >
> > Any one disagree with this proposed resolution?
>
> mm1: I don't disagree but wish to ask a question that applies to not
> only late binding but the event notification approach where object
> references are updated.  In ebBP, we found that LateBinding is not a
> black-white situation. For example, when we started to talk about
> conditional attributes such as time to perform, we determined that
> LateBinding could have a duration, may or may not be allowed, and
> constraints could be applied (when changed, if changed where does the
> value come from, etc). This raises questions:
>
>     * Can you update the object references to the latest version?
>     * Are there conditions that apply? Are all objects in the package
>       updated?
>     * Does the owner define the duration, parameters or constraints of
>       when they can be changed?
>
> As well, in our work on time to perform, we found the conditional
> aspects to be best expressed as an element not an attribute. Thanks.
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]