| RE: [cosmos-dev] COSMOS Architecture Meeting Today! |
|
<nag> “It depends”. Products have
different interaction models depending on what problem they are trying to solve
at the time. So for example, many of our own products consume alerts and events
of one form or another and produce some sort of (usually abstract) visualization
over those events. Then they might drill down on a particular event –
hopefully going back to the event producer in some context that allows for
problem solving or further analysis. At other times you might just be gathering
data from several products to make some sort of management or planning
decision. In each situation you tend to go from higher level abstractions to
low level concrete instances. The questions shift from general ones to specific
ones and the product that’s doing the asking needs to be more intimately
familiar with the data and capabilities being offered by the product that
actually does the low-level work. So in thinking about query services they
probably fall into two broad categories. In each of these cases I am talking
about data getters rather than data putters, but the interfaces are essentially
the same and it simplifies the discussion to focus on the getters. The first category would be about identity
and relationships. At this level we’re still thinking pretty abstractly. “Are
there any instances of the FUBAR product running?” or “Give me an
EPR for an MR that advertises a FUBAR capability” and once you have one
of those you may want to ask that instance questions about its relationships with
other managed resources. All of these interactions are properly in the realm of
WSDM and would be handled pretty simply through those mechanisms. I don’t
want us to invent anything new in that area, or if we do it ought to be
something like a set of “best practices” for MR providers to follow. The second category would be some deeper
introspection on MRs that you found via the first level lookup. When you get
down to this level you’re beginning to get into more concrete situation –
you have an end point that has advertised some set of capabilities that you’re
looking for and now you need to interact with it to solve your problem. It’s
not realistic to construe this level of interaction as a general purpose
fishing expedition. Both sides of the communication need to understand the menu
of data and capability (function) that is exposed via the interface contract –
but not the underlying implementation. That can and should remain private to
the implementer. In terms of DATA interfaces you end up
with essentially two flavors; (1) XPATH/XML query expressions where you get a
document back and hopefully both sides understand the schema and (2) some
flavor of XML/SQL where you still get back a document, but its composed of the
rows forming the result set. It may be necessary for the interface to provide
some transformational capabilities to line up the expectations of the producer
and consumer of the data but that’s also well within the realm of current
XML technologies. In terms of actual operations over the
data you ought to look at SQL as a model since it purports to be a general data
manipulation language. The key (no pun intended) primitives are select, insert,
update, delete and regardless of the shape of the underlying data, those seem
(to me) to be the complete set. I am deliberately omitting discussion of DDL,
schemas etc. The models and schemas are within the COSMOS scope and presently
they are anticipated to be some formulation of SML and SML-IF. It’s not
entirely clear to me at this stage what those things would look like exactly
but I’m willing to do a little hand-waving over it for now. Not sure whether I’ve answered your
question or not, but those are my thoughts of record. Chris Craddock SVP,
Principal Technology Strategist Office
of the CTO Cell
281-770-1950 |