Implementing EPC Information Services with Microsoft BizTalk Server 2006 R2


EPC Information Services (EPCIS) are a part of the EPCglobal Architecture Framework [1], an interrelated collection of hardware, software, data, and service standards towards a common goal of enhancing business flows and computer applications through the use of Electronic Product Codes (EPCs) [1]. The EPCIS layer is at the highest level of the framework, on top of the layers responsible for recording, filtering, and consolidating EPC observations. The goal of the EPCIS layer is to enable disparate applications to share EPC data, both within and across enterprises. This is towards the ultimate goal of enabling the sharing participants to gain a common view of EPC-bearing objects (e.g., items in a retail store which bear bar codes or RFID tags) within a relevant business context. [2]

This goal of this document is to provide architectural guidance on how an enterprise can implement EPC Information Services using the suite of relevant products and technologies from Microsoft. As such, its audience consists of architects, analysts, developers, and Solution Integrators (SIs). The audience is assumed to have a basic level of familiarity with EPC concepts and EPCglobal Architecture Framework. We also assume a basic level of familiarity with Microsoft products in the enterprise integration space including Microsoft® BizTalk® Server [3], Microsoft BizTalk RFID [4], Windows® Communication Foundation (WCF) [5], Message Queuing (MSMQ) [6], and BizTalk Adapter Pack [7].


Scenarios enabled by EPCIS include supply chain tracking, counterfeit detection and ensuring brand integrity by avoiding grey market diversion, e-pedigree, traceability for recalls, visibility into the chain of custody, etc. These scenarios (examples described below) have the common characteristic that EPC data needs to be shared between enterprises to build solutions for them.

For example, consider a “simple” supply chain consisting of a manufacturer, a distributor, and a retailer. The manufacturer commissions new tags for cases, packs them in pallets, and commissions tags for pallets. The distributor receives pallets, re-packs the bottles in cases that contain only items meant for a particular store, and ships the cases to the store. The manufacturer may need to measure average time taken for the items to reach the store from when they leave the manufacturer’s warehouse. It will need to query the store for observational data on items coming from the manufacturer.

Product recall scenarios in a variety of industries (e.g., healthcare, automotive, electronics) can be addressed using EPC data sharing. Drug recall in the healthcare industry is one such example that can be handled more efficiently. Today, recalls are done by Lot Numbers, which means that the whole lot needs to be recalled even if the problem lies with a small subset of the lot. With an EPC data-sharing mechanism in place, manufacturers can identify the subset more precisely, track the items in their distribution network, and perform more targeted recalls.


(From here onwards in this document, we use “EPC data” to mean “observational information on EPC-bearing objects along with appropriate business context”).

Enterprises have attempted to share EPC data necessary to build solutions for the preceding scenarios. This data sharing has had the following characteristics:

  • Every implementation had to independently define the “rules” of EPC data sharing – the structure and semantics of data being shared, and the query mechanisms for the data.
  • The sharing of information has been between parties that already have existing business relationships.

This model of sharing has the following limitations:

  • In today’s world where supply chains are increasingly complex and consist of a whole ecosystem of providers, 3PL parties, freight forwarders, and consolidators in addition to retailers and manufacturers, it is no longer enough to enable sharing of information between two parties that already have an existing business relationship.
  • Since the same business entity may participate in the supply chains of more than one business entity, it will need to share data with potentially more than one business entity. For example, a manufacturer can be a supplier to many retailers and vice versa. If the sharing mechanism for each of these business relationships is proprietary, it is not scalable.

Because of the above limitations, there was a need for a mechanism to standardize EPC data sharing. There are many possible ways to address this. One approach is to use existing B2B standards (e.g., EDI, ASN) and enable them for EPC. Another approach is to define a service model that enables EPC data sharing; EPCIS takes this approach to the problem.

EPCIS architecture

EPCIS defines standard interfaces to capture and query on EPC data using a well-defined set of service operations and data standards [2]. Capture interface implementations can either persist EPCIS events or route them to systems for immediate action. The Query interface supports both synchronous and asynchronous methods for obtaining events. EPCIS is itself agnostic to data security, reliability of messaging, transactionality and authentication models. The problems of object naming and discovery of EPCIS repositories for a given EPC are delegated to Object Naming Service and EPC Discovery, other EPCglobal standards. The Query specifications provide guidance on how to deal with different levels of authorization.

