[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: FW: [cosmos-dev] RE: CMDBf registration questions
|
Hi Bill,
The CMDBf says "In push mode, the MDR initiates the federation." I think
it can be generalized to say that in push mode, any entity other than the
federating CMDB initiates the federation. In a registration message, the
InstanceIds have MdrId and localId that uniquely identify the CIs. So it's
not necessary to ask the MDR to do the registration of its own CIs. We can
have the UI, or a registration manager that help register items from one or
more MDRs. This kind of registration should still be considered the "push
mode".
The problem I described was not caused by the fact that we are using the UI
to initiate the registration, but the way the function was implemented. If
we are using the push mode, the UI will do registration with the federating
CMDB using the standard registration service, which will return the
registration status for each item. Prior to the registration, the UI need
to get the list of items and relationships via the query services of the
MDRs.
I opened two bugs related to this issue: bugs 221612 and 221613.
We can demonstrate pull mode in the COSMOS demo as well, but that's a new
ER.
Thanks,
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Muldoon, William
H"
<William.Muldoon@ To
ca.com> "Cosmos Dev"
Sent by: <cosmos-dev@xxxxxxxxxxx>
cosmos-dev-bounce cc
s@xxxxxxxxxxx
Subject
RE: FW: [cosmos-dev] RE: CMDBf
03/05/2008 04:43 registration questions
PM
Please respond to
Cosmos Dev
<cosmos-dev@eclip
se.org>
Hubert
The original point of this thread was that the pull mode
should
be initiated by the federating CMDB (with the MDR) and the push mode
should be initiated by the MDR (with the federating CMDB). There should
be no other parties involved. In COSMOS, we have introduced a third
party (our UI), which can only act in a "hybrid" mode using a
combination of push and pull. The hybrid mode introduced a registration
integrity issue, which became the main topic of the thread.
I agree with all your points about our implementation.
Basically
our UI is testing the test federating CMDB, which doesn't really help
our adopters. It just illustrates some of the
registration/deregistration concepts.
So what are we trying to accomplish?
Our adopters are interested in using COSMOS to build MDRs
and/or
Federating CMDBs. I think our goal should be to provide tools to assist
them with their implementations. IMHO, this means providing samples and
utilities to help them implement the push and pull modes of the CMDBf
Registration spec. I suggest this approach:
1. Remove all non-standard API from the test federating CMDB, as you
suggested. Then add an exemplar pull mode implementation.
2. Add an exemplar push mode implementation to the Example MDR that
works in conjunction with the test federating CMDB.
3. Both 1 and 2 should utilize our existing cmdbf services, which may
need to be enhanced for more registration utilities.
I'm not sure how the UI fits into the above approach. Maybe it
can drive the test federating CMDB and example MDR though an
administrator interface.
Regards
Bill
-----Original Message-----
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Hubert H Leung
Sent: Wednesday, March 05, 2008 2:58 PM
To: Cosmos Dev
Subject: Re: FW: [cosmos-dev] RE: CMDBf registration questions
The forwarded email thread deals with the issue of tracking the state of
registered items, which is different from the comment I made this
morning.
My comment was about whether the COSMOS UI is implementing the push mode
or
the pull mode, or some of both.
The UI initiates the registrating request, and hence it is a
registration
client. By definition, the usecase is the push mode. However, the
register operation of the CMDBf registration server is never invoked by
the
UI. Instead, the operation registerMDREntries is invoked. It is a
COSMOS
API at the federating CMDB for registering all items from an MDR. The
federating CMDB that queries the MDR for a list of items, using the
CMDBf
query service at the MDR. Note that the federating CMDB only needs to
make
CMDBf queries during a pull mode. With the list of items returned from
the
query, the federating CMDB does the registration, and returns the CMDBf
registration request reponse to the UI (registration client). i.e. the
response of the COSMOS API registerMDREntries is the CMDBf registration
response message. This response is what I expect to get in a pull mode
of
registration. Our code exhibits the behaviors of both pull mode and
push
mode.
Here is my view of the proper implementation:
Making registrations from the UI uses the push mode. The implementation
should strictly use the push mode. Registration is done via the
registration service at the federating CMDB. It is a standard API from
CMDBf. So the registration client can talk to a federating CMDB from
any
vendor. "Register all items and relationships available" is a use case
invented by COSMOS. (I would think it has no use in production
environment.) The UI needs to get the list of items and relations from
the
MDR, and send the CMDBf registration request to the federating CMDB.
Upon
receiving the request from UI, the federating CMDB will do the
registration
and return the accept/reject status to the UI using the CMDBf
registration
response standard.
Changes I suggest include:
1. Remove all non-standard API from the federating CMDB. There should
only
be two methods in IFederatingCMDB - register and deregister. It will
also
help keeping the test federating CMDB simple. Remember hat we don't
really
provide a federating CMDB. It's just a dummy test harness.
2. The tasks of querying the MDR and the creation of the registration
message should be done by the UI.
3. The UI invokes the registration service of the test federating CMDB.
I have another use case that uses the push mode from an internal
adopter,
which does not involve the UI. At the MDR, there is an agent that
listens
for changes in the data to be federated. Upon each update, the agent
will
send a CMDBf registration message to the federating CMDB. The agent
knows
about the list of items without doing a CMDBf query.
The bottom line is: the federating CMDB should only expose the query
and
registration (register and deregister) services. The outside world will
always use standard service APIs to interact with the federating CMDB.
In the pull mode, the federating CMDB initiates the federation. The
federating CMDB uses CMDBf queries to get the list of items to be
registered from known MDRs. It can be configured to pull data
periodically. The UI can use the query service at the federating CMDB
to
get the list of registered items and relationships, and display them at
the
browser. My understanding is that the CMDBf registration service is not
used in the pull mode.
Any comments?
Thanks,
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
"Muldoon, William
H"
<William.Muldoon@
To
ca.com> Hubert H Leung/Toronto/IBM@IBMCA
cc
03/05/2008 12:11 "Cosmos Dev"
PM <cosmos-dev@xxxxxxxxxxx>
Subject
FW: [cosmos-dev] RE: CMDBf
registration questions
Hubert
FYI: the COSMOS ?hybrid? registration approach that you
mentioned
on today?s call was previously discussed in this thread.
Regards
Bill
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Muldoon, William H
Sent: Thursday, February 07, 2008 1:31 PM
To: Cosmos Dev
Subject: FW: [cosmos-dev] RE: CMDBf registration questions
FYI: Forwarding from Mark J.
From: Mark Johnson [mailto:mwj@xxxxxxxxxx]
Sent: Thursday, February 07, 2008 1:20 PM
To: Muldoon, William H
Cc: Ali Mehregani; Feldman, Andrew A; Jacob Eisinger; Mohsin, Jimmy;
Waschke, Marvin G; Troy Volin
Subject: RE: [cosmos-dev] RE: CMDBf registration questions
Everyone,
(Feel free to forward on to cosmos-dev)
Marv and I had a side exchange and I'd like to sum up what is required
by
an implementation of the spec. The CMDBf spec is intended to be useful
across a range of configurations, so I'm attempting to avoid too many
subjective statements.
The expected behavior defined in the spec (lines 1531-1536) is
that
once an MDR has registered data using a given mdrInstanceId, it is
expected to maintain that data using the same instance ID,
including
deregistering the ID if it is no longer valid. If it cannot do
that,
and wishes only to have its data available for query, it should
not
use the registration service.
The MDR must not make any assumptions about whether data it sends
with a new instance ID reconciles to any data it sent previously.
This is because the registration service may not even have a
reconciliation function, or it might be configured to not perform
reconciliation on certain types of data, or perhaps the data
itself
has changed enough that the results of a reconciliation algorithm
yield different results, or any other reason.
The freshness of the data in the Federated CMDB depends on the
capabilities of the F-CMDB and MDR implementations and how they
are
configured. This applies to both push and pull mode, though an MDR
that pushes data is better positioned to initiate an update
immediately rather than a F-CMDB that periodically polls for
changes.
Note that it is perfectly acceptable for a registration client to
periodically reregister all the data that has been previously
registered. If nothing has changed, including potentially even
the
<recordMetadata>/<lastModified> element, and the F-CMDB has not
been
corrupted, the registrations would be treated as updates, which in
this case don't change anything.
Regards,
Mark
Mark W Johnson
Tivoli Advanced Technology
CMDB Federation standard; ARM standard
IBM
512-838-0496 (office)
512-699-9105 (cell)
Mark Johnson/Austin/IBM
mwj@xxxxxxxxxx
"Muldoon,
William H"
<William.Muld
oon@xxxxxx>
To
"Waschke, Marvin G" <Marvin.Waschke@xxxxxx>, Mark
Johnson/Austin/IBM@IBMUS
02/07/2008
cc
09:59 "Ali Mehregani" <amehrega@xxxxxxxxxx>, "Feldman,
Andrew
A" <Andrew.Feldman@xxxxxx>, "Cosmos Dev"
<cosmos-dev@xxxxxxxxxxx>, Jacob
Eisinger/Austin/IBM@IBMUS, "Mohsin, Jimmy"
<Jimmy.Mohsin@xxxxxx>, Troy Volin/Durham/IBM@IBMUS
Subject
RE: [cosmos-dev] RE: CMDBf registration questions
Hi Marv and Mark J
Thank you both for your quick responses!
Mark W & Cosmonauts
Given the range of behavior from ?crappy? MDRs to
intelligent
MDRs, I think we should strive to produce MDRs that are on the more
intelligent end of the scale, correct? I propose the following approach:
1. In the i9 iteration, we continue with 214672 as designed,
resulting in an MDR that does not maintain the integrity of the
registration.
2. In the i10 iteration, we implement a COSMOS specific MDR
interface that enables COSMOS MDRs to maintain the integrity of the
registration. This interface will be used by the COSMOS UI to update the
internal registration table of the COSMOS MDR. The ?helper plumbing?
will
facilitate this feature. In addition the COSMOS UI should issue a
warning
to the user if the new interface is not supported.
As a result, COSMOS MDRs will work well with the COSMOS UI registration
feature but non-COSMOS MDRs will receive warnings when used with the
COSMOS
UI registration feature.
In the future when the CMDBf spec supports notifications, we can
deprecate
the COSMOS specific interface and use the future COSMOS Event Broker to
support the CMDBf notifications to maintain registration integrity.
Regards
Bill
From: Waschke, Marvin G
Sent: Wednesday, February 06, 2008 6:34 PM
To: Mark Johnson
Cc: Ali Mehregani; Feldman, Andrew A; Cosmos Dev; Jacob Eisinger;
Mohsin,
Jimmy; Troy Volin; Muldoon, William H
Subject: RE: [cosmos-dev] RE: CMDBf registration questions
Comment below.
Marvin Waschke
Senior Technology Strategist
Service Management
Tel: +1 360 383 9022
Mobile: +1 425 269 5592
Marvin.Waschke@xxxxxx
Blog: Iterating on IT Service
(Embedded image moved to file: pic23578.gif)
From: Mark Johnson [mailto:mwj@xxxxxxxxxx]
Sent: Wednesday, February 06, 2008 1:58 PM
To: Waschke, Marvin G
Cc: Ali Mehregani; Feldman, Andrew A; Cosmos Dev; Jacob Eisinger;
Mohsin,
Jimmy; Troy Volin; Muldoon, William H
Subject: RE: [cosmos-dev] RE: CMDBf registration questions
Marv, et. al.,
See responses embedd using <mwj> this style. </mwj>
Regards,
Mark
Mark W Johnson
Tivoli Advanced Technology
CMDB Federation standard; ARM standard
IBM
512-838-0496 (office)
512-699-9105 (cell)
Mark Johnson/Austin/IBM
mwj@xxxxxxxxxx
"Waschke,
Marvin G"
<Marvin.Wasch
ke@xxxxxx>
02/06/2008
To
15:19 "Muldoon, William H" <William.Muldoon@xxxxxx>,
"Cosmos
Dev" <cosmos-dev@xxxxxxxxxxx>
cc
Mark Johnson/Austin/IBM@IBMUS, Troy
Volin/Durham/IBM@IBMUS, "Ali Mehregani"
<amehrega@xxxxxxxxxx>, Jacob
Eisinger/Austin/IBM@IBMUS,
"Feldman, Andrew A" <Andrew.Feldman@xxxxxx>, "Mohsin,
Jimmy" <Jimmy.Mohsin@xxxxxx>
Subject
RE: [cosmos-dev] RE: CMDBf registration questions
I will probably confuse things by asking more questions than providing
answers.
First, I think it is possible, although probably not desirable, to
maintain
a push mode federation without the MDR ever getting any feedback from
the
federating CMDB. Leaving COSMOS out of the picture for a second, the
steps
go:
1. MDR calls the fed-CMDB to register an item with an mdrId of
?MDR-A?, instanceId of ?1? and one reconciliation property
<name>One</name>.
2. fed-CMDB accepts the registration and returns
<instanceResponse>
<instanceId><mdrid>MDR-A</mdrid><id>1</id></InstanceId>
<accepted/>
</instanceResponse>
3. MDR throws away the response
At this point the fed-CMDB has a record of an item with name ?One? and
scoped instance id of ?MDR-A 1? With that knowledge, it can (if it wants
to
and the MDR has a query service) query the MDR for its information on
?MDR-A 1?. Alternatively, the fed-CMDB can query for information on
items
with property ?name? equal to ?One?. The only requirement on the MDR is
that whenever it responds to a query on ?MDR-A 1?, it must reply with
data
on the item it originally registered as ?MDR-A 1?. In other words, the
only requirement on the MDR would be to never use ?1? as the id for any
item but the item named ?One?.
The MDR could, if it were sufficiently crappy, simply never use ?MDR-A
1?
again and not answer queries on ?MDR-A 1?. It could, if really crappy,
even
register the same item with a different id, say ?2?. That registration
would be something like this:
<registerRequest>
<mdrId>MDR-A</mdrId>
<item>
<record>
<name>One</name>
</record>
<instanceId><mdrId>MDR-A</mdrId><id>2</id></instanceId>
</item>
</registerRequest>
A sharp fed-CMDB would reply:
<instanceResponse>
<instanceId><mdrid>MDR-A</mdrid><id>2</id></InstanceId>
<accepted/>
<alternateInstanceId><mdrId>MDR-A</mdrId><id>1
</id></instanceId>
</instanceResponse>
>From which we can infer that the fed-CMDB reconciled both registrations
as
referring to the same item.
<mwj> However, the MDR is obliged to report future state changes to
MDR-A:1
as well as MDR-A:2. The MDR must not assume that the F-CMDB reconciles
the
items together. Whether it does is dependent on the F-CMDB
implementation,
how it is configured (e.g., local policy *could* state never reconcile
anything with record type foo), etc. </mwj>
The point is that MDR-A can be as dumb as a post, paying no attention to
what it has done before and still play by the rules. It could, rather
than
notifying the fed-CMDB every time an item which it has registered has
changed, just re-register periodically, not even bothering to use the
same
instance id. Again, a crappy MDR, but sometimes, an MDR that is no more
than a few flat files on somebody?s desktop may be useful.
<mwj> I don't agree. If the F-CMDB returns <accepted>, then the MDR is
obliged to maintain the data for the <mdrInstanceId> that it registered.
It
is not obliged to use the returned CMDB:id. The ability for an MDR to
continue using its own IDs removes a potentially show-stopping
requirement
from the MDR. We expect that MDRs that only use their own IDs will be
common when existing products add an MDR layer and don't want to do
things
like modify their database schema, etc. The CMDB:id is returned because
there were requirements from some MDRs to replace their own ID with the
official ID from the CMDB. </mwj>
[MW] Why oblige the MDR to maintain the data for the <mdrInstanceId>? I
can
see recommending that the MDR maintain a unique id and always register a
change with that <mdrInstanceId> when the MDR?s data on an item changes,
but requiring it? The system will work even if it is not required?the
data
from a dumb MDR will always be somewhat suspect, but at least it will be
there. Data from a push model MDR that has no query service is pretty
shaky
anyway. What if the MDR has been down for a week? Or just unreachable?
Unless you can query the MDR you will never be certain that the
registered
data is not stale. </MW>
This is not to say that building helpers that keep track of what is
registered and help an MDR maintain the integrity of the fed-CMDB would
not
be useful, only that dumb MDRs would not need them.
I have always thought that responsibility for the integrity of the data
falls mainly on the fed-CMDB through query services implemented by the
MDRs. For high integrity data, the fed-CMDB should always query the MDR
or
MDRs when a request for data comes to the fed-CMDB. When a task being
performed by the user of the fed-CMDB requires speed at the expense of
the
risk of stale data, then the fed-CMDB might only return whatever
happened
last to be registered, and skip the query. There are lots of trade-offs
possible, which is a nice part of this architecture.
Mark Johnson?Speak up if I am all wet!
<mwj> OK. :-> </mwj>
Regards, Marv
Marvin Waschke
Senior Technology Strategist
Service Management
Tel: +1 360 383 9022
Mobile: +1 425 269 5592
Marvin.Waschke@xxxxxx
Blog: Iterating on IT Service
(Embedded image moved to file: pic17304.gif)
From: Muldoon, William H
Sent: Wednesday, February 06, 2008 11:52 AM
To: Cosmos Dev
Cc: Mark Johnson; Troy Volin; Ali Mehregani; Jacob Eisinger; Waschke,
Marvin G
Subject: RE: [cosmos-dev] RE: CMDBf registration questions
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:
1. COSMOS MDR invokes the CMDBf registration interface on the
federating CMDBf using the COSMOS ?helper? plumbing.
2. COSMOS MDR receives the CMDBf registration response and uses
the
COSMOS ?helper? plumbing to track the registration.
3. 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
(Embedded
image moved to
file:
pic05727.gif)
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@IB
MCA
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 _______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev
_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev
