[
Lists Home |
Date Index |
Thread Index
]
Hi Joe:
Ok. Yes. The portal is the front man for the middlemen and the main man.
;-)
The authenticated user (identity management) has already been assigned the
role, privileges and scope so all they can do is query what they are
pre-authorized to query. In effect, it is a report generator implemented
much as we already implement such things for secure systems.
Umm... I thought the point of discovery and metadata services was to
describe a service that is available and to ensure that the data exposed
to the interface is and only is precisely what the offeror offers, not
to enable discovery below that level. If the other web service has
discovered what is enabled for it based on its role, then it is trying
to complete something that it hasn't asked for before; iow, it is at
the point of a negotiation and may need a new or new-to-it service.
I confess to having my brain wrapped around the Markle reports so I may
be not making good sense of your example.
len
-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Wednesday, September 22, 2004 3:48 PM
Hi Len,
I should be clearer: I was actually thinking of a different type of
querying than ad hoc. I see ad hoc querying (as you know) as a type of
query in which the queryer (is that a word?) is presented with a user
interface (such as a portal) that may present drop-down lists of various
category values (based on a set of taxonomies) from which they select,
or use some type of textual query, etc. In such cases, there is full
knowledge of the database schema by the entity that is requesting the
information (e.g. the application code or ad hoc query tool behind the
portal).
My example was one in which the request for information (the additional
needed information) was made by an entity (the Hotel Reservation Web
Service) that had no knowledge whatsoever of the "source" database
schema - it just knows that it is missing information that it requires.
So it seems to me that we may need some mechanism for an entity to
communicate a request for information it needs to another entity in a
standard mechanism, so that there is complete understanding between the
2 entities. Of course, the Travel Agent Web Service should be fully
aware of the source database schema - so as long as it fully understands
the request from the Hotel Reservation Web Service, it should be simple
for the Travel Agent Web Service to query the source database for the
needed information information. Now that I think about it more, a
semantically aware database may not be necessary in this case - as long
as there is sufficient semantic understanding between the requestor
(Hotel Reservation Web Service) and requestee (Travel Agent Web
Service).
However, there may be cases in which such a database may be valuable -
let's suppose that there is a sufficient level of trust between a
requestor and a semantically aware database, but an insufficient level
of semantic understanding (as if the Hotel Reservation Web Service made
a direct request to the source database in the example I've given). This
is a case where such a database may be valuable, so that the requestor -
which has no knowledge of the database schema - can request information
from the database and receive exactly what it was looking for.
In closing, it looks like this could be a single mechanism to me - but
applied to different types of entities (Web Services, databases, etc.).
|
