Presentation on theme: "Terminology, Scope and Assumptions Mark Harrison"— Presentation transcript:
Terminology, Scope and Assumptions Mark Harrison firstname.lastname@example.org
Intermediary 'Discovery Service' Resource e.g.EPCIS Query Client Resources hold detailed information about individual objects Query Clients wish to retrieve complete information from multiple sources A Discovery Service can help a Query Client to find multiple sources of information An organization might make queries and might provide resources Resource e.g.EPCIS Query Client A query client queries a Discovery Service Resources publish selected records to a DS so that query clients can find them and receives links to resources They may also specify security policies to protect their records (if the policy allows them to)
Resources may include the following types of service: EPC Information Services (EPCIS) Web pages Web services Other Discovery Services (e.g. for a different region) others... We can assume that a Discovery Service provides links to resources in the form of Uniform Resource Locators (URLs) It might not be possible to tell what kind of service is at each URL just by inspection of the URL... so it might be a good idea for a DS to indicate service type for each URL (just like ONS 1.0 does) N.B. Resources are not expected to publish all of their EPCIS events to a DS. They should be encouraged to only publish the minimal number that allows a DS to link to them as a resource for a specific object (identified by EPC / ID) When a resource publishes a 'record' (or 'event') to a DS, it will usually want to protect the confidentiality of this record by specifying / linking to an access control policy to determine who is allowed to see the link.
Discovery Services provide a lightweight framework that helps authorized authenticated clients to find links to multiple resources that hold more detailed information about an individual object. Discovery Services might provide some resilient/redundant storage of link information to overcome the problem of the broken onward link Discovery Services might also provide some resilient/redundant storage about changes of aggregation or disaggregation or changes of ID (in case the EPCIS that holds this becomes permanently unavailable). Discovery Services are not heavyweight track & trace applications. In particular, they are NOT expected to do the following: Perform end-to-end track & trace queries for an individual object (even if the ID of the object to track temporarily changes) Gather complete event information from across a supply chain or lifecycle Analyze event information to detect problems / deviations in supply chains Predict where objects will be seen next - or where delays will happen Such functionality is the scope of more sophisticated applications that make use of Discovery Services - but not within the scope of Discovery Services.
Discovery Services Value-added track & trace applications & supply-chain management applications Retrieve complete end-to-end traceability including multiple aggregation changes, relabelling Analyze event data from across supply chain / lifecycle detect problems (delays, deviations, duplicate IDs) identify root cause of problems predict ahead (when, where expected next) analyze trends and optimize for efficiencies Handle / choreograph fine-grained product recalls Generate alerts re problems (e-mail, SMS) help authorized authenticated clients to find one or more possibly relevant information resources for an EPC or ID 2 buckets