Re: [ESDS] Interaction models for Discovery Services

["David Potter" <[e-mail]>]

Dear ESDS Colleagues,

I have now had time to study and digest Mark's submissions from one week
ago, which I found most interesting, and I would like to make some
high-level observations as follows:

1.  The Trade-offs.xls spreadsheet is very illuminating. For me it speaks
volumes about the potential complexity if the proposed Discovery Services
component is actually responsible for much more than being a directory of
information sources. Is it realistic to expect a "Discovery Service", among
other functions, to handle "end-user" clients, handle standing
subscriptions, and to handle the collection of data from multiple providers
while according appropriate access rights and responding with that data.

2.  I think that there appears to be too much focus on the specifics of
supply chain management and EPCIS. What is the scope of the ESDS initiative?


a.  To create a generic information directory service? 

b.  Or to create a discovery service specifically for EPCIS and its data
scope?

3.  I am uncomfortable with the portrayal of the role of the Discovery
Service as an intermediary, between the Query Clients and the Information
Resources. I think that this intermediary role compromises the real role of
DS by expecting DS to perform many, potentially conflicting, roles as
already mentioned in 1. above. This significantly increases the complexity
of what the DS is supposed to be and also creates much more complex trust
and access relationships. 

4.  I would like to return for a moment to the concept of the "Consolidated
Information Broker", or CIB, that I raised a few weeks back (posting 21st
April 2008). If you replace the Query Client in Mark's models with a
"broker" type function, even one of the "Value-added track & trace
applications & supply-chain management applications" shown on slide 5 of
Mark's Terminology and Scope.ppt, then the relationship between the broker,
the DS and the Information Resources is much more logical. The tasks of
managing the real client requests, standing subscriptions, access and
permissions etc. can then be handled by the "broker"/value-added application
which uses the DS to locate data on behalf of the query clients.

5.  This creates a simpler trust/authentication/access model because query
clients would no longer have direct access to the DS, only well-trusted and
certificated "broker"/value-added applications would be granted such access.
Similarly query clients would have no direct access to the Information
Resources, only the "broker"/value-added applications would have such
access. The risk of information harvesting by "honeypot" resources is more
or less eliminated in this way.

6.  This approach, in my opinion, leaves the DS with a much clearer role. It
has on the one hand only to deal with properly registered and authenticated
Information Resources who are authorised to publish the whereabouts of
information, probably with some strict scope controls to prevent false
information from being published by otherwise legitimate publishers. On the
other hand it responds to queries from properly registered and authenticated
"brokers"/value-added applications.

As Mark hoped, I also hope that these remarks will stimulate still further
lively discussion which will move us towards our eventual goal.

Best regards,

David.

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Mark
Harrison
Sent: 08 July 2008 11:10
To: [e-mail]
Subject: [ESDS] Interaction models for Discovery Services

 

Dear ESDS colleagues,

 

Following on from the previous discussions on this mailing list about  

the interaction between Discovery Services and 'Consolidated  

Information Brokers', I have attached a couple of Powerpoint  

presentations, which I presented 3 weeks ago at a face-to-face meeting  

of the EPCglobal Data Discovery Joint Requirements Group.

 

The presentation on the interaction models considers the possible  

sequences of message flows between a query client, an information  

resource and a Discovery Service, considering suitability of each  

model for one-off queries as well as standing queries, together with  

an analysis of their relative merits in terms of protecting the  

confidentiality of information resources, confidentiality of clients'  

queries, as well as considering the kinds of data to be stored in a  

DS, performance and latency issues and impact on the network traffic  

and possible security threats.

 

The slides are intended to provide an easy-to-read animated summary of  

the analysis contained in section B of  the document D2.4 from the  

BRIDGE project (High-level design document).

 

 
http://www.bridge-project.eu/data/File/BRIDGE%20WP02%20High%20level%20design
%20Discovery%20Services.pdf

 

I would also like to acknowledge that the original BRIDGE document  

D2.4 section B was jointly authored by Trevor Burbridge (BT), Oliver  

Kasten (SAP), Cosmin Condea (SAP) and Mark Harrison (University of  

Cambridge, Auto-ID Lab), with additional inputs from Nicholas Pauvre   

(GS1 France) and members of AT4 wireless (who led BRIDGE WP2).

 

 

I have also attached an Excel spreadsheet which indicates some of the  

advantages and disadvantages from the perspectives of the client,  

resource, DS and network traffic, together with some possible  

countermeasures.  Feel free to modify the spreadsheet - though I  

suggest that you highlight any changed cells (e.g. set background  

colour of cell to yellow) so it is clear to everyone which changes you  

have made.

 

I really hope that these presentations and the spreadsheet will  

stimulate some lively discussion on this mailing list and I look  

forward to reading your comments about the different interaction  

models for Discovery Services.

 

Best regards,

 

- Mark Harrison

 

_______________________________________________
ESDS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/esds