Information System Framework Architecture for Organization Agnostic Logistics Utilizing Standardized IoT Technologies

Full text

Abstract— Logistics or supply-chain services provide
enterprises and organizations with the necessary level of
flexibility and efficiency in order to retain competitiveness
under the increasingly turbulent e-business area. Web-
Services are utilized by organizations in order to integrate
high and low level applications, thus providing a collaborative
environment without affecting inter- and intra-enterprise
processes. Nevertheless, the above context should be
enhanced in order to comply with the Web-of-Things concept.
This paper describes a sustainable approach towards the
above requirement by employing ONS based services able to
provide targeted information regarding RFID-enabled
physical objects that are handled in an organization agnostic
collaborative environment.
I. INTRODUCTION
ADIO Frequency Identification (RFID) technology has
already delivered revolutionary aspects in various areas
such as logistics (supply chains), e-health management
and materials identification / traceability. RFID technology
itself allows an object’s identification with effectiveness and
efficiency. However traceability of an object calls for a robust
and reliable system operating seamlessly over its entire
lifecycle. Such a traceability system has to be implemented so
as: a) its data model allows unique object identification and
scalable, often big-data, databases, b) its underlying
framework supports interoperability and c) its mechanism is
capable to achieve end-to-end tracing providing full history
information.
Despite RFID technology’s nature in tracking, there are
several challenges that need to be addressed. Since an RFID
tag can be read from a quite long distance without requiring
line-of-sight, it is possible that collisions may occur whereas
also multiple tags could be read simultaneously. Therefore,
there is no guarantee that a single tag will be consecutively
detected on consecutive scans. Moreover, the use of RFID
This work was financially supported by the General Secretariat for
Research and Technology (GSRT) [16] of the Hellenic Ministry of
may constitute a serious threat for the information privacy, as
it could be easily facilitated to espionage or unauthorized
requests.
Based on the previously described situation there is a real
need for an underlying framework able not only to support
and complement the tracing functionality offered by the RFID
technology but also to take into consideration the relevant
tracking information of a physical object through its entire
lifecycle in a secure and effectively protected way.
The work presented in this paper focuses in the challenging
concept of an RFID-enabled, organization unaware, logistics
management, by introducing an architecture that utilizes
components of the Electronic Product Code (EPC) global
network, such as the Object Naming Services (ONS) and the
EPC Information Services (EPCIS), in order to support the
Internet of Things concept. Our implementation is capable of
enhancing the architecture of e-business frameworks, thus
introducing an innovative collaborative business model which
seamlessly integrates the inter-enterprise (public) with the
intra-enterprise (private) processes.
The implemented architecture is demonstrated by the
presentation of a case study in documents (books, papers, etc.)
tracking and management in an academic library
environment. Despite the fact that such an environment has
quite lot variations from an e-business logistics environment,
it has the potential to illustrate (and, even, simulate) the key-
points of the presented architecture when not a standalone but
a whole network of academic libraries are taken into account.
II. CURRENT STATUS
Traceability is defined as the ability to trace the history,
application or location of an entity, by means of recorded
identifications. It also may be defined in general as the ability
to trace and follow any product through all stages of
production, processing and distribution. Traceability itself
can be divided into three types:
 Back traceability (supplier traceability)
Development in the framework of project SELIDA – contract #09SYN-72-
646 which runs under the “Cooperation”, 2009 Call.
R
Information System Framework Architecture for Organization
Agnostic Logistics Utilizing Standardized IoT Technologies
Dimitris Karadimas
Industrial Systems
Institute/RC Athena,
Platani Patras, Greece
Email:
karadimas@ieee.org
Elias Polytarchos
Athens University of
Economics and Business,
Athens, Greece
Email:
e.polytarchos@gmail.com
Kyriakos Stefanidis
Library & Information
Center, University of
Patras, Greece
Email:
stefanidis@ece.upatras.gr
John Gialelis
Industrial Systems
Institute/RC Athena,
Platani Patras, Greece
Email:
gialelis@isi.gr
Preprints of the Federated Conference on
Computer Science and Information Systems pp. 1369–1375
c
2014 1369

 Internal traceability (process traceability)
 Forward traceability (end-user traceability)