Architecturally, this layer exposes a higher-level event model than just filtered and aggregated EPC data. It adds business context (such as business disposition, references to purchase orders, and ASNs) to EPC observational data. The object model is designed to support extensibility at multiple levels, which can be leveraged for vertical and enterprise-specific needs. Figure 1 is taken from the EPCglobal EPC Information Services (EPCIS) Version 1.0.1 Specification, and shows the EPCIS architecture [2].


Figure 1. EPCglobal architecture framework

EPCIS development and Service Oriented Architecture (SOA)

EPC data sharing is an instance of the general cross-enterprise data sharing problem, and as such it can benefit from exploiting technology already developed to address this general problem. The SOA technology stack is one such option. It complements EPCIS in that it provides standardized solutions to many issues that EPCIS implementations will need to solve in a standards-compliant manner but which are outside the scope of EPCIS specifications. These include data retrieval across trust boundaries, support for multiple identification systems, data security, event-based notifications, reliable messaging, transaction support, and claims-based authorization models. Therefore, it is our guidance that EPCIS implementations should leverage the SOA technology stack.

How does BizTalk Server help in EPCIS implementation?

Microsoft BizTalk Server 2006 R2 supports the development and deployment of EPCIS services in many ways:

Processing by edge systems: The construction of EPCIS events, which happens on the edge systems and involves receiving the EPC observations from a plethora of devices, RFID tag readers, bar code scanners and other sensors, pre-processing this data to remove irrelevant information, and adding local business context is facilitated in the following manner:

  • Device abstraction: The BizTalk Server 2006 R2 platform enables implementations to work across a variety of devices. All devices, regardless of their manufacturer, can communicate with the upper layers of the BizTalk RFID platform in a uniform manner using the Device Service Provider Interface (DSPI). This enables the EPCIS implementation to be device vendor agnostic. Moreover, on the BizTalk RFID platform, device topology details are abstracted away from implementations as well. This permits EPCIS implementations to be device topology agnostic.
  • Pluggable event processing: It is possible to declaratively plug-in new components to a BizTalk RFID process. Thus an enterprise can easily add EPCIS support to their existing BizTalk RFID process. Raw device events can be declaratively filtered, so upper layers are processing relevant observations.
  • Reliability: The BizTalk RFID platform has a reliable, proven, and highly performant event processing engine which is capable of filtering duplicates and other uninteresting EPC events and reducing the volume of the EPC event stream. The platform also supports three processing modes, which can be used to increase system performance, depending on the reliability requirements of the Capture service. A discussion on performance tuning for the BizTalk RFID platform can be found .
  • Event persistence: BizTalk RFID ships with a data sink component which can be used out-of-the-box to persist EPCIS events locally. This can be useful in deployments where the edge systems are intermittently connected to the enterprise data center.

Processing in the data center: This consists of the following steps: potential augmentation of EPCIS events with additional business context from the enterprise’s Line of Business (LOB) systems (in case the context is not available at the edge), and implementation of EPCIS Capture and Query interfaces.

  • EPCIS events seek to associate business data such as purchase orders and business state of tagged objects with observations. BizTalk Server 2006 R2 provides connectivity to various back-end systems using adapters (both out-of-the-box and third-party developed) for various back-end systems which provide higher-level abstractions for these business objects.
  • A Web services framework such as WCF can be leveraged to implement the EPCIS Query and Capture interfaces.

Design of an EPCIS implementation on the BizTalk RFID platform

The high-level design of a system that an enterprise will need to implement EPCIS is shown in Figure 2 below. The considerations in building such a system are described in this section.


Figure 2. High-level system design for using EPCIS

Problem decomposition (Edge vs. Data Center)

The decision to perform a function at the edge is driven by the following factors:

  • Optimization: Since the raw RFID event stream can be high volume and contain a lot of redundant events, it is desirable to perform operations that reduce the size of the stream close to where events are generated.
  • Availability of transient information: Some functionalities are dependent on data that is only available in real time at the edge and must be captured or it will be lost.

The following functionalities need to be implemented at the edge:

  • Collection of raw observational data, and converting it to a schema that is uniform across devices.
  • Filtering of raw data to remove duplicates and other irrelevant events.
  • Generation of aggregate events.
  • Addition of business context.
    • Some business context enters the system as part of observational data. It may be recorded in an automated manner or manually entered. For example, temperature of an item may be part of an EPCIS event in the meat-processing industry. Some business context will primarily reside in the LOB systems in the data center, but is still available to the edge in real time. This may be because the data is either cached at the edge, or the edge has continuous connectivity to the data center. An example is the manufacturer sending an ASN to the retailer containing a list of EPC codes for items shipped. This will primarily reside in the LOB systems, but is needed for EPCIS event generation.

