Mark
The
external component that I referred to as COSMOS is the COSMOS UI. So I really did
mean to say that the COSMOS UI performs the registration “on behalf”
of the MDRs. Refer to the design page at http://wiki.eclipse.org/COSMOS_Design_214672.
For example, in the first scenario, an administrator is running the COSMOS UI
and “right clicks on a federating CMDBf”, selects the “register
configuration items” popup menu, selects the MDRs, and clicks register. Thus
the registration activity is initiated by the COSMOS UI. It’s NOT
initiated by the MDRs. We have this sequence:
1. COSMOS UI issues CMDBf queries to obtain CIs from the MDRs.
2. COSMOS UI invokes the CMDBf registration interface on the
federating CMDBf using the CIs from the previous step.
3. COSMOS UI receives the CMDBf registration responses but cannot do
anything with it.
4. The MDRs are left in the predicament of being unable to maintain
the integrity of the registration because they are unaware of the registration
in step 2.
Today’s
discussion included a new enhancement to provide some “helper”
plumbing to assist developers of COSMOS MDRs to support CMDBf registration. In
this case, the registration is initiated by the COSMOS MDR. We have this
sequence:
- COSMOS
MDR invokes the CMDBf registration interface on the federating CMDBf using
the COSMOS “helper” plumbing.
- COSMOS
MDR receives the CMDBf registration response and uses the COSMOS “helper”
plumbing to track the registration.
- COSMOS
MDR detects a change to a registered CI and uses the COSMOS “helper”
plumbing to update the registration.
The “helper” plumbing provides
an added value in COSMOS for MDR developers. But this is a separate topic than
ER 214672.
As
far as 214672 is concerned, let’s see what the CMDBf folks have to say…
Regards
Bill
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On
Behalf Of Mark D Weitzel
Sent: Wednesday, February 06, 2008
1:21 PM
To: Muldoon, William H
Cc: Mark Johnson; Troy Volin; Ali Mehregani; Jacob Eisinger; Waschke,
Marvin G; Cosmos Dev
Subject: [cosmos-dev] RE: CMDBf
registration questions
Bill,
I
think we went into some good detail on the cosmos call this morning. I'm
copying Mark J. and some other members of his team on this note so that when
Ali updates the design page to capture our thoughts, they. can reference this
thread.
Where
I think COSMOS can help is to establish some of the APIs as part of the
programming model, for adapting existing stores of management data to MDRs. From
the perspective of the CMDBf spec people, this could easily be "an implementation
detail". However, as we think about how and where work in the open
can provide value, this kind of "registration management" could add
significant value. It feels like plumbing everyone will need to build.
There
might also be something very subtle in your mail below. When you apply
the COSMOS MDR code on top of an existing data store, this IS the MDR. It
is how you do federation. So COSMOS does not initiate federation "on
behalf" of an MDR b/c it IS the MDR. Part of the "binding"
to an existing data store is the "callback" interface that can hook
into the pull mode.
-mw
_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing | (919) 543 0625
| weitzelm@xxxxxxxxxx
|
|
|
RE: CMDBf registration
questions
|
|
Muldoon, William H
|
to:
|
Mark D Weitzel, Ali Mehregani
|
02/06/08
09:55 AM
|
|
Cc:
|
"Hubert H Leung", "Sheldon
Lee-Loy", "Cosmos Dev",
"Waschke, Marvin G"
|
|
|
|
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