Having the end-to-end traceability encompasses all three
types of traceability and since traceability is defined over
every stages of a value-chain, several researchers have
pointed out various elements that should be taken into
account.
Traceability systems store information and show the path
of a particular object of interest along the whole value-chain
from the supplier/producer to the retailer/distributor and
eventually to the consumer/end-user. Throughout this
process, secure, reliable and automatic object identification is
crucial to provide effective and efficient tracing.
Barcode technology, in the past, has been used for the
identification of items. However, in order to meet the
traceability requirements imposed by the governments, a new
technology that allows automated recording of information
was needed. This need has been partially fulfilled by the
revolutionary developments regarding the RFID technology.
Many logistic services have already integrated RFID
identification technology into their services and products but
these solutions most often implement a custom or proprietary
communication flow. This means that it is quite difficult to
come up with a generic approach against these solutions.
On the other hand, providing traceability services apart
from trading logistics services i.e. physical documents
interchange is even more demanding since existing services
(e.g. Xerox Docushare, Papyrus, etc.) refer only to digitized
documents management. Nowadays, document interchange
between organizations, authorities and citizens is realized via
the well-known courier shipping services (i.e. FedEx, etc.),
but these services are almost always built into proprietary
protocols while a gap often occurs when different services,
even of the same type, in inter-continental transactions are
involved.
Especially for book tracking (i.e. lending libraries, etc.)
libraries and Inter-Librarian Loan (ILL) services in general
employ standard interchange formats, exploited via web
services, in order to share repositories and establish
collaboration among them. However, a global standard
elaborating libraries worldwide does not exist.
III. ARCHITECTURE OF THE DEPLOYED INFORMATION
SYSTEM
In the context of this section we are going to concisely
present the architecture of the Document Tracking System
(DoTS), which has been designed in order to tackle the issues
mentioned in the previous section.
Section A concisely describes the technologies employed
whereas section B presents a brief description of the entire
architecture and its basic components.
A. Technologies and specifications employed
The following technologies and specifications have been
utilized in the context of the system: RFID, used to uniquely
identify physical objects and EPC, providing the underlying
framework that the system takes advantage of in order to offer
standardized tracking services.
a) RFID
The RFID (Radio Frequency IDentification) is a well-
documented [1]-[6] and widely adopted [7], [8] technology,
that provides the ability to uniquely identify objects tagged
with RFID tags using special readers [9]. The main goal of
the architecture is to be able to track documents on a
potentially global scale. RFID provides significant
advantages over other automatic ID technologies (specifically
the widely applied bar and QR codes), as RFID tags:
 can be detected in bulk
 don’t need to be aligned with the reader (line of sight)
in order to be read
 can be detected from a greater distance
 have a larger data capacity
 are less susceptible to damage
These outweigh the benefits of the bar and QR code tags
(which are less expensive and quite ubiquitous compared to
RFID tags) for the application on important documents and
can enable the introduction of innovative services, such as
real time traceability and theft prevention. Additionally,
RFID is intrinsic in the framework of global standards
published by the GS1 that concern the EPC, which have been
exploited in order to provide a method to globally provide
tracking information services.
b) EPCgloba l
The GS1 EPC global is a suite of standards and
specifications that leverage the RFID technology in order to
globally enable visibility and collaboration on an item level.
These standards comprise the framework depicted in Fig. 1.
Fig. 1 GS1, EPCglobal framework standards, 2014 [6]
Information about these standards can be found in the GS1
website [5]. In the context of the proposed system, most of the
EPC related GS1 standards have been utilized.
1370 PREPRINTS OF THE FEDCSIS. WARSAW, 2014