The following functionalities need to be implemented in the data center:

  • Addition of business context. This is business context that isn’t available to the edge in real time, and can be added only at the data center.
  • Interaction with other business systems in the enterprise. For example, observational events may flow to order reconciliation systems for real-time processing (i.e., before they have been stored in the EPCIS repository).
  • Implementation of EPCIS Capture and Query interfaces.

Communication between the edge and the data center

One characteristic of the EPCIS scenario is that the edge and data center may not be continuously connected. Therefore, we need a reliable message bus such as MSMQ to communicate between the edge and the data center.

By using MSMQ, we get loose coupling of systems between the edge and the data center. The edge event producers don’t need to know whether the consumers are in the same data center or in a distributed location with message routing across firewalls or how to address individual machines and how to load balance between them. Both sets of systems can be administered independently of each other.

If using a message bus is not an option for customer deployment, then BizTalk RFID ships with a SQL Sink event handler which can be used to persist EPCIS events.

Implementation at the edge

Aggregate events: Generation of aggregate events depends on the system being able to identify the constituents of an aggregate (for example, the case IDs contained in a particular pallet ID). This problem is complex because the order in which the container’s tag would be read vis-à-vis aggregates’ tags is not predictable. Some implementations choose to use either time-based heuristics (every case seen within x seconds of seeing the pallet belongs to the pallet) or by manual methods. The better solution is to have the workflow itself notify of aggregation boundaries – i.e., sensors on the conveyor belt inform when a pallet is approaching and when it has moved off. These events can be used to establish aggregation boundaries.

Local business context: Another dimension of the problem is the association of local business context with events. The business context may apply to single events (such as temperature of an item) or to multiple events (such as all observations on items being unloaded from a truck being marked with the Business Disposition “Received”). The latter case can be modeled in the following ways:

  • The context can be stored as a rule in the BizTalk Rule Engine (BRE), which is bundled with BizTalk RFID, and available to the event processing engine as an event handler. This context can be changed in real time.
  • The event handler can check a state object periodically and update its state.

Implementation at the data center

BizTalk Server 2006 R2: Orchestrations should be used to receive messages from the message bus and associate further business context to generate complete EPCIS events. For example, when a shipper sends an ASN containing identifiers for items sold, the workflow can associate the ASN with events corresponding to those events. BizTalk Server adapters can be used to facilitate communication with LOB systems.

Modern business processes, especially as enterprises adopt item-level tagging, can generate a high volume of EPCIS events, and they will benefit from the scalability features in BizTalk Server.

Implementations which don’t use a message bus between the edge and the data center can use the SQL adapter in BizTalk Server to fetch events from the edge.

EPCIS Capture interface: It can be implemented as a Web service. This is a stateless service, and it can be implemented using WCF, and hosted using either WAS or IIS. Using WCF provides the enterprise with a framework having a comprehensive implementation for the Web services stack.

Separating EPCIS event generation from the EPCIS Capture interface and using the Web services protocol stack between them provides many advantages. Scenarios where the data in the enterprise is distributed in many data centers that are being managed by different providers need solutions for service discovery, data security, and authorization. These have been addressed in the Web services protocol stack.

(The EPCIS specifications have not specified a SOAP on HTTP binding for the Capture service, only XML on HTTP and XML on Message Queue bindings. BizTalk Server also ships with an HTTP adapter, which can be used if the above considerations don’t apply.)

EPCIS Query interface: It will need to be implemented by an external-facing Web Service front end. A platform such as WCF can be used to implement the framework as the Query interface is stateful, and IIS can provide the hosting container.


The above section describes our recommendation on how an enterprise should architect an end-to-end EPCIS implementation using BizTalk Server 2006 R2. The technology platform has the ability to support a wide variety of business processes. Enterprises will also benefit from the rich support for SOA in the platform.


We thank Ken Traub of Ken Traub Consulting LLC for reviewing the document and providing thoughtful feedback.


1. K. R. Traub et al, “EPCglobal Architecture Framework,” EPCglobal technical document, September 2007

2. “EPC Information Services (EPCIS) Version 1.0 Specification”, April 2007

3. Microsoft BizTalk Server

4. Microsoft BizTalk RFID

5. Windows Communication Foundation

6. Message Queuing (MSMQ)

7. BizTalk Adapter Pack


The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.


Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

©2008 Microsoft Corporation. All rights reserved.

Microsoft, BizTalk, and Windows are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.