[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cosmos-dev] Things that make you go 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