c) Object Name Service Specification
The discovery and tracking service of physical documents
that has been implemented exploits the Object Name Service
(ONS) 2.0.1 [5] and the EPC Information Services (EPCIS)
1.0.1 [2], in order to enable the mapping of EPC tagged
documents to addresses of arbitrary, but with a standardized
interface, object management services (OMS).
B. Framework Architecture
The proposed framework aims to support as many of the
EPC global standards as possible; in order to provide the
ability to map single physical objects to URIs and to track
related information regarding the entire lifecycle of the
representation for all involved organizations in the value
chain, together with the realization of ONS-based web
services available in the cloud.
The proposed architecture is value chain agnostic
pertaining:
 common logistics value-chain (i.e. manufacturer,
logistics service, retail and end-user/customer)
 physical documents inter-change value-chain between
public authorities or organizations of the public sector
and citizens or companies of the private sector
 objects inter-change value-chain in demanding cases
such as insurance organizations, shipping companies,
courier companies, etc.
Fig. 2 illustrates the incorporation of the aforementioned
technologies in the proposed framework architecture.
The proposed ONS service layer consists of a collection of
ONS-based web services that are able to provide information
from the organization’s internal hierarchy model breakdown,
using the global EPC notation, without affecting the existing
processes of the value chain. Each organization’s ONS
service layer is responsible for providing per object, both
public and private information, using the global EPC notation.
The private web services satisfy per sector- needs for real-
time, synchronous physical objects tracking. These needs
have various orientations, depending on the corresponding
node of the chain. The public web services address needs of
common operations, regarding single object’s lifecycle
information, such as location, history etc.
The integration of the RFID subsystem, into the
architecture framework raises two main issues. The first
regards the capturing of tags’ information as well as the
identification of the tags themselves. The RFID reader
scaling, range and reading angle are of major importance
since it is incorporated in a versatile environment (many
different types of organizations performing totally different
internal processes). The second issue regards security and
privacy issues that are raised when the identified object’s data
should be classified. Security and privacy issues are presented
in detail in next paragraph.
a) RFID Middleware
The RFID middleware is responsible for receiving,
analyzing processing and propagating the data collected by
the RFID readers to the Information System that supports the
business processes. The middleware hides the complexity of
the actual RFID infrastructure and only provides business
events. On the other hand, the middleware is oblivious of how
the data it provides gets handled afterwards.
Specifically, the RFID middleware provides facilities for:
1. EPC Allocation
2. Device Management and Monitoring
3. Data Collection and Integration
4. Data Structure and Data Association
5. Data Filtering and Data Routing
6. Line Coordination and Process Control
7. Legend and Graphics Creation
8. Visibility and Reporting
9. Track and Trace Applications
b) ONS Resolver
The purpose of the ONS Resolver is to provide secure
access to the ONS infrastructure, so that its clients would not
only be able to query for the OMSs related to EPCs (which is
the de facto use case of the ONS), but also introduce new or
delete any existing OMSs for the objects. This has been
accomplished by creating a SOAP web service layer that
functions on top of the ONS, which provides authenticated
and authorized users with the capability to query the whole
Fig. 2. Proposed framework architecture.
End Users
ONS-based web services
Overall Framework Architecture
Integration Layer
RFID M/W
Organization Hierarchy
MES Level
Tag
Tag
Tag
ONS Service Layer Inter Enterprise
Level
EPCIS
Repository
Per Sector Private Services
Processing Log Tracking …..
Inventory
Public Services
…...
History
Track
Lookup
Trn DB
Shop Floor Level
Enterprise Level
ONS Servic es
DIMITRIS KARADIMAS ET AL.: INFORMATION SYSTEM FRAMEWORK ARCHITECTURE 1371

