| RE: [cosmos-dev] question on management domain and brokers |
|
I think that we can keep it fairly simple and perhaps
even let most clients be unaware of the existance of multiple data
brokers.
There are several reasons why a customer might have
multiple brokers, but in many cases the interests of client software
will split along the same boundaries. For example, a customer may
install multiple independent products or suites with embedded
brokers. Large customers will install multiple instances of a product
because of differing scopes of control such as regional data
centers.
The domain should be aware of these sorts of scoping
information associated with each broker and make it available on request.
Preferably the client should be able to query for brokers by location
or data type. We could let the query default to "my location"
and "my product's data" so clients that don't need to aggregate data from
multiple brokers would automatically find the broker that is most likely to be
appropriate.
The scoping information for the brokers could reside
in the CMDB or it could just be part of the configuration of the broker
itself.
Regards,
Don
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From:
cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On
Behalf Of Hawkins, Joel
Sent: Thursday, July 19, 2007 9:04 AM To: Cosmos Dev Subject: RE: [cosmos-dev] question on management domain and brokers Hmmm. Well, if we can
assume that the MD and the DBs are somehow reflected
in the CMDB, then we can make the CMDB identities part of the handshake
protocol. Then we can place the responsibility squarely in the MD’s lap (which
it can shovel off to the CMDB for sophisticated deployments) and well can get as
wacky as we like in the CMDB for modeling things like fail-over, etc. of our
infrastructure. That also means we can
reuse the sml editor (and whatever it becomes) as our
configuration editor. GUI jujitsu.
;-) Cheers, Joel The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
Joel, I
understood that there could be multiple DataBrokers(DB) too, and multiple
ServiceBrokers. (SB) For
that to work, it has to be the function of the ManagementDomain(MD) to tell the
requestor the name of the DatBroker(s) to use. As yet, I don’t think it
has been defined how that mechanism should work. Does the MD make the
decision as to what it tells the requestor, or does it give the requestor all
the DataBrokers and let the Requestor decide? I think it should be the MD,
as it is after all, the Manager. So How would the MD do this ?
Perhaps there is always a default broker, and that is the one that is sent back
to the requestor, unless the MD accepts some parameter from the requestor, that
can influence the MD into giving the requestor back a non-default
broker. Martin... From:
cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Hawkins, Joel Martin, Does “the
DataBroker” mean that DataBrokers follow the Highlander model (there can only be
one)? I thought we were going to support multiple DataBrokers so that people
could partition there monitoring infrastructure in some user-defined hierarchy
(preferably one that was reflected in their CMDB).
Cheers, Joel
|