Microsoft Prevalence Products
Richard Caetano is reading about Site Server’s “prevalence” layer, and wondering if anyone still uses it. Since I haveworked with systems using Site Server’s “prevalence” and most other competing technologies, I feel qualified to say some things about the topic.
Now, the first thing to realize is that such layersare nothing new, and there are many examples that predate Site Server. The next thing to realize is that DBAs are not going out of business anytime soon. State management always ends up being owned by the DBAs. But despite that reality, prevalence layers are an interesting and essential part of any large architecture.
To start, the coder guys always end up building a “prevalence” layer. Every large architecture I have seen has involved at least one abstraction layer to hide storage cruft from the programmer’s need to perform state management. Imperative programmers think of databases like the drive-train of a car; greasy and mechanical. Programmers don’t like to deal with DBAs typically, because such interactions are normally not under pleasant circumstances. And there are always those programmers who think “who needs a database when I have objects? Why not just make those objects be persistent and forever banish those cranky DBAs?” The underlying assumption is that databases are low-tech, and code (especially code written in the language du jour) is a far better hammer. Even developers who do not succumb to this delusion will find it difficult to argue with the teammate who explains that a prevalence layer will reduce the learning curve. After all, why force your developers to understand all that relational mumbo-jumbo when they already know how to create Java objects? The idea is far too seductive (and not completely stupid), so promising prevalence to programmers will be a successful way to “hook” them for the forseeable future. Everybody wants it.
“Site Server, Commerce Edition” did contain a sort of object persistence layer exactly as Chad Osgood describes. This product was followed by “Commerce Server 3.0″, which had a similar capability. Both were fairly naive at storing objects, basically just storing blobs in the database. Then came “Commerce Server 2000″, which was far more sophisticated. CS2K provided a GUI mapping tool that allowed admins to define mappings between business objects and underlying stores (LDAP, relational, and more) including objects aggregated from heterogeneous stores. “Commerce Server 2002” added support for ASP.NET, customizable mapping editors, and removed many otherlimitations of CS2K persistence system. Of the sites that use Microsoft’s commerce software, I doubt that many still use Site Server, although there may be a couple that still use Commerce Server 3.0.
Somewhere between the release ofCS 3.0 and release of CS2K, EJB started to take form, and eventually the Java folks came up with “Entity Beans”. Around the same time, ASP.NET was taking form, and Microsoft decided to make object persistence more widely available. ASP.NET has object persistence built-in, although not so sophisticated as to be a threat to Commerce Server revenues. Theremoting architecture in version 1.0 of the .NET frameworks, including Xml Serialization was also designed to be a suitable foundation for developers obsessed about prevalence.
And that takes us to today. EJB “entity beans” and ASP.NET state management have brought object persistence to the masses. You can predict that more sophisticated layers will continue to be commodotized.
~
Now let us talk about the specific marketing buzzword “prevalence“. The referenced wiki says “Prevalence layers are typically three orders of magnitude faster than traditional databases for queries and about as fast for transaction processing.” For the inexperienced, this seems reasonable; for the experienced this is retarded. But it isa lie that has persisted since beforewe called them”prevalence layers”. Another quote:
The basic difference is that a prevalence layer keeps all objects’ states in the client’s memory space, whereas a database (by which I assume you mean a conventional RDBMS or OODBMS) keeps all objects’ states on disk and often requires an IPC mechanism to provide access to that state information. For a prevalence layer, usage of the disk is really just a reliable recovery mechanism. The “real stuff” is in memory, which is why prevalence is so much faster than a database, where all the “real stuff” is on disk. |
flaunts a shocking ignorance of database fundamentals. Any SQL Server that is not running near 99% cache hit ratio is poorly-tuned. It is particularly bad considering that this guy is talking about “prevalence” which he defines as the most naive sort of blob-oriented persistence. A proper O-R mapping layer (any of which have been around 15 years) will absolutely blow away the prevalayer type storage for all but the most trivial of queries. And in reality, all of these layers boil down to the same thing — you are either writing your own poorly-debugged database engine, or else you are writing an abstraction layer over someone else’s database engine. Of course, one can use the filesystem as a database, or a database as a filesystem, so the terminology can be stretched. But in terms of functionality, Query Processing, Storage and Indexing are rarely things that a programmer canimplement better than the professionals. Most of the innovation in terms of “persistence” layers revolves around the Data Access layer, and the fundamentals of the rest of the storage stack remain relevant.