ONS infrastructure and discover the OMSs for the given
EPCs, to add or delete OMSs or to add or delete users of the
ONS Resolver, depending on their permissions.
In addition to the secure access to the ONS infrastructure,
the ONS Resolver acts as an authorization server [10] for the
relevant OMSs. This way, whenever a user uses the ONS
Resolver to get the address of an OMS and authenticates
successfully, an access token will be returned along with the
result of the query, which, if used in the subsequent
interaction between the user and the OMS, it can provide
privileged access to the service. The authorization procedure
that has been developed is depicted in Fig. 3.
Fig. 3. ONS authorization pr ocedure.
c) Object Management Services
The object management services (OMS) provide
management, tracking and other value added services for the
EPC tagged objects. The ONS Resolver maps the object
management services to the objects according to their owner
and type (for example the OMS for objects tagged using an
SGTIN EPC is going to be determined by their GTIN; i.e. the
OMS for the EPCs with the same GTIN is common [5]) and
they should be implemented according to the EPCIS
specification [2].
The most common case of the aforementioned context is
the presentation of all historical data relevant to a single
physical object. The resulting historical data can contain
information regarding object transactions within locations
controlled by the owner of the item or other organizations, as
long as all the implicated parties implement the described
framework; this was rendered possible through the utilization
of the ONS Service Layer. The data of the objects stored by
the different parties adhere to the same API and, as a result,
one can select the exact kind of these data that are to be
presented. For example historical data could describe an
object’s transaction only with dates on interaction with an
RFID M/W, or with geographic interpreted location of the
interaction, or even with more meta-data of the object like its
purpose of transportation, original owner, final destination
and whether it is classified or not. In an expanded version of
multiple organizations running the presented framework, any
tagged object (document, package, suitcase, etc.) could be
easily and reliable recognized in the entire framework’s
context.
Finally, the arbitrary nature of the OMS themselves, even
though they are implemented with standardized formation,
enables each organization to level-up objects’ related
information according to the specific organization needs and
requirements.
d) Security and Pr ivacy aspects
Since the proposed architecture is based on web services,
our first goal is to identify and classify those services in
regards to their security requirements. Even before that, we
can safely assume that all web services can and should
implement TLS as a standard form of encrypting the data
channel in use (usually the Internet).
Based on the aforementioned architecture diagram, we can
easily identify that there are public and non-public facing web
services. In regards to the non-public facing web services, the
ones that reside within the internals of the proposed
architecture stack, we can exploit the useful fact that both the
clients and the servers of this part of the architecture are
known and can be controlled in regards to their
implementation of the security mechanisms. Therefore it is
safe to assume that the use of client certificates is a feasible
security mechanism. Client certificates are a very robust way
of handling secure and, in conjunction with TLS, encrypted
authentication and authorization and the issues with
scalability and deployment that are usually encountered in
more general scenarios are not applicable to our proposed
architecture. As for the public facing web services, we follow
the industry standard of API keys due to the fact that although
we name those services “public facing”, in reality those
services will be accessed not by casual end users but by the
information systems of the organizations that will employ that
services of our proposed architecture. A case study of such a
deployment is described in the next chapter.
Moreover, all the web services should follow a standard of
secure design that, although already a common practice in
popular web services around the web, we will briefly describe
below.
As mentioned above, all services should be authenticated
over an encrypted communication channel. Messages should
be digitally signed, as well as encrypted, to provide privacy
and tamper-proofing when the message travels through
intermediary nodes route to the final destination even within
different organizations that implement the same proposed
architectural stack. The usage of the access token (a unique
ID or nonce, a cryptographically unique value) generated by
the ONS Resolver within every request, will, obviously,
provide protection against unauthorized usage and it will also
aid to the detection message replay and man in the middle
attacks. HTTP methods should be valid for each API key and
associated resource collection and method by white-listing
allowable methods. Any request for exposed resources should
be protected against CSRF and insecure direct object
references should be avoided.
User request: EPC,
Credentials, OMS
description
ONS: Fetch OMS
addresses for the
given EPC
ONS: Verification of
the credentials
ONS: Correct
credentials: valid
access token creation
for the OMS
ONS: Return to the
user the OMSs and
the access token
1372 PREPRINTS OF THE FEDCSIS. WARSAW, 2014

