ESI: Inching toward edge computing
Architects planning the future of edge computing should take a lesson from a recent industry initiative: Don’t make developers write special code to make their applications run at the edge.
Known as ESI (Edge Side Includes), the initiative is an effort to realize some of edge computing’s benefits by making it easy to dynamically assemble the presentation layer of applications at the edge based on a set of content markup tags instead of distributing the application components themselves.
Launched in April 2001 by Akamai and Oracle and recently published as a World Wide Web Consortium (W3C) note, ESI has met with mixed success: endorsed by several leading vendors such as BEA, deployed in the application server by a handful of vendors such as IBM, and completely ignored by others such as Microsoft.
The idea behind the ESI concept is that dynamic, database-driven content — such as a personalized Web page — can be assembled close to the edge using a content markup language consisting of 10 tags that are recognized by each element in the delivery chain, from databases and application servers to routers, caches, and browsers. Developers can specify where and under what conditions a page can be assembled — usually at a cache as close to the end-user as possible. ESI also deals with “invalidating,” or expiring, cached page fragments when fresh data becomes available at the origin.
Critics say that given the overhead of inserting the tags, the benefits of ESI are marginal and can be achieved by other methods, such as using XML and style sheets coupled with specific technology for geographic targeting, parsing query strings, and identifying cookies. These capabilities can be present at the edge, and can then be leveraged by Web services and other distributed apps. The special tagging required to implement ESI “will definitely add a burden to the enterprise,” says Shuang Chen, CTO of OP40, a White Plains, N.Y. edge computing middleware company.
ESI supporters, meanwhile, cite the benefits of doing simple assembly at the edge as opposed to running distributed processes, which could hang a machine and increase manageability requirements. They also point out that the development of JSR 128 (the Java Server Pages Tag Library for ESI) simplifies the work required within a Java application to define dynamic fragments, content invalidation, and personalization.
However, the initiative’s progress now seems limited by a general perception that it will be co-opted by more robust Web services protocols and the distribution of application components themselves closer to the edge. Even ESI co-creator Akamai acknowledges that ESI-enabled page assembly is only a first step toward computing on the edge, and may become redundant when you can generate pages on the edge using distributed resources.
Some see ESI as one of many vertical protocols that will be superceded by — or at best, coexist with — Web services for specific types of apps. “Over time, [Web services] will be a superset of ESI,” says Ted Middleton, director of content delivery at Santa Clara, Calif.-based Exodus, which at one time had its own edge tagging language called DSI, but found that without native support from mainstream development tools, the implementation overhead was too high.
