[cosmos-dev] Fw: Service Broker versus Data Broker - Introducing a "Serv

[Mark D Weitzel <weitzelm@xxxxxxxxxx>]

Jimmy,

A couple of thoughts/questions....

I think you are right in that, functionally,
there is not much difference b/t a "Data Broker" and a "Service
Broker".  The main role of both is to facilitate lookups and
return an endpoint.  The "Brokers" themselves do not and
should not much more than that.

There is a general "Broker"/"Lookup"
pattern.  That is, we need to maintain collections of EPRs and the
like and be able to retrun them

From that perspective, I see a gerneralized
"Service Broker".  Maybe Joel is right, this is nothing
more than the implementation of WS-RC.  My thinking is that this is
WS-RC and maybe an additional capability that we define.  In this
context, I'm using capability in the WSDM sense to represent a named collection
operations, attributes, and events.

The Management Domain shold be a specialized
service broker.  It should have a well defined collection of services
(as properties) that it makes available.  Therefore, when I'm an EPR
that is starting up, I can do a getResourceProperty("http://org.eclipse.cosmos/DataBroker")
on my management domanin and get back the databroker I'm supposed to use.
 

The Data Broker should be a specialized
service broker that may hold onto ONLY data managers.  There may be
additional capabilities that we offer on the data broker.  So while
the Data Broker doesn't know data managers, we can (and should) limit what
goes int this broker.  Before WS-RC, I thought of this as a service
group with content rules.   


Now, it's true, we could smush all these
things together under a single "broker", but I don't think this
is the right thing to do.  For example, in some of the use cases that
we talk about below, there is the notion of the an OMP talking to the service
broker to find a help desk kind of thing.  It's ok for us to have
a service broker, and it's reasonable for adopters to add their own services
to it.  But we should not combine this with the collection of data
brokers.


Re, the enahncement request....  
We already have one open:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=197869
There is a wiki page for the design
as well:  http://wiki.eclipse.org/COSMOS_Design_197869

I think the real question is: how many enhancements do we need?  
I would like to keep what we have for
the following reasons:

* The service broker can be for the
generic "brokering" case.  This should be where we tie in
the WS-RC design.
* The Management Domain should be a
service broker with additional capabilities and a well defined set of contained
services
* The Data Broker should be a service
broker with additional capabilities for handling queries to find data brokers.


_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing
| (919) 543 0625 | weitzelm@xxxxxxxxxx
----- Forwarded by Mark
D Weitzel/Raleigh/IBM on 08/13/07 01:40 PM -----

"Craddock, Chris" <Chris.Craddock@xxxxxx>

08/13/07 12:49 PM

To	"Hawkins, Joel" <Joel.Hawkins@xxxxxxxxxxxxx>, "Mohsin, Jimmy" <Jimmy.Mohsin@xxxxxx>, "Stratton, Paul" <Paul.Stratton@xxxxxx>
cc	"Marootian, Edward" <Edward.Marootian@xxxxxx>, Mark D Weitzel/Raleigh/IBM@IBMUS, "Ebright, Don" <Don.Ebright@xxxxxxxxxxxxx>
Subject	RE: Service Broker versus Data Broker - Introducing a "Service Manager" AND do we need a new enhancement request for this concept ?

EXACTLY!!
 
Chris Craddock
SVP, Principal Technology Strategist
Office of the CTO
Cell   281-770-1950

---

From: Hawkins, Joel [mailto:Joel.Hawkins@xxxxxxxxxxxxx]
Sent: Monday, August 13, 2007 11:46 AM
To: Mohsin, Jimmy; Craddock, Chris; Stratton, Paul
Cc: Marootian, Edward; Mark D Weitzel; Ebright, Don
Subject: RE: Service Broker versus Data Broker - Introducing a "Service
Manager" AND do we need a new enhancement request for this concept
?
 
Jimmy,
 
I think of them WSDM Endpoints
 ;-). You can introspect them to resolve individual capabilities.
As a matter of fact, if we decide to implement the DataBroker using WSRC,
then we could just toss the service EPRs in right next to the data manager
EPRs, and just use the RC’s folder structure to delineate. To me, the
key value proposition here is the combination of a WSDM Endpoint catalog
that can be queried based on graph-oriented relationships contained in
a CMDB. 
 
Cheers,
Joel
 
-----Original Message-----
From: Mohsin, Jimmy [mailto:Jimmy.Mohsin@xxxxxx] 
Sent: Monday, August 13, 2007 12:39 PM
To: Hawkins, Joel; Craddock, Chris; Stratton, Paul
Cc: Marootian, Edward; Mark D Weitzel; Ebright, Don
Subject: RE: Service Broker versus Data Broker - Introducing a "Service
Manager" AND do we need a new enhancement request for this concept
?
 
Joel,
 
But then, the question still remains:
what do we call the constructs sitting under the EPs that a Service Broker
interacts with?  Do we still “think” of them / refer to them as
Data Managers? Or are they something else?
 
Indeed, I do not see as a major
coding delta; but more of an architectural delineation.
 
Thanks,
Jimmy Mohsin
+1-609-635-1703

---

