+1
-----Original Message-----
From:
cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark D Weitzel
Sent: Thursday, August 16, 2007
10:58 AM
To: Cosmos Dev
Cc: Cosmos Dev;
cosmos-dev-bounces@xxxxxxxxxxx
Subject: RE: [cosmos-dev] Things
that make yougo hummmm....Ce quinous appelons la <<Data Broker>>
I agree there is a base "Broker"
functionality. This is what I was getting at in my other post regarding
the bugzilla enhancement requests.
Where
I see some of the specialization is in what kinds of things it
"brokers", in this case data managers, but also in the lifecycle
events that it may (eventually) emit and potentially a distinct set of
operations. For example, we may want convenience API
getDataBroker(someTypeOfQueryString) vs. a getResourceProperty or the generic
RC query.
-mw
_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing | (919)
543 0625 | weitzelm@xxxxxxxxxx
"Hawkins, Joel"
<Joel.Hawkins@xxxxxxxxxxxxx>
Sent
by: cosmos-dev-bounces@xxxxxxxxxxx
08/16/07 10:47 AM
Please
respond to
Cosmos Dev <cosmos-dev@xxxxxxxxxxx>
|
|
To
|
"Cosmos Dev"
<cosmos-dev@xxxxxxxxxxx>
|
cc
|
<cosmos-dev-bounces@xxxxxxxxxxx>
|
Subject
|
RE: [cosmos-dev] Things that make you go
hummmm....Ce quinous
appelons la <<Data Broker>>
|
|
My 2 cents… we don’t have to call it “DataBroker”
in the code. We can implement a set of base “Broker” functionality and then
specialize it (either declaratively or programmatically) to support “Data”,
“Service”, “Stock”, whatever.
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.
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On
Behalf Of Mark D Weitzel
Sent: Thursday, August 16, 2007 10:39 AM
To: Cosmos Dev
Cc: Cosmos Dev; cosmos-dev-bounces@xxxxxxxxxxx
Subject: RE: [cosmos-dev] Things that make you go hummmm....Ce
quinous appelons la <<Data Broker>>
Yes.
Expanding the thought....
The Management Domain is there simply as a bootstrapping mechanism. It
should contain a well known set of things (gag, not the word services) that can
be asked for, e.g. its data broker, notification broker. It should
contain only these well known, well defined things.
Likewise, the Data Broker should be responsible for only Data Managers.
If we need a way to register and look-up arbitrary services, then we can
introduce a "Service Broker". This may also be a reasonable
extension mechanism. That is, we want people to be able to easily provide
additional value. Having a way to register custom, value added services
is a reasonable way to do this. That said, in keeping with Jimmy's focus
on i6, the COSMOS use cases we've defined so far we can get away with just the
Management Domain and the Data Broker.
-mw
_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing | (919)
543 0625 | weitzelm@xxxxxxxxxx
"Todd, John A"
<John.Todd@xxxxxx>
Sent by: cosmos-dev-bounces@xxxxxxxxxxx
08/16/07 10:15 AM
Please
respond to
Cosmos Dev <cosmos-dev@xxxxxxxxxxx>
|
|
To
|
"Cosmos Dev"
<cosmos-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [cosmos-dev] Things that make you go
hummmm.... Ce quinous appelons
la <<Data Broker>>
|
|
So when a “Service Manager” comes into focus and we decide what that is
exactly, it’ll have its own ‘Broker’ potentially called a ‘Service Broker’
which will be independant of Data Brokers?
- John
From: cosmos-dev-bounces@xxxxxxxxxxx
[mailto:cosmos-dev-bounces@xxxxxxxxxxx] On
Behalf Of Mark D Weitzel
Sent: Thursday, August 16, 2007 10:09 AM
To: Cosmos Dev
Cc: Cosmos Dev; cosmos-dev-bounces@xxxxxxxxxxx
Subject: Re: [cosmos-dev] Things that make you go hummmm.... Ce
quinous appelons la <<Data Broker>>
Jimmy,
We should not broaden the scope of the "Data Broker". The role
of this component should be only to provide you an EPR of a "Data
Manager".
One of the key reasons for keeping the function focused is that we want a well
defined collection that can be placed in the Management Domain.
One of the things that we need to describe is the initialization of the Data
Manager and the Client.
>From the Client's perspective, I see it going to a specific Management
Domain and asking: "Give me my Data Broker". It gets back the EPR
that it can now query in a well defined way. If we don't partition the
responsibilities of the collection of resources, then we'll end up with just a
Management Domain and a whole bunch of queries against it. Our
interactions should be more refined than this.
I've put some design assumptions on the use case page regarding broker
initialization (http://wiki.eclipse.org/DataBrokerInitialization).
I've also started the design of the Management Domain
(http://wiki.eclipse.org/COSMOS_Design_197868).
-mw
_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing | (919)
543 0625 | weitzelm@xxxxxxxxxx
"Mohsin, Jimmy"
<Jimmy.Mohsin@xxxxxx>
Sent by: cosmos-dev-bounces@xxxxxxxxxxx
08/15/07 06:40 PM
Please
respond to
Cosmos Dev <cosmos-dev@xxxxxxxxxxx>
|
|
To
|
"Cosmos Dev"
<cosmos-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
[cosmos-dev] Things that make you go
hummmm.... Ce qui nous appelons la <<Data
Broker>>
|
|
All,
Maybe a rhetorical question…
1. Till date, we have been calling our COSMOS DC broker
a “Data Broker”.
2. It is now more and more clear that the “Data Broker”
does not merely deal with data; but it deals with WSDM EPRs, underneath which
could be Data Managers OR “Service Mangers / Providers”.
3. Given the critical/central nature of our “Data
Broker”, is it appropriate to even call it a “Data Broker” ? Or should it
have a name that captures its WIDER
brokering capabilities?
4. If you agree with this characterization, any
suggestions for a new name?
Thanks,
Jimmy Mohsin
+1-609-635-1703
_______________________________________________
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
_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev