RFID, Application Level Events (ALE) standards released publicly Thursday, May 08 2008

I didn't even notice this, but the ALE standard has finally been released publicly by EPC Global

For those not familiar with EPC Global, it's the standards organization devoted to providing standards and recommendations for Electronic Product Code (EPC) and RFID software. They have standards governing the use of EPC RFID tags (the current de facto standard encoding of the data contained on RFID tags), as well as standards governing over-the-air protocol for RFID readers and software/service specifications.

The ALE standard is a language- and platform-agnostic software standard that details the communication interface as well as how a "filtering and collecting" RFID application should be have. In short, some people got together and came up with numerous use cases that detailed various ways that RFID will be used in an enterprise-style environment. All use cases require some level of aggregation. All use cases require some level of filtering capability (filter out bad tags and in good tags). Some use cases require grouping of the resultant data. Different use cases require different sets of the same set of data (for instance all new tags, all removed tags or all current tags). Combining and homogenizing all of these various use cases comes up with a highly configurable system to filter and collect RFID data in application-specific ways.

I first got my hands on the ALE specification late in 2003 (or possibly early in 2004, it's been a while so I forget). The specification was in early draft form and was an incredibly fast moving target (as far as software development is concerned). I created a short week-long proof of concept that only had some of the functionality so we could provide input to Bryan (who is one of the co-chairs of the Filtering & Collection Software Action Group - F&C SAG - who also works at Globeranger, where I work). After we finished arguing over what the spec actually meant (like I said, it was an early draft and had some confusing elements) and I finished my proof of concept with nearly all functionality, ALE got put on hold to get another version of our software out.

By late second quarter of 2004 I had rewritten my ALE POC in service form, fully implemented the WSDL contract and all functionality prescribed by the specification, and integrated the whole thing into the rest of our product (RFID Reader abstraction layer and logical reader name layer) and we had our ALE implementation ready to go and it was the backbone of the 5.0 version of our software. Where we used to have an RFID reader directly linked to its business processes, we now had a full reader management infrastructure software with an easy way to get data out of it completely through user interface configuration. Tie that into our "Edge Process Manager" and we have visually designed edge processes (think BPM but more real time, you expect to be able to fully execute your edge processes in milliseconds to deal with super-fast real-time scenarios) that communicate with our ALE server (which could be the same machine or another machine, or multiple other machines) to request data and execute processes.

Late third quarter of 2004 we take our product to the ALE interop event where we showcase our ALE server as well as attempt to communicate with other ALE servers and clients. Since the ALE contract is WSDL, as long as we implemented the WSDL correctly then everything should be okay. We get there and only find three errors

  • We accidentally chose the wrong format for tags (this was a misread of the spec on my part and we just never caught it)
  • The way .NET web services do not guarantee attribute and element ordering on automatically XML serialized Types even though the WSDL/XSD dictates an explicit order through xsd:sequence instead of xsd:any
  • The default .NET implementation requires the use of the SOAPAction HTTP header to successfully route messages. This default implementation is /wrong/ (the SOAP spec is making that header obsolete and no longer recommended) and should use the request element name instead. This was easily fixed with an additional attribute to alter the default behavior

We tried to communicate with other clients and found almost every single one was implemented in Java. And you know what? We didn't have any problems aside from the few above. We were able to communicate with Java clients, them with us and and the other .NET clients worked with us as well. It was one of the best Java/.NET web service interop scenarios I've encountered.

Anyway, we fixed our issues and release our product fourth quarter of 2004 with ALE as the data backbone. While your average user (mind you, our software's average user is not an average business user) doesn't understand ALE or care about it in general, I'm very pleased with our decision to implement an EPC/RFID standard in our software. I'm also very pleased with my experience as a whole with reading a technical standard, understanding it, implementing it and delivering it to the standards body for interoperability testing.

If you're at all interested in ALE or the other EPC standards (such as the EPC Tag Data Standard), go to the EPC Global website.