IV. CASE STUDY ON PHYSICAL DOCUMENTS TRACKING IN A
LIBRARY ENVIRONMENT
In order to evaluate the applicability of the proposed
architecture on a real environment we deployed it on the
existing Integrated Library System (ILS) that is being used in
the central university library of Patras, Greece. The ILS that
is being used by the institution is the well-known open source
ILS named KOHA [11].
As with all ILS, KOHA supports a variety of workflows
and services to accommodate the needs of the institution. Our
proposed scheme focuses on a handful of those services and
augments them with additional features. This is generally
done by adding, in a transparent way, the additional UI
elements and background processes that are needed for our
scheme to work.
The specifics on how this is done will be presented in the
following section, while first we will discuss briefly on the
exact services of the KOHA ILS that our scheme aims to
augment.
A. Supported services
In its initial design, our scheme aims to provide additional
functionality on the core services of an ILS. Those services
are:
 Check Out
 Check In
 New Record
 Delete Record
There are also a number of tracking services that our
scheme aims for and those are:
 History
 Location
 Search
To elaborate, when the check-out or check-in services are
called in KOHA, an additional call is made on the SELIDA
(the name of the developed framework from the related
project) middleware that updates the status of the affected
documents on the SELIDA database. The details on how
those calls are made will be described in the next section.
Similar functionality can be seen on the entire core and
tracking services that are applicable in our scheme as
described in the previous chapters.
B. Integration layer
In order to provide the added functionality to the existing
KOHA services we designed and implemented an integration
layer that seamlessly handles all the extra work along with the
usual service workflow.
The primary reason to provide a seamless layer instead of
changing the actual services (i.e. the source code) is the fact
that every integrated system that is actually in a production
environment needs the benefits of a continuous and stable
update process that is offered by the systems development
team along and implemented by the organization’s
administrator. Adding extra functionality in the form of
changes to the system’s code would require continuous
maintenance of this part of the system on par with the normal
updates of the KOHA ILS.
To overcome this obstacle, and given to the fact that
KOHA is a web based application as most of the modern ILS,
we designed the integration layer so that it is injected upon
page load as a JavaScript file on the pages that we are
interested in. On our specific case study, we used the
“mod_substitute” directive on the Apache web server that was
serving the KOHA web pages. Each time a module/page of
interest is requested by the server (i.e. check-out), the web
server adds a <script> tag that loads all the additional
functionality in the form of a JavaScript file.
This layer, in the form of a JavaScript application module,
adds the required UI elements for our proposed scheme to
work and handles all the web service requests that are
necessary.
As an example, we will showcase the check-out process.
When the user navigates to the check-out KOHA module by
requesting the module’s URL, the apache server injects the
selida.js file which is the integration layer code (so called
SELIDA module). SELIDA module starts executing upon
page load and adds the button “Scan” next to the button
“Checkout”. When the user presses the button “Scan”, a web
service request is launched from the SELIDA module which
starts up the RFID reader via the SELIDA middleware
services. The results (per example the barcodes and titles of
the documents that the reader identified) are communicated
back to the SELIDA module which in turn shows a pop-up
window to the user indicating those results. After this
procedure, the normal check-out workflow resumes by
sending the required POST requests to the KOHA web server
(just like when the user presses the “Checkout” button after
adding the barcode). When the check-out process ends and the
web server responds with the next web page as per KOHA
workflow, the SELIDA module sends a second web service
request to the middleware indicating that the check-out is
complete so that the rest of SELIDA architecture continues
with its own check-out workflow presented in the previous
chapters.
As we can see on this example, the extra steps that are
needed for our scheme to work are completely transparent
from the ILS itself. KOHA as an application retains its
original functionality and workflow while the user benefits
from the added services that our SELIDA module provides.
Fig. 5 illustrates the framework’s activities during the first
object identification phase, previously described.
C. Object Management Services
Since RESTful [12] web services are becoming the most
common developers’ choice for implementing API’s and data
retrieval services SELIDA’s services have been designed
following the RESTful architectural style and JavaScript
Object Notation (JSON) [13] for data exchanging. Although
these technologies do not comply with a specific standard, as
other technologies do, i.e. SOAP, XML web services, when
combined together they constitute a lightweight data-
interchange mechanism that is easy for humans to read and
DIMITRIS KARADIMAS ET AL.: INFORMATION SYSTEM FRAMEWORK ARCHITECTURE 1373

