The following sections describe the technical specification of Accada's EPCIS implementation. It is intended as an introduction to future developers who are somewhat familiar with the EPCglobal EPC Information Services (EPCIS) specification [1]. We currently implement version 1.0 of this specification.
The goal of EPCIS is to enable applications to incorporate EPC-related data into their businesses. It provides means to store EPC data persistently and offers a framework to add data to a repository as well as query it. The EPCIS specification describes a standard interface for accessing EPC-related information and thus leverages an EPC-related data sharing accross applications.
Accada's EPCIS implementation is not intended to provide a reference implementation but an entry point to allow rapid prototyping. Our software has evolved over several semester and lab projects at the Distributed Systems Group [2] at ETH Zurich and is under continous development.
The following figure gives an overview of the EPCIS architecture.
The architectural style is client server. A client is either an EPCIS Capture Application or an EPCIS Query Application or both. The server is an EPCIS Repository providing several interfaces to which clients may connect. The Repository parses client requests and processes them by accessing the relational database. The transport protocols used are XML over HTTP and SOAP over HTTP.
In the following sections we describe the Repository and the Client Applications in detail.
Some communication and accessing information are described in the Access Tier, the description of the whole functionality is in the Business Tier, and the database details are given in the Resource Tier.
The sections below describe our EPCIS Repository implementation and are divided into so-called tiers. How the information and services of the repository are accessed and how applications may communicate with it are described in the section about the Access Tier. The services, implementing the actual functionality, are in the Business Tier. Finally the database, storing the information surrounding the EPC's (so called events), is maintained in the Resource Tier.
This tier is the entry point into the EPCIS Repository and provides the interfaces used by the client applications accessing the Repository. In here also user authentication and authorisation should take place. Currently our implementation does neither provide authentication nor authorisation mechanisms!
Our Repository implements the SOAP binding for the Query Interface. We use Axis [3] as the framework to provide the SOAP interface. Thus an EPCIS Query Application implemented in Java may use the generated Axis classes available in our epcis-queryclient module in order to access the Repository. Concerning the Capture Interface we implement the HTTP binding and thus an EPCIS Capture Application may send capture events through HTTP POST request with the event (XML form) as payload. More information about the Capture and Query Applications follow in EPCIS Capture Application and EPCIS Query Application further below.
The business tier consists of the EPCIS Repository implementation. Simply speaking the Repository takes client requests, applies some parsing and error handling, transforms the requests into SQL INSERT and SELECT queries, and submits them to the underlying resource tier (database). In the case of an EPCIS query, this tier sends back the resulting EPCIS response. As mentioned above Accada's EPCIS Repository consists of an implementation of the SOAP binding for the Query Interface and an implementation of the HTTP binding for the Capture Interface.
The following class-diagram shows the components that make up the business tier:
In the remainder of this section we describe the most important components in more detail.
In order to implement the SOAP binding on the Query side, the Axis framework [3] comes into play. We use Axis to support SOAP over HTTP and thus integrate the Axis HTTP TransportListener through a servlet into our Web container. In Axis the incoming SOAP messages pass the framework in form of a MessageContext which contains the request or response message as well as a number of attributes. The processing of the MessageContext is made in Handlers. We provide two such Handlers, one for pre-processing and one for post-processing. In between is the actual service implementation:
+------------------+ +-----------------------+ +------------------+
msg -> | QueryInitHandler | -> | QueryOperationsModule | -> | QueryPostHandler |
+------------------+ +-----------------------+ +------------------+
The Handlers make up a HandlerChain which may be configured in the deployment descriptor (see the Developer Guide for locating the corresponding server-config.wsdd file). The following describes the Handlers and the Service in more detail:
The QueryInitHandler performs the initialization work for our Repository implementation. That is, it sets up the database connection, loads application and logging properties, and restores scheduled subscriptions. It saves all necessary information to the MessageContext which will be passed on to the Service. The QueryInitHandler is also responsible to clean up after a service fault by undoing the initialization steps (closing the database connection and making the scheduled subscriptions persistent).
The QueryOperationsModule is the service implementation of the SOAP binding for the EPCIS Query Interface. In here the actual business functionality takes place. Basically the QueryOperationsModule takes the incoming request from Axis, handles it according to the specification (by interacting with the underlying database) and returns the resulting query responses back to Axis. Please refer to the specification [1] for more details about the operations available in the Query Operations Module.
The QueryPostHandler is invoked after the service has completed its work successfully. It reverses the steps taken by the QueryInitHandler, closing the database connection and storing the scheduled subscriptions.
Unlike polled queries which are stateless, subscribed queries have to keep track of things like their last execution time, the destination URL for reporting results, the query parameters, and when or on what event the query should be executed. To meet these requirenments we keep references to subscriptions in the Web application context. This avoids subscriptions being garbage collected and retains them across service invocations. Furthermore we hold the subscriptions also in the database in order to save them across application restarts.
In order to handle subscribed queries requested through the Query Control Interface's subscribe operation we provide the QuerySubscription component. It represents standing queries which are either scheduled or triggered:
A QuerySubscriptionScheduled represents a subscription associated with a schedule and a query. The query is invoked whenever the timer of the schedule times out.
A QuerySubscriptionTriggered represents a subscription associated with a trigger URI and a query. The query is invoked whenever an event is captured that includes the specified trigger URI.
The CaptureOperationsModule is the implementation of the HTTP binding for the EPCIS Capture Interface. It is responsible for storing incoming capture events to the repository. Currently MasterData cannot be inserted through this module, as the specification does not describe the means how MasterData should be entered. Also note that currently there is no way to delete event data once it is entered.
Technically the CaptureOperationsModule is an HttpServlet which implements the doPost operation and thus waits on a specific HTTP address for incoming POST requests. The payload of the POST request must correspond to a valid EPCIS event in its XML representation as described by the specification [1].
The resource tier consists of a relational database which stores all the event data, the vocabularies, and the subscriptions. The figure below shows the database schema for holding ObjectEvents. The schemas for Transaction-, Quantity-, and AggregationsEvents are similar to the one below and are not reproduced here.
Vocabularies each have their own database table. Below we exemplary give the schema for BizTransaction, Disposition, and ReadPoint vocabularies. The vocabularies table holds the mapping from vocabulary names to our vocabulary database table names.
As mentioned before we also store the subscriptions to the database. The corresponding schema looks like this:
An EPCIS Capture Application is used for capturing events to the Repository. Since we only implement the HTTP/POST binding of the EPCIS Capture Interface, a capture application must send events in their XML form through HTTP POST requests to our Repository. The following diagram shows the components available in our epcis-captureclient module:
Basically we provide the CaptureClient and the CaptureClientGui as described in the following sections:
The CaptureClient implementing the CaptureClientInterface provides transparent access to the Repository. It supports the capture operation and sends the given events in their XML form to the Repository using HTTP POST requests.
This graphical user interface provides the capturing functionalities for use by humans. Technically the CaptureClientGui is an implementation of the Model-View-Controller (MVC) pattern: The CaptureEvent represents a real world event (the model in the MVC pattern). The CaptureClientGui is the actual view in the MVC pattern. And the CaptureClient implements the controller part of the MVC pattern. Please refer to the User Guide for further information on the use of the capture gui.
An EPCIS Query Application sends queries through the EPCIS Query Interface to the EPCIS Repository. Because we currently only implement the SOAP/HTTP binding of the Query Interface, a query application must use SOAP requests. For this reason we provide the epcis-queryclient module which includes the Axis generated classes for use in a Java query client. The following diagram outlines the components that make up the epcis-queryclient module:
The main components are the QueryControlClient, the QueryCallbackClient, and the QueryClientGui. In the following we describe these components briefly:
The QueryControlClient is a simple Java class that can help in getting started with a query application. It uses the Axis framework and the Axis generated Java classes in order to connect and send queries to the Repository. The QueryControlClient implements the QueryControlInterface and thus provides the operations available in the EPCIS Query Control Interface. It acts as an application-side layer providing transparent access to the Query Operations Module at the EPCIS Repository.
A query callback is the mechanism for returning results of a standing query (subscribed query) back to the requesting client. The QueryCallbackClient provides very simple support for this mechanism: It can be started as a new Thread and will then be listening at a specific ServerSocket for incoming HTTP POST connections. Once such a connection is established, it parses and caches the POST payload, and notifies everyone waiting for a response.
The following sequence diagram gives an overview for the query callback mechanism. It shows the processing steps a subscribed query takes, from the time of subscription to the delivery of results to the client.
We also provide a graphical user interface for composing and sending queries manually. The gui makes use of the QueryControlClient described above for sending the queries to our Repository. Technically this component is also implemented according to the MVC pattern: The Query models a real world query (the model in the MVC pattern) and has merely setter and getter functionalities. The QueryClientGui is the actual view in the MVC pattern. And finally the QueryClientGuiHelper which performs integrity checks, does the error handling, marshalls parameters and transfers queries to the QueryControlClient is the controller in the MVC pattern. Please consult the User Guide for further notes on how to use this gui.
[1] EPC Information Services (EPCIS) Version 1.0 Specification, Proposed Specification Version of 29 November 2006
[2] Distributed Systems Groups, ETH Zurich, http://www.vs.inf.ethz.ch/
[3] Apache Axis, The Apache Software Foundation, http://ws.apache.org/axis/java/index.html