Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cosmos-dev] Things that make yougo hummmm....Ce quinous appelons la <<Data Broker>>

+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


Back to the top