Oracle8i Application Developer's Guide - XML Release 3 (8.1.7) Part Number A86030-01 |
Library | Service | Contents | Index

Building n-Tier Architectures for Media-Rich Management using XML: ArtesiaTech, 8 of 13

## Inter-Tier Communication

Digital asset management systems ultimately provide application services at the middle architectural tier that must be able to push and pull data from the persistent storage layer, which is generally proprietary, specific to the database management and/operating system. Utilizing XML an application framework, it is possible to construct a DAM system that can rapidly be redeployed as new platforms arise. This can be accomplished because XML inherits from its SGML lineage the notion of separating logical and physical data representations.

Logically, a digital asset is comprised of its metadata and its content; however, physically, these two components may be stored in any number of ways. This is where the XML conception of entities is useful. The concept of digital assets can be codified as follows:

    <!DOCTYPE teams:digital-asset [
    <!ENTITY metadata PUBLIC "-//TEAMS//TEXT digital asset metadata//EN"
    "metadata.ent">
    <!ENTITY content  PUBLIC "-//TEAMS//TEXT digital asset content//EN"
    "content.ent" >
      ]>
      <teams:digital-asset>
        &metadata;
        &content;
      </teams:digital-asset>

As the XML parser encounters the entity references, it looks to the entity declaration to determine from where it should pull the actual entity data. This resolution of an entity reference in its declaration is handled by an entity manager. Fortunately, XML also falls heir to the notion that entity management should be kept independent from the actual parser; therefore, by substituting different entity management, numerous underlying physical storage schemes can be supported.

The most basic persistent storage mechanism for the metadata of a digital asset would be XML serialization onto a file system; hence, the entity manager would need only map the PUBLIC identifier for the metadata to a specific host, path and filename.

The same data can also be stored within relational or object-oriented databases, SGML/XML component managers, and proprietary data format schemes. Because one specific implementation is not optimal, in terms of price, performance or other variables, for all situations, the DAM system must be easily configurable to facilitate any of these persistent storage systems.

As an entity manager can be written for to retrieve data from any conceivable storage strategy, XML can be used to serve as a level of indirection between persistent storage and the business logic.

As entities are resolved, pulling data from persistent storage, the information can, again, be serialized as XML and passed to middle-tier, application services for processing. This provides a ubiquitous mechanism for processing the data independent of the plethora of known and unknown methods by which the data can be warehoused.

| Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index