Mark
I
think all of us have the same interpretation of the CMDBf spec. The CMDBf spec
defines the push mode, where the MDR initiates the federation and the pull
mode, where the CMDBf initiates the federation. In both modes, the initiator is
responsible for maintaining the integrity of the registration. In the
implementation of the initiator (MDR or CMDBf), it must maintain an internal
list of registered items. When any of the registered items in the internal list
change state, it is responsible for updating the registration.
The issue is that we are
trying to implement a third mode, where an external component (COSMOS)
initiates the federation on behalf
of an MDR acting in push mode. The problem is that the MDR has no idea that
COSMOS initiated the federation and thus cannot update its internal list of
registered items.
One solution is that the
external component (COSMOS) informs the MDR of the registration so it can
update the internal list of registered items and continue with business as
usual. Unfortunately there is no such interface for the MDR in the CMDBf spec.
This was the point of my original question.
Another solution is for
COSMOS to maintain an internal list of registered items, perhaps in a
Notification Broker component as you suggested. But today, this component must
use polling to determine if any of the registered items change state and a
polling solution is not really desirable. A better solution is to use events.
But again there is no such event interface for the MDR in the CMDBf spec.
I’ve
included cosmos-dev and Marv for his opinion.
Regards
Bill
From: Mark D Weitzel
[mailto:weitzelm@xxxxxxxxxx]
Sent: Wednesday, February 06, 2008
9:36 AM
To: Ali Mehregani
Cc: Hubert H Leung; Sheldon
Lee-Loy; Muldoon, William H
Subject: Re: CMDBf registration
questions
I also interpret the spec the way Ali has. I
think of CMDBf as a point-to-point protocol. An MDR knows about a
federating CMDB. The registration API is used for these
updates/deregistration. We should have what we need today based on Ali's
work. Technically, an MDR can, know about more than one, but as Ali
points out, there is no broadcast mechanism, so an MDR is always sending one
message at a time to a cmdb. Any discussion of a notification broker
should be taken off the table until we get some insight from the CMDBf group. At
a minimum, it's an i10 item, if then.
Lines
1544 - 1549
o
The MDR also uses the Register operation to update
registered data. An update may consist of any combination of:
o
Changes to existing data, such as a property value
change
o
Registering an additional record type for this item
or relationship
o
Deregistering a previously registered record type
for this item or relationship
p.s.
Is there any reason this thread is not on COSMOS-Dev?
_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing | (919) 543 0625
| weitzelm@xxxxxxxxxx
|
|
|
Re: CMDBf registration
questions Link
|
|
Ali Mehregani
|
to:
|
Sheldon Lee-Loy
|
02/05/08
05:59 PM
|
|
Cc:
|
Hubert H Leung, Mark D Weitzel,
"Muldoon, William H"
|
|
|
|
Here's my translation of the section copied from the
specification (lines 1531-1536):
When
MDR registers item A and A is accepted by the federating CMDB, then it is the
responsibility of the MDR to notify the federating CMDB when A changes. E.g.
if A is deleted from the MDR, then it is the responsibility of the MDR to
notify the federating CMDB that A has been deleted.
I'm
not sure why you're asking how we can update the MDR with the registration IDs.
There
are no plans in i9 for MDRs to broadcast changes to items/relationships that
have been registered with a federating CMDB. This will be enable once we
have an implementation of a notification broker.
I'm
confused by the second question as well. I don't think we have the same
interpretation of the section that's been copied from the specification.
Ali Mehregani
Phone Number: (905) 413-3712
Service Modeling Language - COSMOS
http://www.eclipse.org/cosmos/
|
Sheldon Lee-Loy/Toronto/IBM
05/02/2008 04:44 PM
|
|
To
|
"Muldoon, William H"
<William.Muldoon@xxxxxx>
|
|
cc
|
Mark D Weitzel/Raleigh/IBM@IBMUS, Ali Mehregani/Toronto/IBM@IBMCA,
Hubert H Leung/Toronto/IBM@IBMCA
|
|
Subject
|
Re: CMDBf registration questionsLink
|
|
Hi Bill,
I
replied to your questions on the talk page.
Mark,
Bill
pointed out a good point.
- In the registration process, how do we update the
MDR with the returned CMDBf registration IDs required for subsequent data
change updates from the MDR? Refer to the CMDBf spec (lines 1531-1536):
1531 If the return status is accepted, the Registration service
returns the ID
1532 that identifies the item or relationship
within the Registration service.
1533 For accepted data, the MDR is expected to
update the Registration
1534 service whenever any of the registered data
changes. The specification
1535 does not stipulate how soon after the data
changes the update must
1536 occur – this would typically be
determined by local policy.
- The previous point also applies to the
unregistration process: we have no interface to inform the MDR that the
items have been deregistered
Do we have the interfaces in place to update the MDRs?
Thanks,
Sheldon
______________________________________
Sheldon Lee-Loy
Tivoli
Autonomic Computing, IBM Toronto Lab
email: sleeloy@xxxxxxxxxx
phone: 905.413.2610
|
"Muldoon, William H"
<William.Muldoon@xxxxxx>
02/05/2008 03:13 PM
|
|
To
|
Sheldon Lee-Loy/Toronto/IBM@IBMCA
|
|
cc
|
|
|
Subject
|
CMDBf registration questions
|
|
Sheldon
Please see my comments
on
the
talk page at http://wiki.eclipse.org/Talk:COSMOS_Design_214672.
Thanks
Bill
