Object Name Server plays an important role in RFID scenarios.... at least that's what articles from EPCglobal
(former Auto-ID Center) say. Why do we need ONS so badly? Let me first show you how this service works.
In a typical RFID scenario ONS translates Electronic Produt Codes (EPC) into one or more URLs where
all of the information about the product can be found. ONS is very similar to DNS and it will provide
a quite similar functionality but on a much larger scale.
Below you can find a schema of a typical ONS scenario.
When the reader reads the EPC from the product it is then transferred to the RFID middleware application.
Now the application knows the EPC code but it doesn't know anything about the product yet.
1. Retailer's application queries the ONS server with the EPC data to find out where it can find information about the product.
2. The ONS server responds and returns the URL pointing to the producers database.
3. The retailer's application queries the given URL.
4. Database maintained by the producer returns all of the nessecsary data about the product.
Most applications can also have a local ONS server which will store the information of the once queried objects.
This local ONS can also server as a place where you can store your company EPC data (like assets for instance).
But can we live without the ONS ? Most of RFID applications today do. They send the EPC data directly inside
a delivery confirmation message. That might be good for now on but in a few years this will not be enough.
Why is ONS so much better than sending EPC data directly?
- only one receiver - if you send EPC data to one receiver no one else can read the EPC data unless
the receiver resends the data and how can you know how produced the material if you only have it's EPC?
- message security - if the ONS gives the URLs to the producers database then the producer knows
who reads the data so he can restrict access to specific views (prices, etc.)
- storage information - one of the most important because this gives the producer an actual information about
his products. Only with the ONS will he know exactly how many of his products reached to the store, how much was sold
and directly when... so now we'll have Real Time Stock of shelves Information.
Also the information from where did the query come from might be very interesting...
Right now companies like VeriSign are working to prepare the ONS infrastructure for billions look-ups per day.
SAP AutoID Infrastructure 2.1 doesn't use ONS yet but let's hope in the near future it will, so that it won't miss
this great opportunity of cooperating with the most frequently queried service on the world...
Further reference:
VeriSign to Run EPC Directory
EPCglobal Object Name Service (ONS) 1.0
(former Auto-ID Center) say. Why do we need ONS so badly? Let me first show you how this service works.
In a typical RFID scenario ONS translates Electronic Produt Codes (EPC) into one or more URLs where
all of the information about the product can be found. ONS is very similar to DNS and it will provide
a quite similar functionality but on a much larger scale.
Below you can find a schema of a typical ONS scenario.
When the reader reads the EPC from the product it is then transferred to the RFID middleware application.
Now the application knows the EPC code but it doesn't know anything about the product yet.
1. Retailer's application queries the ONS server with the EPC data to find out where it can find information about the product.
2. The ONS server responds and returns the URL pointing to the producers database.
3. The retailer's application queries the given URL.
4. Database maintained by the producer returns all of the nessecsary data about the product.
Most applications can also have a local ONS server which will store the information of the once queried objects.
This local ONS can also server as a place where you can store your company EPC data (like assets for instance).
But can we live without the ONS ? Most of RFID applications today do. They send the EPC data directly inside
a delivery confirmation message. That might be good for now on but in a few years this will not be enough.
Why is ONS so much better than sending EPC data directly?
- only one receiver - if you send EPC data to one receiver no one else can read the EPC data unless
the receiver resends the data and how can you know how produced the material if you only have it's EPC?
- message security - if the ONS gives the URLs to the producers database then the producer knows
who reads the data so he can restrict access to specific views (prices, etc.)
- storage information - one of the most important because this gives the producer an actual information about
his products. Only with the ONS will he know exactly how many of his products reached to the store, how much was sold
and directly when... so now we'll have Real Time Stock of shelves Information.
Also the information from where did the query come from might be very interesting...
Right now companies like VeriSign are working to prepare the ONS infrastructure for billions look-ups per day.
SAP AutoID Infrastructure 2.1 doesn't use ONS yet but let's hope in the near future it will, so that it won't miss
this great opportunity of cooperating with the most frequently queried service on the world...
Further reference:
VeriSign to Run EPC Directory
EPCglobal Object Name Service (ONS) 1.0
3 Comments