write and also easy for machines to parse and generate, thus
appearing to be the easiest and most comprehensive
messaging way among web services. Moreover, nowadays
numerous open standards-like specifications (i.e. JSONDoc
[14], Swagger [15], etc.) have been presented towards
describing, producing, consuming, and visualizing RESTful
web services so as RESTful web services can become a
complete framework.
Currently, based on the deployment of the proposed
architecture on the existing Integrated Library System (ILS)
that is being used in the central university library of Patras,
Greece, three types of management services (history, location
and search) have been implemented, as described in
paragraph A.
As for an example, the JSON schemes for the request and
response of the search service is presented in Fig. 4.
As depicted in Fig. 4 request to the status OMS may
contain multiple EPC tags at a time, while the implemented
system response contains an indicative error code (0 in case
of no error) and relevant data for recognized books. In the
illustrated example the first two EPCs belong to books owned
by the central university library of Patras, Greece (LIS
UPATRAS) while the third belongs to a book owned by the
university library of Athens University of Economics and
Business, Athens, Greece (LIS AUEB).
V. BENEFITS AND SCALABILITY
Although the described framework has been deployed in an
ILL (Inter-Librarian Loan) environment its initial inspiration
and design has been originated in general logistics or
warehouse inventory stocktaking environments. Based on this
origin the whole framework has been designed and deployed
so as to offer organization agnostic information, supported by
ONS-based web-services that are integrated at the top of each
organization’s hierarchy stack, as illustrated in Fig. 2.
The proposed architecture offers a set of versatile
characteristics due to the combination of reliability and
uniqueness, induced by RFID technology along with the ONS
perspective implementation throughout the architecture that
derives interoperable information exchange. These
characteristics could constitute the basis for the employment
of such a framework so as to derive into a generic Internet-
Of-Things service platform able to handle information and
processes of any value-chain type, including and not limited
at food supply chain, luggage handling, physical document
interchange, etc.
This prospect could be further substantiated by the nature
of the ONS, which is actually a mechanism that leverages
Domain Name System (DNS) to discover information about
an object and its related services from the EPC code.
Conclusively, the presented architecture could be scaled in the
same way as internet does, since internet is based on DNS and
the presented architecture is based on ONS, inheriting DNS
scalability capabilities.
VI. CONCLUSION
In spite of the promising nature of RFID technology,
numerous applications in the actual logistics field area have
not been reported. Only a few pilot studies as well as
experimental tests have proved that RFID would be a
successful tool to enable supply chain traceability. The
reasons why companies are yet reluctant to have confidence
in adopting the technology to gain their product visibility may
be attributed to the several challenges such as lack of
standards, immaturity of RFID, and privacy issues.
This paper presents a ubiquitous approach towards a
collaborative logistics environment and concludes with a case
study implementation involving physical documents tracking
Fig. 5. Framework’s activities during an object identification phase.
Actor
(KOHA Operator)
KOHA
(Workflow) Integ ration Layer RFID M/W ONS Resolver ONS-based
WS Repository
Service
Request
Service
Response
Action
Request mod_substitute Reque st
Tag Code Start Scan
Identify
Object
List of
known WS
Call
Responsible
WS
Object
Identity
resume
Action
Request
Present
Information
continue
Fig. 4. An example of JSON request and response data structure
for status OMS.
{
"EPCList": [
{
"EPC": "1111;2222;3333"
},
{
"EPC": "4444;5555;6666"
},
{
"EPC": "7777;8888;9999"
}
]
}
{
"ErrID": 0,
"EPCList": [
{
"EPC": "1111;2222;3333",
"ItemCode": "abc",
"Title": "Title of document",
"Status":"Self",
"Owner":"LIS UPATRAS",
"Location":
{
"Lat":"38.28923",
"Lon":"21.785369"
}
},
{
"EPC": "4444;5555;6666",
"ItemCode": "def",
"Title": "Title of document",
"Status":"Loaned",
"Owner":"LIS UPATRAS",
"Location":
{
"Lat":"38.28923",
"Lon":"21.785369"
}
},
{
"EPC": "4444;5555;6666",
"ItemCode": "ghi",
"Title": "Title of document",
"Status":"Self",
"Owner":"LIS AUEB",
"Location":
{
"Lat":"37.9940902",
"Lon":"23.7324801"
}
},
]
}
Request Response
1374 PREPRINTS OF THE FEDCSIS. WARSAW, 2014

