Comments
inline.
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. <Joel>That’s
not quite what I meant. What I tried
to imply is that we could house our brokers in a WS-RC implementation, but we’d
want to front-end them with our additional capabilities. From a pure WS-RC spec
point of view, we could distinguish the types of services by using the catalog
structure mechanisms presented by the spec, but I don’t think WS-RC is
enough for what we need to do in and of itself. I think we require an
implementation of the CMDBf query interface in order
to support richer queries with real semantic content. Since to an external
consumer, WS-RC just looks like another capability supported by the broker
endpoint, there’s nothing implying that it’s the only (or best) way
to perform catalog queries. </JOEL>
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.
<Joel>These distinctions sound like a simple case of filtering –
basically something that could be handled declaratively. I’m arguing for adopting
a convention in our usage of the WS-RC catalog structure.</Joel>
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. <Joel>Can and Should are two
different things. There’s no reason we couldn’t support a single
broker instance presenting multiple faces. In fact, I can predict that we’ll
want exactly this for our next “all in one” demo, but of course
that’s a demo – not the only (or even preferred) way to deploy
COSMOS. <Joel>
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. <Joel>If we choose to, we can support all of these
queries with a single implementation, that being the CMDBf
query implementation required for implementing an MDR.</Joel>
