WEB SERVICE-BASED TRACEABILITY IN FOOD SUPPLY CHAINS
Andr
´
eia Akemi Kondo, Claudia Bauzer Medeiros,
Edmundo Roberto Mauro Madeira, Evandro Bacarin
Institute of Computing, University of Campinas, Campinas, S
˜
ao Paulo, Brazil
Keywords:
Traceability, Supply Chains, Workflows, Web Services.
Abstract:
Supply Chains present many research challenges in Computing, such as the modeling of their processes, com-
munication problems between their components, logistics and processes management. This paper presents
a supply chain traceability model that relies on a Web service-based architecture to ensure interoperabil-
ity. Geared towards assisting quality control in the agricultural domain, the model allows to trace products,
processes and services inside a chain. It has been validated for real life case studies and the Web service
implementation is under way.
1 INTRODUCTION
A supply chain is a network of retailers, distributors,
transporters, storage facilities and suppliers that par-
ticipate in the sale, delivery and production of a par-
ticular product (Kumar, 2001; Min and Zhou, 2002).
It is composed of distributed, heterogeneous and au-
tonomous elements, whose relationships are dynamic.
Figure 1 presents a basic example of the milk sup-
ply chain. Starting from a product (input) – (Milk 1) –
it produces another product – (Cheese), going through
transformations, storage and transportation steps. The
figure shows units of Production (Milk Producer 1
and Dairy 1), Transportation (Transp1, Transp2 and
Transp3) and Storage (Warehouse 1 and Supermarket
1). Any supply chain can be represented by a directed
graph which has at least one source – e.g., (Milk Pro-
ducer 1) and one sink (Supermarket1). The back ar-
row represents a return flow, where some outputs of
a chain can be used as inputs of the same or other
chains – e.g., milk overflowing from vats can be used
to enrich food for the animals at the farm.
Traceability in food supply chains is gaining im-
portance everywhere all over - be it to feed humans,
plants or animals. The food industry is investing mas-
sively in issues involving health e.g., safety, storage,
manipulation and composition of products.
In particular, meat supply chains have attracted at-
tention from all over the world, with the appearance of
the Creutzfeldt-Jacob Disease (also known as the mad
cow disease). New devices have been devised to tag
animals, and special hardware and software systems
keep track of specific events in the animal’s life. The
emphasis, however, is on constructing such devices.
What is needed is a generic computational infrastruc-
ture to support traceability in a general way.
In Computer Science, supply chain traceability
management involves many challenges, such as cap-
turing, identifying and storing relevant events, man-
aging associated constraints, analyzing the interaction
of actors in a chain, monitoring negotiation protocols,
and many others. Though some of these computing
issues are studied in the context of supply chains, food
supply chain traceability is still a relatively new field.
This paper contributes to solving this problem, by
presenting a traceability model for agriculture sup-
ply chains. This model is based on two main con-
cepts: (1) using distributed repositories to store sets of
records concerning specific events along a given food
supply chain; and (2) defining Web services to access
these repositories, thereby transforming the problem
of traceability derivation into that of performing a set
of service invocations.
2 RELATED WORK
2.1 Supply Chains and Base Model
An agricultural supply chain is composed of all the
activities that occur from the production to the fi-
171
Akemi Kondo A., Bauzer Medeiros C., Roberto Mauro Madeira E. and Bacarin E. (2007).
WEB SERVICE-BASED TRACEABILITY IN FOOD SUPPLY CHAINS.
In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 171-177
DOI: 10.5220/0001270701710177
Copyright
c
SciTePress
Figure 1: Basic example: the Milk Supply Chain.
nal consumer. The flow inside an agricultural supply
chain is subject to several controls, most of which can
affect human health. Such controls must be enacted
at all phases within the chain, complicating its moni-
toring.
Our work is based on a general model (Bacarin
et al., 2004) composed of the basic components: Ac-
tors, Production, Storage and Transportation.
Chain dynamics are modeled by Regulations,
Contracts, Coordination Plans and Summaries. Re-
gulations are restrictions imposed at several phases of
the chain. Contracts are agreements between trading
partners. Coordination Plans are directives that des-
cribe chain execution, coordinating the interactions
between its components. Summaries are elements in-
troduced for traceability and auditability. This paper
is concerned with traceability issues.
2.2 Traceability
Traceability is a concept that involves several types of
activities and refers to the ability to describe and to
follow the life of a conceptual or physical element,
preserving its identity and its origins. In database
systems, traceability is associated with execution of
transaction logs. In software engineering, it is related
to all phases of software development from the re-
quirements to the final product. It is also present in
fault tolerance studies or in system auditing.
Most scientific papers on agricultural traceability
ignore implementation aspects. They are concerned
with logistics (Thomas and Griffin, 1996) and strate-
gies of chain execution (Guiffrida and Nagi, 2006) or
certification (Stock, 2004). These papers center on the
business at hand, and computing issues are not treated
at depth.
More recently, work has appeared concerning a
computer science perspective e.g., (Bello et al.,
2004) or (Cimino et al., 2005). The first proposes a
distributed collaborative information system that uses
XML for representing data and Web Services to inter-
face distinct suppliers which communicate through a
HTTP protocol. The second describes a traceability
system that supports exchanging documents between
several units of the supply chain. It uses ebXML
(Electronic Business using eXtensible Markup Lan-
guage), a set of specifications that enable companies
to conduct business over the Internet.
According to (Opara, 2003), there are seven im-
portant elements in agricultural traceability: product,
process, genetic constitution, inputs, disease, pests
and measurement traceability. Many of these factors
are associated with geographical coordinates. As a
consequence, additional information can be derived
- e. g., associated with cultural aspects, which may
influence food preparation and preservation. An ex-
ample of the use of coordinates is the GeoTraceAgri
(Debord et al., 2001) european project, where geo-
graphic coordinates are the prime element for trace-
ability studies. As will be seen, our model also relies
on this information.
2.3 Workflows and Web Services
In our work, processes within a chain are modelled
as workflows, in which an activity can encapsulate
other activities. A workflow represents the automa-
tion of procedures where documents, information or
tasks are passed between participants for executing
a certain action according to a defined set of rules
(Hollingsworth, 1995).
Figure 1, the basic supply chain, can be seen
as a workflow where each box denotes a Produc-
tion element (e.g, Dairy), a Transportation element
or a Storage element. Each box comprises a wide
range of activities that occurs within the supply chain.
The Dairy can furthermore encapsulate another chain
(workflow).
In our architecture, each workflow activity may
be considered as invoking some sort of Web service.
Web Services are self-describing and modular busi-
ness applications that provide business logic as ser-
vices over the Internet through standards-based inter-
faces and Internet protocols (e.g. HTTP) with the pur-
pose of finding, subscribing and invoking those ser-
vices (Nagappan et al., 2003; Alonso et al., 2004).
These standards include XML (Extensible Markup
Language), SOAP (Simple Object Access Protocol),
WSDL (Web Services Description Language) and
UDDI (Universal Description, Discovery and Integra-
tion). Web Services facilitate the communication be-
tween distinct applications and platforms. As will be
seen, our traceability model is also enacted via service
invocation and composition.
WEBIST 2007 - International Conference on Web Information Systems and Technologies
172
3 THE TRACEABILITY MODEL
3.1 Model Overview
Our traceability architecture is concerned with recor-
ding relevant events that occur within an agricultural
supply chain. Those events are incrementally regis-
tered in summaries (Section 3.2) that are stored in in-
terlinked repositories (Section 3.3).
Let us introduce our three main summaries (Prod-
uct, Process and Service) via our running example.
Consider again Figure 1 and the cheese making pro-
cess. This process demands a certain amount of milk,
coagulating agent and salt. At the Dairy, those in-
gredients are mixed and undergo the process that pro-
duces cheese. Each ingredient has its own Product
Summary. For instance, the milk summary stores in-
formation that allows discovering among other things
where and when the milk was produced, if any milk
cow received certain undesirable substances (a drug,
a vaccine). The production process itself has several
stages, such as: curd formation, cutting, cooking, salt-
ing, pressing and curing. Although this process ap-
plies to most kinds of cheese, there are variations and
each process occurs under distinct condition. The in-
formation about each instance of the cheese making
process (ingredients and specific conditions) is stored
in a Process Summary.
The cheese making process produces two distinct
products: cheese and whey. These products may be
used by other production processes. Thus, it is nec-
essary to create a specific Product Summary for each
product. Finally, the cheese may be transported to a
grocer and the whey to an animal food industry, where
they may be stored. Thus, there is a Service Summary
associated to each transportation and storage step.
3.2 Summaries
A Summary is a sequence of records that, similar to
a database log, describes events of a supply chain
for traceability purposes. There are 3 kinds of sum-
maries:
Product: it records the sequence of events that
happen along the life of a product, from its cre-
ation to its final consumption.
Process: it records the details and the phases of
a production process. A process is any activity
that transforms a set of inputs into one or more
different products.
Service: it records information about a service. A
service is any activity that may influence a prod-
uct, without transforming it, e.g. transportation or
storage.
3.2.1 Product Summary
Figure 2 presents a general view of a Product Sum-
mary record, illustrating its links to other data sources
(repositories or other summary records).
Figure 2: Product Summary Record: General View.
The field “id product” uniquely identifies the pro-
duct instance. The “events” field refers to phases of
the supply chain, such as creation, storage, packing,
mixture, consumption etc. Events are described by
“Event description”. The field “process or service that
has originated the event” is a pointer to a record in the
Process or Service Summary that describes the pro-
cess or service which originated the event.
Records in the Product Summary refer to specific
instances of a product. This summary is comple-
mented by a table (Table 1) that defines the properties
of an instance of the product. Each property is defined
as a record composed of three fields, similar to an
RDF description: “id”, “property name” and “value”.
For example, quantity is a property of the product in-
stance identified as CheeseProd (Table 1). The value
of each property is specified by the field “value” (e.g.
the value circular for property shape). This table
allows managing products with distinct properties
here milk has three properties and cheese has four.
Table 1: Table of Product Characteristics.
3.2.2 Process Summary
Figure 3 presents a general view of a Process Sum-
mary record. Similar to what occurs with product in-
stances, records in Process Summaries are instances
of more general process descriptions stored in the
Process Repository (see Section 3.3).
WEB SERVICE-BASED TRACEABILITY IN FOOD SUPPLY CHAINS
173
Figure 3: Process Summary Record: General View.
The “id
process” field identifies a process in-
stance. Every time a process is executed, a new in-
stance is generated. The “place” field indicates the
geographical coordinates of the place where the pro-
cess is executed; the “duration” of the process is a
time interval characterized by two timestamps: pro-
cess begin and process end; “responsible” indicates
the entity (human, software or machine) in charge of
the process; “production date” is the date in which
the process created a product. The “input” field indi-
cates the raw materials that are required for producing
that product. The field “output” contains one or more
identifiers of the products that are produced by the
process; “regulation” contains references to the norms
or conditions that are followed by the process; “pro-
cess detail” points to a workflow, stored in the Process
Repository, which presents details of the process (see
Section 3.3). If a workflow encapsulates other more
detailed workflows, additional records will be stored
in the Process Summary, refining the process activi-
ties. This feature allows to record process execution
in several granularity levels.
The Process Summary is complemented by a ta-
ble that defines the characteristics of an instance of
the process. This table is similar to the product char-
acteristic table (Table 1).
3.2.3 Service Summary
Figure 4 presents a general view of a Service Sum-
mary record. A service can be classified as Trans-
portation or Storage.
Figure 4: Service Summary Record: General View.
A Service Summary record is identified by a key
composed of four fields: “id
service”, id product”,
“place” and “event”. Each record is related to an event
that happens while the service is carried out – e.g., the
loading or unloading of products (during transporta-
tion or storage). The field “id
service” indicates that
a record is related to a specific service. Amount”
indicates the loaded or unloaded quantity; “id
prod”
identifies the product that is the target of a service;
“rep
service” makes reference to a record of the Ser-
vice Repository. “place”, “duration” and “responsi-
ble” are analogous to the fields of the Process Sum-
mary.
The Service Summary is complemented with a
Displacement and a Storage table. The Displacement
table, illustrated in Table 2, describes an itinerary for
each instance of a transportation service. “Id
service”
is the related service identifier. “Description” de-
scribes the service carried out. “Itinerary” stores the
trajectory of that transportation service: triples (x
i
y
i
t
i
) where (x
i
y
i
) are geographical coordinates and t
i
the time. “Company” makes reference to an enter-
prise, whose description is stored in the Participant
Repository. “Regulation” contains references to the
norms or conditions that are followed by the service
in this itinerary.
Table 2: Displacement Table.
The Storage table, see Table 3, contains details
on instances of storage services. The field “Id
serv”
refers to the service. “Company” makes reference to
an enterprise that is carrying out the storage. “Regu-
lation” contains references to the norms or conditions
followed while performing this storage service.
Table 3: Storage Table.
3.3 Repositories
Our model relies on six types of distributed reposito-
ries: Product, Process, Service, Regulation, Partici-
pant and Summary Repositories.
Product Repositories store generic descriptions of
products that are used or generated along the supply
chain. A product can belong to distinct chains. For
example, the product “Minas Cheese” has a unique
generic description for all chains which is instantiated
every time a product of this type is produced.
Process Repositories store descriptions of the pro-
cesses that generate or transform products along the
chain. These processes are stored as workflows and
WEBIST 2007 - International Conference on Web Information Systems and Technologies
174
define the sequence of activities needed for the pro-
duction of a specific product. Table 4 illustrates the
records stored in the repository for the example of
Figure 1. The first row concerns a cow milking pro-
cess and the second shows details of cheese produc-
tion in the Dairy.
Table 4: Process Repository.
Service Repositories store the description of ser-
vices Transportation and Storage that are pro-
vided by a chain’s participants. Participant Reposito-
ries store descriptive data on the chain’s participants
- e.g, information on a transportation or a production
company. Regulation Repositories contain the regu-
lations for quality control in processes and services.
Summary Repositories store summary records previ-
ously described and are of three kinds: Product, Pro-
cess and Service.
4 ARCHITECTURE
This section shows the architecture (Figure 5) that
supports our traceability model. The figure is com-
posed of three layers: repository, summary, and sum-
mary manager layers. All layer components are en-
capsulated by Web services.
Figure 5: Proposed Architecture.
Traceability processing involves queries and up-
dates to Repositories. It is performed via exter-
nal requests to the Summary Manager Web Service
(SMWS). This service provides an interface (SM in-
terface) that allows client applications (a Summary
Manager, a Coordination Manager or a specific soft-
ware) to interact with the Summary Repositories.
Through this service, a client application can request
queries or update the summaries and related tables
with information generated along the supply chain.
Several SMWS may exist, for a fully distributed sum-
mary management scenario. This service forwards
the appropriate requests (queries and/or updates) to
the summary layer, which may need to forward part
of these requests to the repository layer. Repositories
in this layer may also be updated or queried directly
by external applications.
The figure separates summary concerns from the
rest thus, Summary Repositories are treated apart.
The bottom layer encapsulates access to ve Reposi-
tories via five distinct Web services, that respectively
receive requests to Process, Product, Service, Regula-
tion and Participant Repositories.
The middle layer is composed of three Web ser-
vices, ProcSRWS, ProdSRWS and SSRWS, respec-
tively encapsulating access to Process, Product and
Service Summary Repositories and associated tables.
The figure shows that the interface of ProdSRWS ac-
cepts requests from the Summary Manager Web ser-
vice, and may interact with SSRWS and ProcSRWS.
The Web Service of the Product Summary Reposi-
tory is a central piece in traceability processing. The
other two Summary Repository services (ProcSRWS
and SSRWS) cannot interact with each other. The rea-
son for these design decisions is based on the fact that
Product Summaries centralize event recording – thus,
Process and Service Summaries are to some extent de-
pendent on Product Summaries.
Though the figure shows only one repository of
each kind, repositories are in fact distributed. In this
case, we assume that the figure elements are repli-
cated for each site. Distribution does not mean that all
elements of the figure appear at every site. Rather, it
provides a logical overview of communication among
Web services and application. Moreover, traceabil-
ity management must always depend on the Sum-
mary Manager service (SMWS). Thus, our distributed
architecture relies on several SMWS, one for each
site containing summary data. These services inter-
act with each other and manage the access to related
Product, Process and Service Repository services.
Distribution also raises issues such as access au-
thorization, replication, and integrity control, which
are beyond the scope of this paper. For our purposes,
it is enough to state that interactions mediated via
a given Summary Manager service must conform to
WEB SERVICE-BASED TRACEABILITY IN FOOD SUPPLY CHAINS
175
network domain constraints. We say that two Sum-
mary Repositories belong to the same domain when
they have mutual access authorization. The interac-
tion between repositories in distinct domains is ac-
complished through Summary Managers.
Let us now illustrate Web service interactions,
starting with a non distributed scenario. Consider a
request R1 made to service SMWS1 to know when
a given process finished producing product instance
Cheese1. This is executed as follows. SMWS1 is
“responsible” for interacting with three summary ser-
vices ProcSRWS1, ProdSRWS1 and SSRWS1. It
sends a request to ProdSRWS1 with input parameters
“id
product = Cheese1” and “event = creation” (see
Figure 2), requesting as output “production
date” (see
Figure 3). First, ProdSRWS1 finds out which pro-
cess instance was responsible for creating Cheese1
(suppose “process
id = pr ch1”); next, ProdSRWS1
will request from ProcSRWS1 the production date, of
“pr ch1”, the desired date for R1. Repository updates
can also be processed in a similar way.
Figure 6: Example: activity sequence.
In a second example (Figure 6), a user applica-
tion requests the following query from the SMWS:
find the company name that carried out the transporta-
tion service of product P from dairy (x
1
y
1
) to ware-
house (x
2
y
2
) and the date of this transport event. The
SMWS interacts with the Service Summary Repos-
itory Web service (SSRWS) which finds the service
identifier. Within this service, the company is found
via the displacement table. Given the company iden-
tifier, the SSRWS poses a request to the Participant
Repository WS to find the company name. To find the
event date of the service, the SSRWS accesses Prod-
SRWS using the product and service identifiers. Date
and company name are forwarded to the SMWS and
returned to the user application.
Our examples concern a centralized scenario. In
the distributed case, requests will start at some SMWS
say, SMWS1 that will interact with “its” Summary
services for information. If this cannot be provided,
SMWS1 will broadcast the request to other SMWS
which behave independently as described in the cen-
tralized case. Another possibility to avoid such broad-
cast overheads would be to replicate some key reposi-
tory information (e.g., basic product and service data).
The use of Web Services for the communication
between the Summary Manager and the many repos-
itories facilitates the management of traceability data
and provides interoperability for distributed and het-
erogeneous environments.
5 CONCLUSIONS
Supply chains present many research challenges in
Computing. This paper proposed a traceability model
for agricultural supply chains. It allows to follow the
life of a product at distinct granularity levels, through
distributed summaries and repositories. The model
proposed was evaluated for different chains for spe-
cific scenarios.
This paper differs from most related work by the
level of detail concerning storage aspects and the use
of spatial data in repositories and summaries, increas-
ing the number of traceable entities and facts. More-
over, it provides a Web service based infrastructure
to allow interactions among repositories. The use of
Web services increases flexibility in chain event man-
agement and facilitates traceability processing.
Ongoing work includes the use of real chain data,
and service implementation. We adopted XML stan-
dards and services are being implemented using the
Java language and PostGIS database.
ACKNOWLEDGEMENTS
This work was partially financed by FAPESP, CNPq,
as well as WebMaps and AgroFlow CNPq projects.
REFERENCES
Alonso, G. et al. (2004). Web Services: Concepts Architec-
tures and Applications. Springer, Germany.
Bacarin, E., Medeiros, C. B., and Madeira, E. R. M.
(2004). A Collaborative Model for Agricultural Sup-
ply Chains. In CoopIS/DOA/ODBASE 2004, LNCS
3290, pages 319–336.
Bello, L. L., Mirabella, O., and Torrisi, N. (2004). Mod-
elling and evaluating traceability systems in food
manufacturing chains. In Proc. of the 13th IEEE
International Workshops on Enabling Technologies:
Infrastructure for Collaborative Enterprises, pages
173–179.
WEBIST 2007 - International Conference on Web Information Systems and Technologies
176
Cimino, M. G. C. A., Lazzerini, B., Marcelloni, F., and
Tomasi, A. (2005). Cerere: an information system
supporting traceability in the food supply chain. In
Proc. of the Seventh IEEE International Conference
on E-Commerce Technology Workshops, pages 90–98.
Debord, M., Viau, A., Tychon, B., Oger, R., and Danet, V.
(2001). Geotraceability: an innovative concept for
the qualification of crop production. Available at:
http://www.geotraceagri.net/doc/GeoTraceAgri
Final-
report
EN.pdf/.
Guiffrida, A. L. and Nagi, R. (2006). Cost characterizations
of supply chain delivery performance. International
Journal of Production Economics, 102(1):22–36.
Hollingsworth, D. (1995). Workflow management coali-
tion - the workflow reference model. In The Workflow
Management Coalition Specification.
Kumar, K. (2001). Technology for supporting supply chain
management. Comm. of the ACM, 44(6):58–61.
Min, H. and Zhou, G. (2002). Supply chain modeling: past,
present and future. Computer & Industrial Engineer-
ing, 43:231–249.
Nagappan, R., Skoczylas, R., and Sriganesh, R. P. (2003).
Developing Web Services. Architecting and Develop-
ing Secure Web Services Using Java. Wiley, USA.
Opara, L. U. (2003). Traceability in agriculture and food
supply chain: A review of basic concepts, technologic
implications, qne future prospects. Food, Agriculture
and Environment, 1(1):101–106.
Stock, J. R. (2004). Food Supply Chain Management, chap-
ter 14 - The US Food Supply Chain, pages 211–220.
Blackwell Publishing, United Kingdon.
Thomas, D. J. and Griffin, P. M. (1996). Coordinated supply
chain management. European Journal of Operational
Research, 94(1):1–15.
WEB SERVICE-BASED TRACEABILITY IN FOOD SUPPLY CHAINS
177