in an academic library. The main focus of the proposed
methodology and implemented architecture addresses the is-
sue of empowering the whole framework with a standard
specification for objects tracking services, thus the integra-
tion of the ONS-perspective in the architecture. The integra-
tion itself, which, within the EPC global framework is mainly
achieved by utilizing the Object Naming Service, enables in-
volved organizations to act agnostically of their entities and
provides them with the ability to resolve EPC tagged objects
to arbitrary services, but with a standardized manner.
However, security and privacy issues should be further in-
vestigated as future work, apart from the issues already cov-
ered though the implementations of the framework’s web ser-
vices, so as the presented framework will be promising
enough for evolutionizing the way currently exploited for
tracking items in the supply chain.
REFERENCES
[1] ISO. (2010). ISO RFID Standards: A Complete List. Retrieved from
http://rfid.net/basics/186-iso-rfid-standards-a-complete-list
[2] GS1. (2007). EPC Information Services (EPCIS) Version 1.0.1 Speci -
fication. Retrieved from http://www.gs1.org/gsmp/kc/epcglobal/ep-
cis/epcis_1_0_1-standard-20070921.pdf
[3] GS1. (2010). EPCglobal: Specifications. Retrieved from
http://www.gs1.org/epcglobal/standards/specs
[4] GS1. (2010). EPCglobal: Standards. Retrieved from
http://www.gs1.org/gsmp/kc/epcglobal
[5] GS1. (2013). Object Name Service (ONS). Retrieved from
http://www.gs1.org/gsmp/kc/epcglobal/ons/ons_2_0_1-standard-
20130131.pdf
[6] GS1. (2014). EPCglobal framework standards. Retrieved from
http://www.gs1.org/gsmp/kc/epcglobal
[7] Hossain, M. (2012). A Comparison of Voluntary and Mandatory
Adoption of Radio Frequency Identification (RFID) Technology in
Organizations. Retrieved from http://www.wbiconpro.com/421-Hos-
sain.pdf
[8] RFIDjournal. (2013). Survey Shows Half of U.S. Retailers Have Al-
ready Adopted Item-Level RFID. Retrieved from http://www.rfid-
journal.com/articles/view?9168
[9] Wikipedia. (2007). Radio-frequency identification. Retrieved from
http://en.wikipedia.org/wiki/Radio-frequency_identification
[10] IETF. (2012). RFC 6749: The OAuth 2.0 Authorization Framework.
Retrieved from http://tools.ietf.org/html/rfc6749
[11] Official Website of Koha Library Software. Retrieved from
http://koha-community.org/
[12] Wikipedia (2014). Representational state transfer. Retrieved from
http://en.wikipedia.org/wiki/Representational_state_transfer
[13] JSON (JavaScript Object Notation). Retrieved from http://json.org
[14] JSONDoc. Retrieved from http://jsondoc.org
[15] Swagger. Retrieved from https://helloreverb.com/developers/swagger
[16] General Secretariat for Research and Technology, http://www.gsrt.gr
DIMITRIS KARADIMAS ET AL.: INFORMATION SYSTEM FRAMEWORK ARCHITECTURE 1375