Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Universality of Assets
When we speak about assets, it is sometimes tricky to distinguish a web asset from a nonweb asset. For example, a company's web banner logo graphic is easy to categorize as a web asset. On the other hand, it is more difficult to classify program code that contains an SQL query that extracts a customer's pending order that is invoked by an application server running in conjunction with a web server. Is that a web asset? We'll be pragmatic. If the logic or other intellectual property embodied in the program code affects the success of the web property, we'll consider it an asset within our area of concern. To emphasize the point, we'll refer to these as extended web assets. An extended web asset is directly or indirectly used to implement a web property. An extended web asset may not be a web asset in the strictest sense, but its ability to be developed in a timely and correct manner does affect the overall success of the web property. We'll use the shorter term, "asset," to refer to these extended web assets. For example, an automated voice-response telephony system uses prerecorded audio messages. Working in conjunction with a web property or working standalone, the audio message files are assets by our definition.
Web assets, we must emphasize, are passive. A web property comes alive through hardware and software that renders web assets. (See Figure 1.) For example, a "classical" web property renders HTML and images by using a combination of web server software running on stock hardware. The HTML and images constitute the web assets. Because web assets are passive, we store them, version them, index them, and retrieve them. In spite of their passivity, web assets define the essence of a web property. As such, we must carefully protect and care for web assets by storing them in a content repository. (Paradoxically, the hardware and software to render assets consist of standard replaceable components: off-the-shelf computers and shrink-wrapped software components.)
){kind=link}
Figure 1 A repository stores assets, while a server renders them to bring them to life.
The distinction between web assets and the rendering of web assets is critical; it underscores the proposition that the enterprise of web development focuses on creating and managing web assets. The fundamental challenge of content management is to protect and care for the web assets that give life to its web property.
Organizations choose varying approaches to rendering their web assets. One company chooses a traditional approach of HTML files, image files, augmented with CGI scripts. Another chooses a database-driven content server. Another devises a hybrid solution that combines a database-driven content server with a Java servlet-driven application server. Common application servers include products from IBM, Art Technology Group, BEA Systems, BroadVision, and Vignette. All of these mechanisms represent different approaches to the problem of rendering web assets. This idea extends to assets that implement extensions to the web server (such as Microsoft Active Server Pages) as well as assets hosted on the web server but downloaded into the client browser (such as Java applets). Content management transcends the specific choice of rendering technology. The requirement to manage the assets, preferably in some kind of repository, is universal across all the approaches.