|
|
|
The Core Query Operations
Module provides two interfaces, called the EPCIS Query Control
Interface and the EPCIS Query Callback Interface, by which EPCIS data
can be retrieved by an EPCIS Accessing Application.
The EPCIS Query Control Interface defines a means for EPCIS Accessing
Applications and trading partners to obtain EPCIS data subsequent to
capture from any source, typically by interacting with an EPCIS
Repository. It provides a means for an EPCIS Accessing Application to
retrieve data on-demand, and also enter subscriptions for standing
queries.
Results of standing queries are delivered to EPCIS Accessing
Applications via the EPCIS Query Callback Interface.
|
|
|
Query
Framework (EPCIS Query Control Interface)
|
|
|
The EPCIS Query Control
Interface provides a general framework by which client applications may
query EPCIS data. The interface provides both on-demand queries, in
which an explicit request from a client causes a query to be executed
and results returned in response, and standing queries, in which a
client registers ongoing interest in a query and thereafter receives
periodic delivery of results via the EPCIS Query Callback Interface
without making further requests. These two modes are informally
referred to as “pull” and
“push,” respectively.
Standing queries are made by making one or more subscriptions to a
previously defined query using the subscribe method. Results will be
delivered periodically via the Query Callback Interface to a specified
destination, until the subscription is cancelled using the unsubscribe
method. On-demand queries are made by executing a previously defined
query using the poll method. Each invocation of the poll method returns
a result directly to the caller. In either case, if the query is
parameterized, specific settings for the parameters may be provided as
arguments to subscribe or poll.
An implementation may provide one or more
“pre-defined” queries. A pre-defined query is
available for use by subscribe or poll, and is returned in the list of
query names returned by getQueryNames, without the client having
previously taken any action to define the query. In particular, EPCIS
does not support any mechanism by which a client can define a new
query, and so pre-defined queries are the only queries available.
An implementation may permit a given query to be used with poll but not
with subscribe. Generally, queries for event data may be used with both
poll and subscribe, but queries for master data may be used only with
poll. This is because subscribe establishes a periodic schedule for
running a query multiple times, each time restricting attention to new
events recorded since the last time the query was run. This mechanism
cannot apply to queries for master data, because master data is
presumed to be quasi-static and does not have anything corresponding to
a record time.
This framework applies regardless of the content of a query. The
detailed contents of a query, and the results as returned from poll or
delivered to a subscriber via the Query Callback Interface, are defined
in later sections of this document. This structure is designed to
facilitate extensibility, as new types of queries may be specified and
fit into this general framework.
An implementation may restrict the behavior of any method according to
authorization decisions based on the authenticated client identity of
the client making the request. For example, an implementation may limit
the IDs returned by getSubscriptionIDs and recognized by unsubscribe to
just those subscribers that were previously subscribed by the same
client identity. This allows a single EPCIS service to be
“partitioned” for use by groups of unrelated users
whose data should be kept separate.
If a pre-defined query defines named parameters, values for those
parameters may be supplied when the query is subsequently referred to
using poll or subscribe. A QueryParams instance is simply a set of
name/value pairs, where the names correspond to parameter names defined
by the query, and the values are the specific values to be used for
that invocation of (poll) or subscription to (subscribe) the query. If
a QueryParams instance includes a name/value pair where the value is
empty, it shall be interpreted as though that query parameter were
omitted altogether.
|
|
|
|
|
|
Query
Callback Interface
|
|
|
The Query Callback Interface is
the path by which an EPCIS service delivers standing query results to a
client.
Each time the EPCIS service executes a standing query according to the
QuerySchedule, it shall attempt to deliver results to the subscriber by
invoking one of the three methods of the Query Callback Interface. If
the query executed normally, the EPCIS service shall invoke the
callbackResults method. If the query resulted in a
QueryTooLargeException or ImplementationException, the EPCIS service
shall invoke the corresponding method of the Query Callback Interface.
Note that “exceptions” in the Query Callback
Interface are not exceptions in the usual sense of an API exception,
because they are not raised as a consequence of a client invoking a
method. Instead, the exception is delivered to the recipient in a
similar manner to a normal result, as an argument to an interface
method.
|
|
|
|
|
|
|
|
|