From: Hawkins, Joel [mailto:Joel.Hawkins@xxxxxxxxxxxxx]
Sent: Monday, August 13, 2007 12:29 PM
To: Mohsin, Jimmy; Craddock, Chris; Stratton, Paul
Cc: Marootian, Edward; Mark D Weitzel; Ebright, Don
Subject: RE: Service Broker versus Data Broker - Introducing a "Service
Manager" AND do we need a new enhancement request for this concept
?
 
Ahhh. But the DataBroker doesn’t
really know DataManagers, either. It just knows Endpoints. Sounds like
two birds, one stone. I don’t think this will be a lot of work, which
to quote Martha, is “a good thing”. ;-)
 
Cheers,
Joel
 
-----Original Message-----
From: Mohsin, Jimmy [mailto:Jimmy.Mohsin@xxxxxx] 
Sent: Monday, August 13, 2007 11:45 AM
To: Hawkins, Joel; Craddock, Chris; Stratton, Paul
Cc: Marootian, Edward; Mark D Weitzel; Ebright, Don
Subject: RE: Service Broker versus Data Broker - Introducing a "Service
Manager" AND do we need a new enhancement request for this concept
?
 
Hi Joel,
 
1.
 The Service Broker (Bugzilla –
Bug 197869) was envisioned to support some of the event-centric use cases.
 The idea was to have the Broker manage functional behavior (as opposed
to pure data collection).
2.
 Again, BOTH the Data and Service
Broker would use VERY similar code; however, what they look-up is different.
 The Data Broker knows about Data Manager; the question becomes what
does the Service Broker “know” about?  Obviously, it is not going
to be Data Managers.
3.
 As an example, one of our use cases
entails a non-interactive ticket being created in our ticketing system,
based on some information that is known to the Network / Systems Management
NSM product.  In this scenario, the NSM product is the primary actor.
 NSM needs to be able to talk to a Service Broker, and locate a component
(dare I say a “Service Manager”) that is able to open a ticket REMOTELY
/ automagically in the ticketing system.
4.
 We should talk about this in our
next call, as MANY of our high value use cases rely on this.  We can
also ask Hubert to talk about his event-centric use case that he mentioned
last week.
 
Thanks,
Jimmy Mohsin
+1-609-635-1703

---

From: Hawkins, Joel [mailto:Joel.Hawkins@xxxxxxxxxxxxx]
Sent: Monday, August 13, 2007 11:26 AM
To: Mohsin, Jimmy; Craddock, Chris; Stratton, Paul
Cc: Marootian, Edward; Mark D Weitzel; Ebright, Don
Subject: RE: Service Broker versus Data Broker - Introducing a "Service
Manager" AND do we need a new enhancement request for this concept
?
 
Jimmy,
 
Can you give me some idea of
what the service broker would do? How is it notionally different from the
Data Broker, other than in the type of endpoints it may provide? Can you
give me some insight into what kind of problems Hubert’s run into that
require a Service Manager? Please take a look at the comments I posted
for the DataBroker design regarding the reconciliation of the CMBDf Query
API with the DataBroker – is what’s needed just the Collection side of
this issue?
 
Thanks,
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: Mohsin, Jimmy [mailto:Jimmy.Mohsin@xxxxxx] 
Sent: Monday, August 13, 2007 12:52 AM
To: Craddock, Chris; Stratton, Paul
Cc: Marootian, Edward; Mark D Weitzel; Ebright, Don; Hawkins, Joel
Subject: Service Broker versus Data Broker - Introducing a "Service
Manager" AND do we need a new enhancement request for this concept
?
Importance: High
 
Gents,
 
Shades of Rosetta creeping into
the COSMOS DC world… In a COSMOS call about two weeks ago, folks agreed
on the need to have a Service Broker, based on some of the MR 2 use cases…
 Hubert has actually run into the same issue due to some of their
event based use cases.  However, there are MANY downstream (or upstream,
depending on how you look at it) architectural implication of having a
Service Broker.
 
The FIRST question: what does
a Service Broker interact with?  Obviously, there is the Managements
Domain on one side; but what is on the other side???  Let the games
begin J…
 
For now, I am calling it a “Service
Manager”… We need to define the Service Manager…. And then see if there
is the need for an animal called “Service Adapter”….
 
Thanks,
Jimmy Mohsin
+1-609-635-1703

---

From: Mohsin, Jimmy 
Sent: Monday, August 13, 2007 12:47 AM
To: 'Cosmos Dev'
Subject: Service Broker versus Data Broker - Introducing a "Service
Manager" AND do we need a new enhancement request for this concept
?
Importance: High
 
Dear All,
 
For some of our event-centric use cases,
the need for a Service Broker has been brought up and this concept has
been discussed in several of our prior meetings.
 
As we all know, a Data Broker interacts with
multiple Data Manager to fulfill data related requests.
 
What does / should a Service Broker interact
with?  Will we call it a “Service Manager”?
 At then end of the day, this is all about managing functional behavior
(as opposed to Data Collection).
 
What will a Service Manager “look“like?
 Are there any specific consideration we need to discuss for a Service
Manager, a la those we discussed for a Data Manager?  Do we ALSO need
to create an enhancement request for a “Service Manager” ?
 
Thanks,
Jimmy Mohsin
+1-609-635-1703