http://www.intersystems.com/cache/technology/techguide/cache_tech-guide_complete.html
Cache Technology Guide
Introduction
Today's transaction processing applications have requirements that outstrip the capabilities of relational technology – they must span large networks, service thousands of clients, but still provide superb performance, Web compatibility, and simple operations at low cost. And they must be developed quickly!
The computing world has entered the “post-relational” era
Twenty-five years ago, relational databases were hailed as a great innovation. Instead of monolithic legacy databases, each with its unique data schema, data would be stored in a tabular format, and be accessible to anyone who knew SQL. Relational databases were highly successful, and SQL became a common standard for database access. However, as is common with older technologies, relational databases have limitations that reduce their applicability to today's world – primarily in the realms of performance/scalability, ease of use, and fit with today's development technologies.
The usage and complexity of computer applications are exploding, and today's systems increasingly have processing requirements that outstrip the capabilities of relational technology. Many key applications that demanded high performance and scalability never made the transition to relational databases, and today even simple applications are beginning to approach the limits of traditional relational technology.
“Impedance mismatch” between relational databases and today's development technologies has become a serious problem – making development more complex and the chances of failure greater. While the simplicity of tabular structures supports an elegant query language (SQL), it is difficult to decompose real world data structures into such simplistic rows and columns. The result is a huge number of tables whose relationships are hard to remember and hard to use – rows and columns are simple, but the pervasive need to program left outerjoins, stored procedures, and triggers is not.
Modern applications are usually written using object technology, which enables a faster and more intuitive way of describing and using information. Development is faster, and reliability increases. Unfortunately, objects are not natively compatible with relational databases. The advantages of object technology get blunted when the resulting database objects have to be forced into the two-dimensional relational model.
Introducing Caché
IntroductionCaché is a new generation of ultra-high-performance database technology. It combines an object database, high-performance SQL, and powerful multidimensional data access – all of which can simultaneously access the same data. Data is only described once in a single integrated data dictionary and is instantly available using all access methods. Caché provides levels of performance, scalability, rapid programming, and ease of use unattainable by relational technology.
But Caché is much more than a pure database technology. Caché includes an Application Server with advanced object programming capabilities, the ability to easily integrate with a wide variety of technologies, and an extremely high-performance run-time environment with unique data caching technology.
Caché comes with several built-in scripting languages: Caché ObjectScript, a powerful yet easy to learn object-oriented programming language; Caché Basic, a superset of the widespread Basic programming language including extensions for powerful data access and object technology; and MultiValue Basic, a different flavor of the Basic programming language with MultiValue compatible extensions.
Caché also goes beyond traditional databases by incorporating a rich environment for developing sophisticated browser-based (Web) applications. Caché Server Pages (CSP) technology allows the rapid development and execution of dynamically generated Web pages. Thousands of simultaneous Web users can access database applications, even on low-cost hardware.
For non-browser-based applications, the user interface is typically programmed in one of the popular client user interface technologies, such as VB, Delphi, Java, or C++. Best results (fastest programming, greatest performance, and lowest maintenance) are usually obtained by performing all of the rest of the development within Caché. However, Caché also provides extremely high levels of interoperability with other technologies and supports all of the most commonly used development tools, so a wide range of development methodologies are available.
Chapter One:
Data Modeling – Relational or Object Access
Early in the process of designing a new application, developers must decide upon their approach towards data modeling. For most, this comes down to a choice between the traditional modeling of data as relational tables and the newer approach of modeling as objects. Faced with the need to handle complex data, many developers believe that modeling with objects is a more effective approach.
When moving legacy applications to Caché, however, the first step is usually to migrate the existing data model. There are easy ways to import data models from various relational, object, or MultiValue representations so that the result is a standard Caché data definition. Once migrated to Caché, data can be accessed as objects, relational tables, multidimensional arrays, or MultiValue files, depending only on developers’ needs.
Multidimensional and MultiValue technologies have their devotees, but the lion’s share of new development employs either relational or object data modeling. Caché supports both SQL and object data access, and at times each is appropriate. To understand the uses of each and why data modeling with objects is generally preferred by modern-day developers, it is useful to understand how and why each has been developed.
Data Modeling
Relational Technology
In the early days of computing, information processing was done on huge mainframe systems and data access was, for the most part, limited to IT professionals. Databases tended to be home grown, and retrieving data effectively required a thorough knowledge of the database. If a user wanted a special report, he or she usually had to ask an overworked central staff to write it, and it usually wasn't available in time to influence decisions.
Although relational technology was originally developed in the 1970s on the mainframe, it remained largely a research project until it began to appear in the 1980s on mini-computers. With the advent of PCs the world entered a more “user-centric” era of computing with more user-friendly report writers based on SQL – the query language introduced by relational technology. Users could now produce their own reports and ad-hoc queries of the database, and relational usage exploded.
SQL allows a consistent language to be used to ask questions of a wide variety of data. SQL works by viewing all data in a very simple and standardized format – a two-dimensional table with rows and columns. While this simple data model allowed the construction of an elegant query language with which to ask questions, it came with a severe price. The inherent complexity of real world data relationships doesn't fit naturally into simple rows and columns, so data is often fragmented into multiple tables that must be “joined” in order to complete even simple tasks. This results in two problems: a) queries can become very difficult to write due to the need to “join” many tables (often with complex outer joins); and b) the processing overhead required when relational databases have to deal with complex data can be enormous.
SQL has become a standard for database interoperability and reporting tools. However, it is important to understand that while SQL grew out of relational databases, it need not be constrained by them. Caché supports standard SQL as a query and update language using a much stronger multidimensional database technology, and it is extended to include object capabilities.
Object Technology and Object Databases
Object programming and object databases are a practical result of work to simulate complex activities of the brain. It was observed that the brain is able to store very complex and different types of data and yet still manipulate such seemingly different information in common ways. Also, very complex behavior needed to be implemented in programs while hiding that complexity. Clearly both of these characteristics are true of today’s leading-edge applications.
Object Versus Relational Access
In object technology, the complexity of the data is contained within the object, and the data is accessed by a simple consistent interface. In contrast, relational technology also provides a simple consistent interface, but, because it does nothing to manage real-world data complexity, the user or programmer is responsible for constantly dealing with that complexity.
Because objects can model complex data simply, object programming is the best choice for programming complex applications. Similarly, object access of the database is the best choice for inserting and updating the database (i.e., for transaction processing).
Caché complements object access with an object-extended SQL query language. SQL is a powerful language for searching a database and is widely used by reporting tools. However, we believe SQL is best suited for that purpose – queries and reports – rather than for transaction processing (for which it is cumbersome and often inefficient). Caché SQL’s object extensions eliminate much of the cumbersome join syntax, making SQL even easier to use.
Overview of the Caché Object Data Model and Object Programming
The Caché object model is based upon the ODMG (Object Database Management Group) standard and supports many advanced features, including multiple inheritance.
Object technology attempts to mirror the way that humans actually think about and use information. Unlike relational tables, objects bundle together both data and code. For example, an Invoice object might have data, such as an invoice number and a total amount, and code, such as Print().
Conceptually, an object is a package that includes that object’s data values (“properties”) and a copy of all of its code (“methods”). An object’s methods send messages to communicate with other methods. To reduce storage, it is common for objects of the same class to share the same copy of code (e.g., it would be unrealistic for each Invoice object to have its own private copy of code). Also, in Caché, method calls typically result in efficient function calls rather than enduring the overhead of passing messages. However, these implementation techniques are hidden from the programmer; it is always accurate to think in terms of objects passing messages.
What is the difference between an object and a class? A class is the definitional structure and code provided by the programmer. It includes a description of the nature of data and how it is stored as well as all of the code, but it does not contain any data. An object is a particular “instance” of a class. For example, invoice #123456 is an object of the Invoice class.
Object technology also promotes a natural view of data by not restricting properties to simple, computer-centric data types. Objects may contain other objects, or references to other objects, which makes it easy to build useful and meaningful data models. Here’s a simple example of a Customer object:
[Customer object diagram artwork]
Name: Data is stored using a Name datatype.
SSN: Data might be a simple datatype, such as an integer,
or a more complex programmer-defined data type such as a 9 digit string that matches the pattern: NNN-NN-NNNN.
Address: This is an example of how objects can be embedded within other objects. In this example, Address is an embedded object that contains the properties Street and City.
AccountRep: AccountRep is a property that connects a Customer to an AccountRep object in a many-to-one relationship (many Customers to one AccountRep.) Unlike an embedded object, the related object has its own database ID and is stored separately using that ID. That ID can be used to directly access that AccountRep without accessing the Customer. In Caché the syntax for accessing an embedded or related object is the same (e.g., Customer.Address.City and Customer.AccountRep.Name use the same “dot syntax”).
Invoices: A Customer has a collection of Invoices, each of which is a complex object stored separately with its own database ID. In this example there is a one-to-many relationship between Customers and Invoices (one Customer to many Invoices) using a parent-child relationship (Invoices cannot exist without a Customer, but a Customer can exist without Invoices.) A collection of embedded objects is also possible.
Key Object Concepts
Inheritance is the ability to derive one class of objects from another. The new class (a subclass) contains all of the properties and methods of its superclass, as well as additional properties and methods unique to it. Objects of the subclass can be thought of as having an “is a” relationship to its superclass. For example, a dog “is a” mammal, so it makes sense for the Dog class to inherit all the properties and methods of the Mammal class plus have additional properties and methods such as a DogTagNumber. A subclass may also override an inherited definition (e.g., the Print() method for a subclass of the Invoice class may be different from the Print() method of Invoice). Inheritance promotes reusability of code and makes it easier to introduce major improvements.
Multiple Inheritance means a subclass can be derived from more than one superclass. For example, a dog “is a” mammal and “is a” pet, so the object class “Dog” can inherit the attributes of both the “Mammal” class and the “Pet” class.
Encapsulation means that objects can be viewed as a sort of “black box”. Public properties and methods can be accessed by any method, whereas private properties and methods can only be accessed by methods of the same class. Thus the application doesn’t need to know the internal workings of an object – it deals only with the public properties and methods. The power of encapsulation is that programmers can improve the inner workings of a class without affecting the rest of the application.
Polymorphism refers to the fact that methods used in multiple classes can share a common interface, even if the underlying implementation is different. For example, suppose the classes Letter, Mailing Label, and ID Badge all contain a method called Print. To print, an application doesn’t need to know which type of object it is accessing – it merely calls the object’s Print method.
The Caché Advantage
Caché is fully object-enabled, providing all the power of object technology to developers of high-performance transaction processing applications.
Intuitive Data Modeling: Object technology lets developers think about and use information – even extremely complex information – in simple and realistic ways, thus speeding the application development process.
Rapid Application Development: The object concepts of encapsulation, inheritance, and polymorphism allow classes to be reused, re-purposed, and shared between applications, enabling developers to leverage their work over many projects.
Why Choose Objects For Your Data Model?
For new database applications, most developers choose to use object technology because they can develop complex applications more rapidly and more easily modify them later. Object technology provides many benefits:
* Objects support a richer data structure that more naturally describes real-world data.
* Programming is simpler; it is easier to keep track of what you are doing and what you are manipulating.
* Customized versions of classes can easily replace standard ones, making it easier to customize an application.
* The black box approach of encapsulation means programmers can improve the internal workings of objects without affecting the rest of the application.
* Objects provide a simple way to connect different technologies and different applications.
* Object technology is a natural match with Java and GUI-based user interfaces.
* Many new tools assume object technology.
* Objects provide a good insulation between the user interface and the rest of the application. Thus when it becomes necessary to adopt a new user interface technology (perhaps some currently unforeseen future technology) you can reuse most of your code.
Object Data Storage...
Unfortunately, although many applications are now being written with object programming languages, they often try to force object data into flat relational tables. This significantly impairs the advantages of object technology.
Caché provides a multidimensional data structure that naturally stores rich object data. The result is faster data access and faster programming.
...Plus Relational Access
Of course many tools (such as report writers) use SQL, not object technology, for accessing data.
A unique feature of Caché is that whenever a database object class is defined, Caché automatically provides full SQL access to that data. Thus, with no additional work SQL-based tools will immediately work with Caché data, and even they will experience the high-performance advantage of the Caché Multidimensional Data Server.
The reverse is also true. When a DDL definition of a relational database is imported, Caché automatically generates an object description of the data, enabling immediate access as objects, as well as through SQL.
The Caché Unified Data Architecture keeps these access paths synchronized; there is only one data description to edit.
Chapter Two:
Caché's Multidimensional Data Server
Caché's high-performance database uses a multidimensional data engine that allows efficient and compact storage of data in a rich data structure. Objects, SQL, and MultiValue files are implemented by specifying a unified data dictionary that defines the classes and tables and provides a mapping to the multidimensional structures – a mapping that can be automatically generated.
Integrated Database Access
Caché gives programmers the freedom to store and access data through objects, SQL, or direct access to multidimensional and MultiValue structures. Regardless of the access method, all data in Caché's database is stored in Caché's multidimensional arrays.
Once the data is stored, all four access methods can be simultaneously used on the same data with full concurrency.
A unique feature of Caché is its Unified Data Architecture. Whenever a database object class is defined, Caché automatically generates a SQL-ready relational description of that data. Similarly, if a DDL description of a relational database is imported into the Data Dictionary, Caché automatically generates both a relational and an object description of the data, enabling immediate access as objects. Caché keeps these descriptions coordinated; there is only one data definition to edit. The programmer can edit and view the dictionary both from an object and a relational table perspective.
The Caché Advantage
Flexibility: Caché's data access modes – Object, SQL, multidimensional, and MultiValue, – can be used concurrently on the same data. This flexibility gives programmers the freedom to think about data in the way that makes most sense and to use the access method that best fits each program's needs.
Less Work: Caché's Unified Data Architecture automatically describes data as both objects and tables with a single definition. There is no need to code transformations, so applications can be developed and maintained more easily.
Leverage Existing Skills and Applications: Programmers can leverage existing relational skills and introduce object capabilities gradually into existing applications as they evolve.
Multidimensional Data Model & Multivalue Files
At its core, the Caché database is powered by an extremely efficient multidimensional data engine. Direct access to multidimensional structures is provided by built-in Caché scripting languages – providing the highest performance and greatest range of storage possibilities – and many applications are implemented entirely using this data engine directly. Direct “global access” is particularly common when there are unusual or very specialized structures and no need to provide object or SQL access to them, or where the highest possible performance is required.
There is no data dictionary, and thus no data definitions, for the multidimensional data engine.
Rich Multidimensional Data Structure
Caché’s multidimensional arrays are called “globals”. Data can be stored in a global with any number of subscripts. What’s more, subscripts are typeless and can hold any sort of data. One subscript might be an integer, such as 34, while another could be a meaningful name, like “LineItems”– even at the same subscript level.
For example, a stock inventory application that provides information about item, size, color, and pattern might have a structure like this:
^Stock(item,size,color,pattern) = quantity
Here’s some sample data:
^Stock(“slip dress”,4,”blue”,”floral”)=3
With this structure it is very easy to determine if there are any size 4 blue slip dresses with a floral pattern – simply by accessing that data node. If a customer wants a size 4 slip dress and is uncertain about color and pattern, it is easy to display a list of all of those by cycling through all of the data nodes below
^Stock(“slip dress”,4)
In this example all of the data nodes were of a similar nature (they stored a quantity), and they were all stored at the same subscript level (4 subscripts) with similar subscripts (the 3rd subscript was always text representing a color). However, they don’t have to be. Not all data nodes have to have the same number or type of subscripts, and they may contain different types of data.
Here’s an example of a more complex global with invoice data that has different types of data stored at different subscript levels:
^Invoice(invoice #,”Customer”) = Customer information
^Invoice(invoice #,”Date”) = Invoice date
^Invoice(invoice #,”Items”) = # of Items in the invoice
^Invoice(invoice #,”Items”,1,”Part”) = part number of 1st Item
^Invoice(invoice #,”Items”,1,”Quantity”) = quantity of 1st Item
^Invoice(invoice #,”Items”,1,”Price”) = price of 1st Item
^Invoice(invoice #,”Items”,2,”Part”) = part number of 2nd Item
etc.
Multiple Data Elements per Node
Multiple Data Elements per NodeOften only a single data element is stored in a data node, such as a date or quantity, but sometimes it is useful to store multiple data elements together in a single data node. This is particularly useful when there is a set of related data that is often accessed together. It can also improve performance by requiring fewer accesses of the database.
For example, in the preceding invoice example each item included a part number, quantity, and price all stored as separate nodes, but they could be stored as a list of elements in a single node:
^Invoice(invoice #,”LineItems”,item #)
To make this simple, Caché supports a function called $list() which can assemble multiple data elements into a length delimited byte string and later disassemble them. Sub-elements can in turn contain sub-sub-elements etc.
MultiValue Files
From MultiValue Basic, Caché provides native MultiValue file access to data stored in multidimensional globals. This feature relies on Caché’s ability to store multiple data elements per global node.
For example, if the invoice example was implemented as a MultiValue file INVOICE-FILE, this could have the following structure:
Invoice # Item id
Customer information Attribute 1
Invoice date Attribute 2
Parts Attribute 3 (MultiValued)
Quantities Attribute 4 (MultiValued)
Prices Attribute 5 (MultiValued)
Caché will internally represent this MultiValue file as the equivalent multidimensional global structure:
^Invoice(invoice #)
Customer Information @AM Invoice Date @AM PartNo1 @VM PartNo2 @AM
Quantity1 @VM Quantity2 @AM Price1 @VM Price2
Logical Locking Promotes High Concurrency
In systems with thousands of users, reducing conflicts between competing processes is critical to providing high throughput. One of the biggest conflicts is between transactions wishing to access the same data.
Caché processes don’t lock entire pages of data while performing updates. Instead, because transactions require frequent access or changes to small quantities of data, database locking in Caché is done at a logical level. Database conflicts are further reduced by using atomic addition and subtraction operations, which don’t require locking. (These operations are particularly useful in incrementing counters used to allocate ID numbers and for modifying statistics counters.)
With Caché, individual transactions run faster, and more transactions can run concurrently.
Variable Length Data in Sparse Arrays
Because Caché data is inherently variable length and is stored in sparse arrays, Caché often requires less than one half of the space needed by a relational database. In addition to reducing disk requirements, compact data storage enhances performance because more data can be read or written with a single I/O operation, and data can be cached more efficiently.
Declarations and Definitions Aren’t Required
Caché multidimensional arrays are inherently typeless, both in their data and subscripts. No declarations, definitions, or allocations of storage are required. Global data simply pops into existence as data is inserted.
Namespaces
In Caché, data and code are stored in disk files with the name CACHE.DAT (only one per directory). Each such file contains numerous “globals” (multidimensional arrays). Within a file, each global name must be unique, but different files may contain the same global name. These files may be loosely thought of as databases.
Rather than specifying which database file to use, each Caché process uses a “namespace” to access data. A namespace is a logical map that maps the names of multidimensional global arrays and code to databases. If a database is moved from one disk drive or computer to another, only the namespace map needs to be updated. The application itself is unchanged.
Usually, other than some system information, all data for a namespace is stored in a single database. However, namespaces provide a flexible structure that allows arbitrary mapping, and it is not unusual for a namespace to map the contents of several databases, including some on other computers.
The Caché Advantage
Performance: By using an efficient multidimensional data model with sparse storage techniques instead of a cumbersome maze of two-dimensional tables, data access and updates are accomplished with less disk I/O. Reduced I/O means that applications will run faster.
Scalability: The transactional multidimensional data model allows Caché-based applications to be scaled to many thousands of clients without sacrificing high performance. That’s because data access in a multidimensional model is not significantly affected by the size or complexity of the database in comparison to relational models. Transactions can access the data they need without performing complicated joins or bouncing from table to table.
Caché’s use of logical locking for updates instead of locking physical pages is another important contributor to concurrency, as is its sophisticated data caching across networks.
Rapid Development: With Caché, development occurs much faster because the data structure provides natural, easily understood storage of complex data and doesn’t require extensive or complicated declarations and definitions. Direct access to globals is very simple, allowing the same language syntax as accessing local arrays.
Cost-Effectiveness: Compared to comparably sized relational applications, Caché-based applications require significantly less hardware and fewer database administrators. System management and operations are simple.
SQL Access
SQL is the query language for Caché, and it supports a full set of relational database capabilities – including DDL, transactions, referential integrity, triggers, stored procedures, and more. Caché supports access through ODBC and JDBC (using a pure Java-based driver). SQL commands and queries can also be embedded in Caché ObjectScript and within object methods.
SQL accesses data viewed as tables with rows and columns. Because Caché data is actually stored in efficient multidimensional structures, applications that use SQL achieve better performance with Caché than when they run against traditional relational databases. The performance is apparent both with highly efficient compiled queries, as well as with the execution of dynamic (defined at run time) SQL statements.
Caché supports, in addition to the standard SQL syntax, many of the commonly used extensions in other databases so that many SQL-based applications can run on Caché without change – especially those written with database independent tools. However, vendor-specific stored procedures will require some work, and InterSystems has translators to help with that work.
Caché SQL includes object enhancements that make SQL code simpler and more intuitive to read and write.
Traditional SQL
SELECT
SC.FullName, SM.Descr, MS.Value, SI.InvDate, SI.InvNumber
FROM
MainSales MS, SalesItemSI, SalesProduct SP, Sales Customer SC, SalesMarket SM
WHERE
SI.SalesItemID *=MS.SalesItem
AND SP.SalesProductID *=MS.Product
AND SC.SalesCustomerID *=MS.Customer
AND SM.SalesMarketID *= SC.SalesMarket
AND SP.DESCR = "Hammer"
Object Extended SQL
SELECT
Customer->FullName,
Customer->SalesMarket->Descr, Valus,
SalesItem->InvData, SalesItem->InvNumber
FROM MainSales
WHERE Product->Descr = 'Hammer'
Accessing Relational Databases with Caché Relational Gateway
Relational Gateway
The Relational Gateway allows applications built in Caché to access relational data.
The Caché Relational Gateway enables a SQL request that originates in Caché to be sent to other (relational) databases for processing. Using the Gateway, a Caché application can retrieve and update data stored in most relational databases.
Additionally, if Caché database classes are compiled using the CachéSQLStorage option, the Gateway allows Caché applications to transparently use relational databases. However, applications will run faster and be more scalable if they access Caché’s post-relational database.
Multivalue Query Language
Caché’s implementation of the MultiValue query language is based on Caché’s very high performance SQL engine. Developers may choose to use either Caché MultiValue Query Language (CMQL) or SQL for the rapid generation of reports.
CMQL supports SELECT, LIST, and related commands. SELECT lists can be manipulated throughout the environment. Existing MultiValue queries and dictionaries and be used “as is” with support provided for A types, S types, D types, etc., as well as A and F correlatives, I types, and the full range of conversions and correlatives.
LIST CUSTOMER BY CODE CODE NAME HEADING “‘C’COMPANY X (‘T’)
(Page: ‘S’) ‘LLC’ CUSTOMER NAMES ‘L’” ID.SUP
The Caché Advantage
Faster SQL: Relational applications can enjoy significantly enhanced performance by using Caché SQL to tap into Caché’s efficient post-relational database.
Faster Development: In Caché, SQL queries can be written more intuitively, using fewer lines of code.
Compatibility With Existing Applications and Report Writers: Caché’s native ODBC and JDBC drivers, together with its support for CMQL, provide high performance interoperability with conventional applications, including most popular data analysis and reporting tools.
Caché Objects
Caché’s object model is based upon the ODMG standard. Caché supports a full array of object programming concepts including encapsulation, embedded objects, multiple inheritance, polymorphism, and collections.
The built-in Caché scripting languages directly manipulate these objects, and Caché also exposes Caché classes as Java, EJB, COM, .NET, and C++ classes. Caché classes can also be automatically enabled for XML and SOAP support by simply clicking a button in the Studio IDE. As a result, Caché objects are readily available to every commonly used object technology.
State for Caché objects is always maintained in the Caché Application Server. When a Java, C++, C#, Visual Basic, or other program outside of the Application Server accesses a Caché object, it calls a template of the class in the native language. That template class (which is automatically generated by Caché) communicates with the Caché Application Server to invoke methods on the Caché server and to access or modify properties. To speed execution and reduce messaging, Caché caches a copy of the object’s data on the client and piggy-backs updates with other messages when possible. To the user program, it looks like the object is local; Caché transparently handles all communications with the server. The Java template and supporting library is completely Java-based, so it can be used across the Web or on specialized Java devices.
Method Generators
Caché includes a number of unique advanced object technologies – one of which is method generators. A method generator is a method that executes at compile time, generating code that can run when the program is executed. A method generator has access to class definitions, including property and method definitions and parameters, to allow it to generate a method that is customized for the class. Method generators are particularly powerful in combination with multiple inheritance – functionality can be defined in a multiply inherited class that customizes itself to the subclass.
The Caché Advantage
Caché is fully object-enabled, providing all the power of object technology to developers of high-performance transaction processing applications.
Rapid Application Development: Object technology is a powerful tool for increasing programmer productivity. Developers can think about and use objects – even extremely complex objects – in simple and realistic ways, thus speeding the application development process. Also, the innate modularity and interoperability of objects simplifies application maintenance, and lets programmers leverage their work over many projects.
Transactional Bit-Map Indexing
Caché uniquely provides Transactional Bit-Map Indexing, which can radically increase performance of complex queries giving fast data warehouse query performance on live data.
Database performance is critically dependent on having indexes on properties that are frequently used in searching the database. Most databases use indexes that, for each possible value of the column or property, maintain a list of the row IDs (or object IDs) for the rows/objects that have that value. A bit-map index is another type of index. Bit-map indexes contain a separate bitmap for each possible value of a column/property, with one bit for each row/object that is stored. A 1 bit means that the row/object has that value for the column/property.
The advantage of bit-map indexes is that complex queries can be processed by performing Boolean operations (AND, OR) on the indexes – efficiently determining exactly which instances (rows) fit the query conditions, without searching through the entire database. Bit-map indexes can often boost response times for queries that search large volumes of data by a factor of 100 or more. Bit-maps traditionally suffer from two problems: a) they can be painfully slow to update in relational databases, and b) they can take up far too much storage. Thus with relational databases, they are rarely used for transaction processing applications.
Caché has introduced a new technology – “transactional bit-map indexes” – that leverages multidimensional data structures to eliminate these two problems. Updating these bit-maps is often faster than traditional indexes, and they utilize sophisticated compression techniques to radically reduce storage. The result is ultra-fast bit-maps that can often be used to search millions of records in a fraction of a second on an on-line transaction-processing database. Business intelligence and data warehousing applications can work with “live” data.
Caché offers both traditional and transactional bit-map indexes. Caché also supports multi-column indexes. For example, an index on State and CarModel, can quickly identify everyone who has a car of a particular type that is registered in a particular state.
The Caché Advantage
Radically Faster Queries: By using transactional bit-map techniques, users can get blazing fast searches of large databases – often millions of records can be searched in a fraction of a second – on a system that is primarily used for transaction processing.
Real-Time Data Analytics: Caché’s Transactional Bit-Map Indexing allows real-time data analytics on up-to-the-minute data.
Lower Cost: There is no need for a second computer dedicated to data warehouse and decision support. Nor is there any need for daily operations to transfer data to such a second system or database administrators to support it.
Scalability: The speed of transactional bit-maps enhances the ability to build systems with enormous amounts of data that need to be maintained and periodically searched.
Enterprise Cache Protocol For Distributed Systems
Scalable Performance in Distributed Systems
InterSystems’ Enterprise Cache Protocol (ECP) is an extremely high performance and scalable technology that enables computers in a distributed system to use each other’s databases. The use of ECP requires no application changes – applications simply treat the database as if it was local.
Here’s how ECP works. Each Application Server includes its own Data Server, which can operate on data that resides in its own disk systems or on blocks that were transferred to it from another Data Server by ECP. When a client makes a request for information, the Caché Application Server will attempt to satisfy the request from its local cache. If it cannot, it will request the necessary data from the remote Caché Data Server. The reply includes the database block(s) where that data was stored. These blocks are cached on the Application Server, where they are available to all applications running on that server. ECP automatically takes care of managing cache consistency across the network and propagating changes back to Data Servers.
The performance and scalability benefits of ECP are dramatic. Clients enjoy fast responses because they frequently use locally cached data. And caching greatly reduces network traffic between the database and application servers, so any given network can support many more servers and clients.
DataServer
Easy to Use – No Application Changes
The use of ECP is transparent to applications. Applications written to run on a single server run in a multi-server environment without change. To use ECP, the system manager simply identifies one or more Data Servers to an Application Server and then uses Namespace Mapping to indicate that references to some or all global structures (or portions of global structures) refer to that remote Data Server.
Configuration Flexibility
Every Caché system can function both as an Application Server and as a Data Server for other systems. ECP supports any combination of Application Servers and Data Servers and any point-to-point topology of up to 255 systems.
Object Synchronization
In most distributed applications, under normal circumstances the data server is always available and updates to the database are made in real time. But some applications – by design – are only occasionally connected to a data server. For such “occasionally connected” applications, Caché supports object synchronization.
What is Synchronization?
24-Hour OperationsConsider the example of a sales application in which each traveling representative carries a copy of the sales database on their laptop computer. Each representative makes changes to their copy of the database. The next time they connect to the office network, their copy must be “synchronized” with the central database – updates made on their laptop must be applied to the central system, and the remote system must be updated with any changes to the central database that were generated by other representatives.
GUIDs
Synchronization cannot work unless every object in a database has a unique identifier. For classes that will need to be synchronized, developers can set a parameter to tell Caché to use Globally Unique IDs (GUIDs). When enabled, Caché assigns every instantiation of the class (every object) a GUID, thus making that object universally unique.
Resolving Conflicts
If an object has been changed in both the source and target databases, Caché flags this as a conflict. Caché provides a class method where developers can create code to try and resolve conflicts programmatically. If this fails, other means must be used.
The Caché Advantage
Massive Scalability: Caché’s Enterprise Cache Protocol allows the addition of application servers as usage grows, each of which uses the database as if it was a local database. If disk throughput becomes a bottleneck, more Data Servers can be added, and the database becomes logically partitioned.
Higher Availability: Because users are spread across multiple computers, the failure of an Application Server affects a smaller population. Should a Data Server “crash” and be re-booted, or there is a temporary network outage, the Application Servers can continue processing with no observable effects other than a slight pause. In some configurations, a Data Server can also be configured to fail-over to a Shadow Server or clustered system, further enhancing reliability.
Lower Costs: Large numbers of low-cost computers can be combined into an extremely powerful system supporting massive processing – “grid computing”.
Transparent Usage: Applications don’t need to be written specifically for ECP – Caché applications can automatically take advantage of ECP without change.
Resiliency
Outages happen. Some are planned, such as when a system is brought down for reconfiguration or upgrades. Some are unplanned, perhaps caused by a glitch or someone tripping over a power cord. Some can be classified as disasters, for example, a fire in the building, or a neighborhoodwide power loss. Resiliency refers to a system’s ability to adapt to and recover from outages. By providing a variety of resiliency features, Caché gives system architects options when it comes to balancing cost, system availability, and database state retention.
Fault Tolerance in Distributed Systems
For distributed systems using Enterprise Cache Protocol, upon a temporary network outage or a Data Server crash and reboot, the servers attempt to reconnect. If a successful reconnect occurs within a specified time period, the Application Servers resend any uncompleted requests and operations continue with no observable effect to users of the remote Application Servers other than a slight pause. Otherwise open transactions are rolled back and user processes are issued an error. In some configurations, a Data Server can also be configured to fail-over to a Shadow Server or cluster member, further enhancing reliability. The new Server resumes processing for the failed Data Server, allowing uninterrupted operation.
Clusters
In a database cluster, two or more servers can access the same database. They are configured so that if one server fails, the other members of the cluster take on the jobs it was performing. Users will notice little or no interruption of operations, depending on the system architecture.
A Failover Cluster
A Failover Cluster
Failover Clusters
One common architecture is the failover cluster, in which multiple data servers share access to a database, but only one is active at a time. If the active server fails, the standby server automatically takes over. Depending on the operating system, the failover may take as much as a few minutes. Caché’s Enterprise Cache Protocol (ECP) provides a unique advantage in this kind of system because transactions, although they may be delayed, will not be lost.
Shared Clusters
Another type of cluster is the shared database cluster, in which all members of the cluster can simultaneously access the database. This system ensures that the database remains available, but may require additional hardware or administration. Caché currently* supports shared database clusters on the Alpha OpenVMS and Unix TRU64 platforms.
Shadow Servers
Some systems use a shadow server – a server that constantly reads the journal of the primary server and maintains a real-time duplicate of the database. Depending on the system architecture, the latency – the time between when a change occurs in the primary database, and when it occurs in the shadow database – will typically run from a fraction of a second up to as much as a few seconds. Caché has the capability of measuring the latency in a shadowed system. It also includes provisions for rolling back transactions that have not been shadowed when a failure occurs.
Shadowing can be used for a clustered system, thus providing both availability and database state retention. In a shadowed cluster, each member of the cluster writes to a separate journal. Journals are transferred to the shadow server. When they are de-journaled, instructions are applied in order according to the cluster journal sequence number.
Shadowing a Clustered System
Shadowing a Clustered System
* Support on other platforms is planned. Check with your account representative for availability.
The Caché Advantage
High Availability During Minor Outages: Architectures that use Caché’s cluster technology can sustain partial failure with little or no noticeable effect on the users.
Rapid State Recovery after Significant Outages: Caché supports server shadowing, enabling the existence of a duplicate database that is “up to date” within a few seconds of the primary system. This allows systems to recover from the loss or corruption of the primary database in the shortest possible time.
Simple System Management / 24-Hour Database Operation
Caché is designed to run 24 hours a day, every day of the year, on systems ranging from small 4-user systems to systems with tens of thousands of users. Many Caché installations are performed by Application Partners, who often have a need to install large systems but can't afford to provide on-going extensive system management support. These requirements place great demands on the needs for simplicity while supporting the sophisticated needs of large sites.
In Caché there is no need to perform operations such as periodically rebuilding indexes for performance or reloading a database when a new version is released, as is common with some relational systems. Such operations are neither simple nor conducive to 24-hour operation.
Caché includes a full complement of system management utilities, all of which can be accessed remotely. Major system management functions can be scripted for unattended operation.
Unattended Back-up while the Database is being Updated
Caché supports full, incremental, and cumulative incremental back-ups. These back-ups can be performed while the database is up and running, including while database updates are occurring. Back-ups can be scripted so they are performed automatically without an operator.
Hardware and Database Reconfigurations Without Downtime
On each system, Caché maintains "namespace maps" that specify where data and code is stored. Changes to the system, even major changes such as adding a database server or switching to a backup server, can be accomplished by revising the namespace map. Scheduled reconfigurations can be done dynamically, without down time, in a manner transparent to applications. Contingency Namespace Maps can be configured to compensate for a variety of failure scenarios.
Introducing Source Changes on a Running System
It is not always practical to halt operations to introduce code changes, and with thousands of PCs and multiple servers, introducing changes can be a real problem.
Caché simplifies this process. To introduce a change in Caché ObjectScript or Basic into a running system, simply load the changed source routine onto the single Data Server where the code resides. The code will be automatically compiled – no linking is required – and Application Servers will be notified they need to reload the revised routine. Of course, such changes should be introduced with caution; a process that made a call from the old version to another routine will get an error upon attempting to return to the changed routine.
Caché Monitor
The Caché System Monitor is an extendable system monitor facility. It provides services for gathering and monitoring performance and system data, generating alerts, handling notifications, and maintaining a persistent repository of such data. Users can filter and search the repository according the severity assigned to various system events, and automatically initiate actions (pages, emails, etc.) based on the results.
The Caché Monitor also supports the Simple Network Management Protocol (SNMP), thus enabling the monitoring of Caché by a variety of third-party system management tools and frameworks.
The Caché Advantage
Simplified System Management: Caché is designed to make day-to-day system management easy by automating required tasks (such as back-ups) and eliminating many administrative tasks common in other databases. Less system management translates into less trouble and lower costs.
No DBA: Caché is so easy to manage, most installations do not even have a DBA.
Dynamic Reconfiguration: Dynamic namespace mapping allows system reconfiguration to be accomplished “on the fly”, without interrupting application availability.
Robust 24-Hour Operation: On-line back-up, Shadow Servers, and Database Clusters support 24-hour operation and seamless recovery from failures.
Easy and Flexible System Monitoring: Caché can easily be configured to monitor system events and take appropriate action based on their severity. Minor occurrences won’t trigger late night phone calls.
Chapter Three:
Caché's Application Server
The Caché Application Server offers advanced object programming capabilities, provides sophisticated data caching, and integrates easy access to a variety of technologies. The Caché Application Server makes it possible to develop sophisticated database applications rapidly, operate them with high performance, and support them easily.
More specifically, the Caché Application Server provides:
* The Caché Virtual Machine which runs four built-in scripting languages – Caché ObjectScript, Caché Basic, MultiValue Basic, and MultiValue PROCs.
* Access to Caché Multidimensional Data Servers on the same and other computers with transparent routing.
* Connectivity software with client side caching to permit rapid access to Caché Objects from all commonly used technologies, including Java, C++, C#, COM, .NET, Visual Basic, and Delphi. Caché automatically performs the networking between the client and Application Server.
* Compatibility with SOAP and XML.
* SQL access using ODBC and JDBC, including sophisticated caching at the client and application server for high performance.
* Access to relational databases.
* Caché Server Pages for high-performance, easy-to-program Web applications.
* Caché Studio – an IDE to rapidly develop and debug applications with Caché.
* Code for the Scripting Languages is stored in the database and can be changed on-line, with changes automatically propagating to all application servers.
The Caché Virtual Machine and Scripting Languages
The core of the Caché Application Server is the extremely fast Caché Virtual Machine, which supports Caché's three scripting languages – Caché ObjectScript, Basic, and MVBasic. (MultiValue PROCs can also be compiled within Caché and run in the Caché Virtual Machine.)
* Caché ObjectScript is a powerful and easy-to-learn object-oriented language with extremely flexible data structures.
* Basic provides an easy way for Visual Basic programmers to start using Caché. Similar to VBScript, Basic is extended to have direct access to the Caché multidimensional arrays.
* MVBasic is the flavor of the Basic programming languages used in MultiValue systems. MultiValue commands and queries are executable from the provided command shell as well as from MVBasic and MultiValue PROCs.
Database access within the Caché Virtual Machine is highly optimized. Each user process in the Caché Virtual Machine has direct access to the multidimensional data structures by making calls to shared memory that access a shared database cache. All other technologies (Java, C++, ODBC, JDBC, etc.) connect through the Caché Virtual Machine to access the database.
Complete Interoperability
Since Caché ObjectScript, Caché Basic, and MVBasic are all implemented on the same Caché Virtual Machine, they are completely interoperable:
* Any object method can be written in any language – the same class can use all three languages.
* Each language can make calls to code written in the other languages.
* They share variables, arrays, and objects.
Faster Development / Flexible Deployment
In almost all cases, programmers can develop applications faster, and those applications will run significantly faster with greater scalability, by writing as much code as possible in these scripting languages – ObjectScript, Basic, and MVBasic – so that they run in the Caché Virtual Machine. Plus, such code requires no changes to switch hardware or operating systems. Caché automatically handles all differences in operating system and hardware.
Scripting Languages
A Failover Cluster
The Caché Advantage
Rapid Application Development: Development of complex database applications with Caché ObjectScript is radically faster than any other major language – often 10 to 100 times faster. Faster also means the project has a better chance of succeeding – with fewer programmers – and being able to adjust rapidly as application needs change.
Shorter Learning Curve: Basic is perhaps the world’s best known computer language. Developers who know Visual Basic can instantly start writing code in Basic, and the Caché object model is easily learned.
Faster and More Scalable: The Caché Virtual Machine with its direct access to the database provides faster applications that can scale to tens of thousands of users using low-cost hardware.
Flexibility: Code that runs in the Caché Virtual Machine can run on other hardware and operating systems without change. Code is stored in the database and automatically propagated to Application Servers.
Caché ObjectScript
Caché ObjectScript is a powerful, object-oriented programming language designed for rapid development of database applications. Here are some of the key characteristics of the language.
Overall Structure
Caché ObjectScript is command oriented; hence it has syntax such as:
set x=a+b
do rotate(a,3)
if (x>3)
There is a set of built-in system functions that are particularly powerful for text manipulation. Their names all start with the single ‘$’ character to distinguish them from variable and array names. For example:
$extract(string,from,to)
// get a set of characters from a string
$length(string)
// determine the length of a string
Expressions use left-to-right operator precedence, just like most hand-held calculators, except when parentheses alter the order of evaluation.
Flexible Data Storage
One of the most unique characteristics of Caché ObjectScript is its highly flexible and dynamic data storage. Data may be stored in:
* object properties.
* variables.
* sparse, multidimensional arrays that permit any type of data for subscripts.
* database files (“globals”) which are sparse multidimensional arrays.
With rare exceptions, any place in the language where a variable can be used, an array, object property, or global reference could also be used.
In most computer languages, datatypes are an extension of hardware storage concepts (integer, float, character, etc.). However, Caché ObjectScript has the philosophy that humans don’t think using such storage types, and that these “computer-centric” datatypes simply impede rapid application development. Requiring declarations and dimension statements introduces far more errors than they help prevent (errors such as a 2-byte integer overflow, or when a string overflows its allocation of memory and corrupts other storage). However, object typing, such as Person, Invoice, or Animal, is viewed as highly valuable and consistent with the way humans think.
Thus, in Caché ObjectScript, object properties are strongly typed, but the other three types of storage (variables, arrays, and global nodes) are fully polymorphic, typeless entities that need not be declared or defined. They simply pop into existence as they are used and mold themselves to the data needs of what they are storing and how they are being used in an expression. Even arrays do not need any specification of size or dimension or type of subscripts or data. For example, a developer might create an array called Person by simply setting:
set Person(”Smith”,”John”)=”I’m a good person”
In this example, data was stored in a two-dimensional array using string data for subscripts. Other data nodes in this array might have a different number of dimensions and might intermix strings, integers, or other types of data for subscripts. For example, in the same array, one might store data in:
abc(3)
abc(3,-45.6,”Yes”)
abc(”Count”)
Direct Access to the Database
Direct Accessdirect reference to the database (a “global reference”) is essentially a multidimensional array reference preceded by the carat character ‘^’. That character indicates this is a reference to data stored in the database rather than to temporary process private data. Each such database array is called a “global”.
As with multidimensional arrays and variables, no declarations or definitions or reservations of storage are required to access or store data in the database; global data simply pops into existence as data is stored. For example, to store information in the database one might write:
set ^Person(“Smith”,”John”)=”I’m a very good person”
and later might retrieve it by code such as:
set x=^Person(“Smith”,”John”)
The programmer has complete flexibility in how to structure these global data arrays.
(See the Multidimensional Data Model.)
Object References
Caché Objects implement the ODMG data model with powerful extensions.
In Caché ObjectScript an “oref” is used to access an object (an “oref” is typically a variable whose value specifies which in-memory object is being referenced). The “oref” is followed by a dot and then by the name of a property or method. Object references can be used wherever an expression can be used. For example:
set name=person.Name
// ‘person’ is a variable whose
// value is an oref
// the person’s name is put into
// the variable ‘name’
if (person.Age>x)
// see if the person’s age is
//greater than ‘x’
set money=invoice.Total()
// ‘Total()’ is a method that
// calculates the sum of
// all of the invoice’s
// line items
Methods can also be executed with a DO command when no return value is needed. For example:
do part.Increment()
// ‘Increment()’ is a method whose
// return value, if any,
// is ignored
The “oref” is not the same as a database object ID. The object ID is a value that is permanently associated with a database object; it is used to retrieve and store a database object. Once an object is in memory, it is assigned a reusable “oref” value that is then used to access the object’s data. The next time that same database object is brought into memory it will probably be assigned a different “oref” value.
HTML and SQL Access
HTML for Web applications and SQL can be embedded in Caché ObjectScript code.
Calling Code
In some object languages, all code has to be part of some method. Caché ObjectScript doesn’t have that restriction – code may be directly called or called through object syntax.
Code is often called using the DO command.
do rotate(a,3)
Code that returns a value can also be called as a function. For example,
set x=a+$$insert(3,y)
calls the programmer-written procedure or subroutine “insert”.
Code can also be invoked as an object method.
set money=invoice.Total()
// Total() returns the
//invoice total amountdo
do part.Increment()
// ‘Increment()’ is a method
// whose return value,
// if any, is not of interest
Both call by value and call by reference is supported for parameters.
Routines
Caché ObjectScript code is fundamentally organized into a set of “routines”. Within a routine, code is organized as a set of procedures and/or subroutines.
When calling code that is within the same routine, only the procedure or subroutine name is needed. Otherwise, the routine name must be appended to it.
do transfer()
// calls ‘transfer’ in
// the same routine
do total^invoice()
// calls ‘total’ in the
// routine ‘invoice’
A procedure or subroutine that has a return value of interest should be called using the “$$” function syntax.
set x=$$total^invoice()
// calls the same ‘total’
// procedure but uses the
// return value
Routines can be edited and compiled through the Caché Studio.
Object Methods
Class definitions and their method code are stored in global data files, and the Class Compiler compiles each class into one or more routines. Each method is simply a procedure in a routine, although it can only be invoked by object syntax. For instance, if the Patient class defines an Admit method and the Pat variable identifies a specific Patient object, then we call the Admit method for that object with the following syntax:
do Pat.Admit()
// Call the admit method
// for Patient
set x = Pat.Admit()
// Calls the same method
// but uses the return value
Procedures and Public/Private Variables
A procedure is a block of code within a routine that is similar to a function in other languages. A procedure consists of a name, a formal parameter list, a list of public variables, and a block of code delimited by ‘{}’. For example:
Admit(x,y)[name,recnum] { ...code goes here}
In Caché ObjectScript, some variables are common and others are private to a particular procedure. Every variable that is used within a procedure is considered private to that procedure unless it is listed in the public list. In the above example, ‘name’ and ‘recnum’ access the public variables by those names, whereas all other variables exist only for this invocation of this procedure. Variable names that start with a ‘%’ character are always implicitly public.
Procedures cannot be nested, although a procedure can contain subroutines.
Subroutines
SubroutinesRoutines may also contain subroutines, which are lighter weight than procedures. A subroutine may contain a parameter list and it may return a value, but it does not have a public list or formal block structure. Subroutines may be embedded within procedures or be at the same level as a procedure in a routine.
Subroutines permit the calling of code using the same public/private set of variables as the caller, and they can be called quicker. A subroutine embedded within a procedure uses the same variable scope as the procedure and may only be called from within that procedure. Variable references for a subroutine that is not part of a procedure are all to public variables.
BASIC
Basic is perhaps the world’s best-known application programming language. In Caché, Basic has been extended to support direct access of the Data Server’s core data structures – multidimensional arrays – as well as other Caché Application Server features. It directly supports the Caché Object Model using Visual Basic syntax, and runs in the Caché Virtual Machine.
Basic can be used either as methods of classes or as Caché routines (see the Caché ObjectScript description of routines.) Basic can call Caché ObjectScript, and vice-versa, with both languages accessing the same variables, arrays, and objects in process memory.
Arrays have been extended to be far more powerful:
* The presence of a ‘^’ character preceding the array name indicates a reference to a database multidimensional array – persistent arrays that are shared with other processes.
* Subscripts can be of any datatype – strings, integers, decimal numbers, etc.
* Data can be stored at multiple subscript levels in the same array – for example, data could be stored at A(“colors”) and A(“colors”,3).
* Arrays do not have to be declared and they are always sparse – Caché only reserves space as nodes are inserted.
* A Traverse function allows identification of the next (or previous) subscript at a given subscript level.
Other extensions include:
* Transaction processing commands to Start, Commit, and Rollback a transaction.
* An atomic increment function that can be used on the database.
* Extensions that provide better integration with the Caché Application Server capabilities.
Object Access with Basic
In Caché, classes are organized into packages, and class names include the package name followed by a period. For example, Sample.Person is a Person class of the Sample package.
The Basic New command is used to create an object. Basic has been extended with an OpenID command to access an existing object:
person = New Sample.Person()
// creates a new
// Person object
person = OpenID Sample.Person(54)
// opens the Person
// object with OID 54
Here are some examples of code that access the person’s properties:
person.Name = ”Smith, John”
// sets the person’s name
person.Home.City
// references the
// person’s home city
person.Employer.Name
// brings the person’s
// employer object into
// memory and accesses
// the employer’s name
Database classes can be saved to disk with the Save method. For example:
person.Save()
will save the person, creating an object ID if it is the first time the object was stored. If related objects (such as the Employer) were also modified, they are automatically saved as well.
Caché Technology Guide
MVBasic
MVBasic is an alternative scripting language offered in Caché that is very similar to the implementation of the Basic language described above. However, it is intended to execute applications written for MultiValue systems and therefore supports additional characteristics:
* Capabilities to access and manipulate MultiValue files.
* Support for dynamic arrays.
* Access to the results of MultiValue commands and queries.
MVBasic can be used either as methods of classes or as Caché routines (see the Caché ObjectScript description of routines.) MVBasic can call Caché ObjectScript, and vice-versa, with both languages accessing the same variables, arrays, and objects in process memory.
Java
Java is an increasingly popular programming technology, but connecting Java applications to a database can be challenging. Connecting to a relational database requires extensive coding of SQL — which is very time consuming and blunts many of the advantages of Java’s object technology. Direct object syntax to access the database is usually preferred, and some like the functionality of Enterprise Java Beans. Caché supports all of these approaches:
Java Supported Several Ways
Caché & Java Access
* Any Caché class can be projected as a Java class, so properties and methods can be accessed as Java objects.
* Caché classes can also be projected as Enterprise Java Beans (EJB).
* JDBC provides high performance SQL access using a completely Java-based (Type 4) driver.
Object Access Through Projected Classes
Every Caché class can be projected as a Java (or EJB) class, with methods corresponding to every property and method of the Caché class. To Java programs these classes look just like any other local Java classes. The generated Java class uses a Java library provided by InterSystems to handle all communications between the client and server.
State for every Caché object is maintained in the Caché Application Server, although properties of the class are also cached in the client to optimize performance. Java method calls invoke corresponding methods on the Caché Application Server – including methods to store an object in the database and later retrieve it. It is transparent to the client as to which Caché Data Server contains the data, or even if the object data is stored in a relational database accessed through the Caché Application Server.
Caché Methods Written in Java
Methods of Caché classes can be written in Java using Caché Studio. However, unlike Caché ObjectScript and Basic, Java methods are not executed by the Caché Virtual Machine. Instead, they are included in the generated Java class and executed in any Java Virtual Machine. Such code is not accessible from non-Java methods.
Providing Persistence for J2EE Applications
Developers of J2EE applications, which use Enterprise Java Beans (EJB), work primarily with objects until such time as they need to access the database. Then they are usually forced to revert to using SQL. Through its JDBC interface, Caché can provide extremely fast SQL response to such applications. However, SQL access is not generally the preferred approach.
Object databases represent a more natural access technique to EJB programmers. Caché projects Caché classes as EJBs, automatically generating high-performance persistence methods for Bean-Managed Persistence (BMP). This avoids the overhead of SQL and object/relational mapping – the result is higher scalability for J2EE applications.
High Performance Strategies with Java
Code in the Caché Virtual Machine usually executes faster than code in a Java Virtual Machine, and it is also usually much faster to develop. Although it is possible to build complete applications in Java, most clients obtain the best results by maximizing the amount of code they put in the Caché Application Server's Scripting Languages (Basic and Caché ObjectScript) and limiting Java to the user interface portion of the application.
The Caché Advantage
Java Flexibility: Java developers have choices when it comes to accessing Caché objects – they can use SQL and JDBC or more naturally project objects as Java classes or Enterprise Java Beans.
High Performance: All Java applications, regardless of how they are connected to Caché, benefit from Caché’s superior performance and scalability.
Caché Rapid J2EE Development: Caché classes can easily be projected as EJBs, giving J2EE developers a simple way to connect to Caché’s post-relational database. When a Caché class is projected using bean-managed persistence, Caché automatically generates the method used by the EJB to access the Caché database. Because developers no longer have to hand code persistence methods, applications can be completed more rapidly.
C++
Every Caché class can be projected as a C++ class, with methods corresponding to each property and method of the Caché class. To C++ programs, these classes look just like any other local C++ classes, and Caché automatically handles all communications between the client and server. Properties of the class are cached on the client, and C++ method calls invoke corresponding server side methods – including methods to store an object in the database and later retrieve it.
Caché and .NET
Caché and .NETBecause of its open and flexible data access, Caché works seamlessly with .NET. There are many ways of connecting the two, including objects, SQL, XML, and SOAP. Developers can create applications with the technologies they prefer – all of them will benefit from Caché's superior performance and scalability.
COM & ADO
COM and ADO are both considered “older” Microsoft technologies, included in .NET to encourage migration to the newer framework. Caché interacts with COM through its object data access – exposing Caché classes as COM classes. In contrast, ADO provides object “wrappers” for relational data, and interacts with Caché via Caché’s relational data access.
ADO.NET
ADO.NET is a new incarnation of ADO, optimized for use in the .NET framework. It is intended to make .NET applications “database independent”, and generally uses SQL to communicate with databases. Through its relational data access, Caché provides native support for
ADO.NET. It also supports Microsoft’s ODBC.NET and the read-only SOAP connectivity that is built into ADO.NET.
Web Services
There are two ways of using Web services in .NET. One is to send XML documents over HTTP. The other is to use the SOAP protocol to simplify the exchange of XML documents. In both cases, because Caché can expose data as either XML or SOAP documents, it works seamlessly with .NET Web services.
Caché Managed Objects
Caché can automatically generate .NET assemblies (or Visual Basic or C# source code) from Caché object classes. A plug-in for Visual Studio lets developers who prefer that environment to easily access and use Caché’s managed .NET projections.
The Caché Advantage
Speedy Data Serving: Web applications that use Caché as a data server benefit from the high performance and massive scalability provided by Caché’s multidimensional data engine.
Productivity: Developers will be more productive when they work with their favorite tools in environments that are familiar to them. Providing both SQL and object data access, Caché supports a wide variety of common development technologies and tools.
Compatibility with .NET: Caché fits easily into .NET architectures, giving developers the option of connecting to clients via Web services, XML, COM, or ODBC.
Chapter 3
Caché and XML
Just as HTML is an Internet-compatible mark-up language for displaying data, XML is a mark-up language for exchanging data between applications. Using XML, disparate applications (within a company, or at different enterprises) can share data over a network. The structure of XML data is hierarchical and multidimensional, making it a natural match for Caché's multidimensional data engine.
Caché provides an easy-to-use, bi-directional interface to XML that eliminates the need for developers to manually create a "mapping layer" of processing between XML data and the database.
Exporting XML
All that is required to make a Caché class compatible with XML is to have it inherit from the %XMLAdaptor class that is included in Caché. This provides all the methods needed to:
* Create either a DTD (Document Type Definition) or an XML Schema for the class. DTD's and Schemas are documents that define the structure of XML data. Caché will automatically generate DTD's and XML Schemas, but developers who wish to customize the XML formatting of a class may do so.
* Automatically format data (instances of the class) as XML, according to the defined DTD or Schema.
Importing XML
Caché comes with other classes that provide methods allowing developers to:
* Import XML Schemas and automatically create corresponding Caché classes.
* Import the data in XML documents as instances of Caché classes, via a simple API.
* Parse and validate XML documents via a built-in XML (SAX) parser.
Caché and Web Services
Web Services enable the sharing of application functionality over the Internet as well as within an organization or system. Web Services have an interface described in WSDL (Web Service Definition Language), and they return an XML document formatted according to the SOAP protocol.
Caché enables any class method, any SQL stored procedure, and any query to be automatically exposed as a Web service. Caché generates the WSDL descriptor for the service and, when the service is invoked, sends the response, appropriately formatted as SOAP/XML. Caché also facilitates rapid development by automatically generating a Web page to test the service, without the need to construct a client application.
The Caché Advantage
Easy Connectivity to XML: Caché takes advantage of its capability for multiple inheritance to provide any Caché class a bi-directional interface to XML. The result: Caché classes can easily and quickly be turned into XML documents and schemas. Similarly, XML schemas and documents can be turned into Caché class definitions and objects.
Rapid Development of Faster XML Applications: Because Caché’s native multidimensional data structures are a good match to XML documents, there is no need for developers to manually code a “map” that translates between XML and the Caché database. Therefore, XML-enabled applications are quicker to develop. And with less processing overhead, they run faster, too.
Instant Web Services: Any Caché method can be published as a Web service with just a few clicks of a mouse. Caché automatically generates the WSDL descriptor and the SOAP response when the service is invoked. Existing Caché applications can easily be Web service enabled, and new Web service applications can be built extremely quickly.
Integrating Caché with Other Technologies and Popular Tools
Caché can be used immediately with a wide variety of popular development tools and frameworks – virtually any that supports COM or .NET components, Java classes or EJB, SQL access via ODBC or JDBC, or development with XML and Web services. As a result, Caché delivers unparalleled freedom of choice, enabling each developer to choose the most suitable development approach for each project.
Caché and Rational Rose
Caché RoseLink is an InterSystems provided add-in to the popular Rational Rose object modeling tool. It provides a full round-trip engineering interface between Caché and Rational Rose, enabling schemas to be designed in Rational Rose and exported to Caché for implementation. Similarly, developers can import schemas from Caché into Rational Rose for further design or documentation.
Caché and Dreamweaver
Caché comes with an add-in to the Dreamweaver Web page design environment that gives Dreamweaver users an easy way of creating Caché Server Pages, and using Caché Application Tags.
The Caché Advantage
Freedom of Choice: Caché allows programmers to use any development environment they choose for user interface and business logic programming. Through the use of projections, object servers, and gateways, Caché-based applications can interact with other programs using COM, .NET, C++, Java, EJB, and SQL.
Links to Popular Tools: Caché comes with special features that provide highly productive links to object modeling tools like Rational Rose and Web design tools like Dreamweaver. Developers who use these tools can very quickly create applications that tap into the power of Caché's post-relational database.
Caché Studio
Caché Studio is an easy-to-use and powerful integrated development environment that enables the rapid creation, debugging, and testing of Caché applications. Notable features include:
* Editors: Programmers can write Caché ObjectScript, Caché Basic, MultiValue Basic, and Java code as well as class definition files and Web pages. Clicking on a property, method, etc. in the editor displays the characteristics of that property, etc., and allows them to be edited in that display window.
* Wizards: With just a few clicks developers can define or edit classes, Caché Server Pages, and SQL queries, publish Caché methods as Web services, and project Caché classes as Java, COM, or C++ classes, Enterprise Java Beans, and XML documents.
* Automatic Syntax Checking: Improper syntax is automatically flagged for Caché ObjectScript, Caché Basic, MultiValue Basic, HTML, and Java.
* “View Web Page” Command: Developers can test Web pages directly from within the development environment.
* Visual Debugger: Compile and debug code with a visual debugger, which can also attach to and debug an existing Caché process.
* Context Sensitive Help: Caché Studio is fully integrated with its on-line documentation.
* “Import” and “Export”: Automatically import Caché class definitions from relational DDL schema definitions, or from object modeling tools. Caché class definitions can also be imported from MultiValue dictionaries. An Export tool allows creation of definition files to send to other computers.
The Caché Advantage
Rapid Application Development: The Caché Studio is a highly productive tool for creating, debugging, and testing Caché applications. Through the extensive use of wizards, Caché Studio eliminates much of the “drudge work” associated with application development.
Chapter Four:
Building Fast Web Apps Fast With Caché Server Pages
“Building fast Web apps fast” uses the word fast two times. That’s because it is possible to build sophisticated database-oriented Web applications with CSP more rapidly than with traditional approaches, and also because the built-in Caché database is the world’s fastest, capable of running systems with tens of thousands of simultaneous users.
There are many ways to write Web applications with Caché – including all of the traditional ways that use SQL to access the database. In this chapter we’re going to discuss another, more direct approach called Caché Server Pages (CSP).
CSP is a technology that is provided as part of the Caché Application Server. It is the fastest way for Caché applications to interact with the Web, providing:
* An advanced object-oriented development approach.
* Ultra-high performance and scalability at run-time.
CSP supports HTML, XML, and other Web-oriented mark-up languages.
CSP is not a Web design tool, although it can be used with them. While Web design tools often concentrate solely on the production of static HTML, CSP goes beyond the appearance of pages to aid in the development of application logic. It also provides the run-time environment that enables rapid execution of code within the Caché Application Server.
CSP supports a strong procedural programming environment, so applications can be written with a level of sophistication and exactness that exceeds that possible with pure application generation technologies. It also supports rapid development through its class architecture, which produces “building blocks” of code that can be combined, and through the use of wizards, which can quickly produce simple versions of customizable code. The result is the ability to quickly develop very sophisticated Web applications.
The Caché Advantage
Rapid Web Development: Rapid Web Development: Object-oriented procedural programming plus Caché Wizards result in rapid development of sophisticated browser-based database applications.
Some of the characteristics of Caché Server Pages are:
* Dynamic Server Pages – Because pages are created dynamically on the application server by application code, rather than having a Web server simply return static HTML, applications can respond rapidly to a variety of different requests and tailor the resulting pages that get sent back to the browser.
* Session Model – All of the processing related to pages from a single browser are considered part of a session – from the first browser request until either the application is completed or a programmable timeout occurs.
* Server State Preservation – Within a session, application data on the server – and even the entire application context – can be automatically retained across browser requests, making it much easier to develop and run complex applications.
* Object Architecture – Because every page corresponds to a class, code and other characteristics common to many pages they can be easily incorporated through inheritance. Data is also typically referenced through objects with all of the benefits of object-oriented programming.
* XML – Caché fully embraces XML, both as a powerful alternative to HTML for building Web pages and as a universal format for moving data between applications and systems.
* Caché Application Tags for Automatic Generation of Server Application Code – These extended HTML tags are as easy to use as traditional HTML tags. When added to an HTML document, they generate sophisticated application code providing a variety of functionality, such as opening objects, running queries, and controlling program flow. These tags are extensible – developers can create their own to suit their specific needs.
* Integration with Popular Web Design Tools – CSP works with a variety of tools that make it easy to visually lay out a page. With Dreamweaver, CSP goes a step farther with the ability to add Caché Application Tags through simple point-and-click interaction. CSP also includes a Wizard that makes it easy to create forms that display or edit data in a Caché database.
* Server Methods Callable from the Browser – To facilitate development of more dynamic interactive applications, CSP makes it easy to invoke server-side methods. When an event occurs in the browser – typically because the user took some action – application code on the server can be invoked and a response to the event generated, all without the overhead of transmitting and displaying a whole new page.
* Encryption – Caché automatically encrypts data in the URL, to help authenticate requests and prevent tampering. The encryption key is kept only on the server, and it is only good for the life of the single session.
That’s a lot of technology – but it does not have to be hard to use. We’ve focused on making CSP simple to use, with most of these capabilities working automatically for you. Our philosophy is power through simplicity – the complexity should be in our implementation, not in your programming.
The Caché Server Page Model
Traditional Web Technologies
With traditional Web technology, a request is sent to the Web server, and the Web server retrieves a sequential file of HTML that it sends back to the browser. When applications involve variable data, development gets more complicated, with programmers typically using CGI (with languages such as Perl or tcl) on the Web server and sending SQL queries and stored procedure requests to the database. As a programming environment, this leaves much to be desired, and execution – particularly with a large number of users – can be quite inefficient as the Web server gets heavily overloaded.
With CGI, each browser request typically creates a new process. To avoid this overhead, programmers sometimes link application code directly to the Web server, with the unfortunate side-effect that an error in such code can crash the entire Web server.
Dynamic Server Pages
CSP uses a different programming and execution approach: Dynamic Server Page Technology. Content (HTML, XML, style sheets, images, and other types) is generated programmatically at run time on the Caché Application Server, rather than coming from sequential files, allowing much greater flexibility in responding to page requests.
Most of the application code executes on the Caché Application Server, which may or may not be on the same computer as the Web server. Some code – typically JavaScript or Java – may run on the browser, usually to support operations such as data validation, reformatting, or invoking server-side code.
With this approach, processes don’t have to be created for each browser request (as they do with the traditional CGI approach), boosting performance. And since the application code isn’t linked to the Web server, an application error cannot crash the Web server.
Sessions – The Processing Model
All of the processing related to pages from a single browser are considered part of a session – from the first browser request until either the application is completed or a programmable timeout occurs. When the Web server receives a page request (URL) with the file extension “.csp”, that request is sent (by a thin layer of Caché code attached to the Web server) to the appropriate Caché Application Server, which may be on a different computer.
When the Caché Application Server receives the request, it determines whether a session is already in progress for that browser. If not, one is started automatically. Caché then executes application code associated with that particular page – performing the actions requested by the user and programmatically creating HTML, XML, image, or other content that is sent back to the browser.
A session ends when a property is set in the Session object terminating the session. Applications that run stateless may elect to terminate the session on each page.
State Preservation
One of the challenges facing developers is the inherently stateless nature of the Web – there’s usually no simple way to retain information on the server from one request to the next. Applications typically send all of the state information they need to retain out to the browser in URLs or hidden form fields. That’s not an effective technique for more complex applications, which may resort to saving data temporarily in files or databases. Unfortunately this imposes significant overhead on the server, and it makes programming considerably more difficult.
Caché’s Session model enables Caché to automatically and efficiently preserve data between calls from a browser. CSP provides a Session object that contains general session information plus properties that enable the programmer to control various session characteristics. The application can store its own data in the Session object, which is automatically retained from one request to the next.
The application determines how much state to preserve by setting the Preserve property of the Session object to 0 or 1. (The default is 0, and it can be dynamically modified at run time.)
* 0 – Data stored in the Session object is retained. (Data is simply set into a multidimensional property that accepts data of any type and allows any number of subscripts – including string valued subscripts – without any declarations.)
* 1 – Caché dedicates a process to the session so that all of the state of the process is retained, including all variables (not just those in the Session object), I/O devices, and locks.
A setting of 0 allows a logical partitioning of all preserved data and permits multiple sessions to share a single process, but it preserves less state. A setting of 1 is easier for the programmer and provides a wider range of capabilities, at a cost of increased server resources.
The Request Object
CSP automatically provides several objects in addition to the Session object to help the programmer process the page. One of these is the Request object. When a page is received, the URL is decoded and its contents are placed into the request object. The request object contains all name/value pairs and any form data along with other useful information. For example, the value of the name “FilmID” could be obtained by the code:
%request.Data(”FilmID”,1)
// the 1 indicates we want the
// 1st value for this name
// in case multiple values are
// present for this name
The Caché Advantage
By automatically preserving state information on the server, there’s less network traffic and less overhead on the server, as the application doesn’t have to keep filing and accessing data on every page request. And programming the application is simpler.
The use of Dynamic Server Pages and the Caché Application Server results in greater flexibility to respond to requests, faster execution without the risk of application errors bringing down the Web server, and a richer programming environment.
Class Architecture of Web Pages
For each Web page, there is a corresponding page class that contains methods (code) to generate the page contents. When a request is received, its URL is used to identify the corresponding page class, and the “Page()” method of that class is called. Usually page classes are derived from a standard Web page class “%CSP.Page” that provides every page with various built-in capabilities, such as the generation of headers and encryption. Those standard capabilities can be overridden through a variety of means – deriving from another superclass, using multiple inheritance, or simply overriding specific methods.
This class architecture makes it easy to change behavior for an entire application and to enforce a common style. It also brings all of the other programming advantages of object programming to Web development.
The page class contains code to perform the requested action and generate and send a response to the browser, but not all of the application code that is executed is in that page class. In fact, most of the executed code is typically in methods of various database classes and perhaps additional business logic classes. Thus the development process consists of developing both page classes and database classes (plus perhaps additional business logic classes).
In general, we recommend that page classes contain only user interface logic. Business logic and database logic should be put into different classes, so that there is a clean separation of user interface code from the business and database logic, and it is easier to add additional user interfaces later.
Multiple Development Strategies
DevelopmentA page class is created for each Web page and contains the code to be executed for that page. There are two ways to build page classes, and most applications use both of them:
* CSP File – An HTML file with embedded Caché Application Tags is written using a simple text editor or Web design tool. That sequential file (a “CSP File”) is not sent directly to the browser – it is compiled to generate a page class.
* Direct Programming – Programmers write the entire page class by coding the appropriate methods.
Simple pages are often quicker to develop with CSP files and wizards, but it may be easier to directly program more complex pages.
CSP Files
CSP Files are sequential HTML files with embedded Caché Application Tags that are compiled into page classes – the same sort of page classes that a programmer might write directly. Those page classes are then compiled to generate code that runs on the Caché Application Server in response to browser requests.
Caché Studio includes a Form Wizard that automatically generates a CSP file to edit or view a database class. The user simply clicks on the database class of interest and then clicks on the set of properties to be displayed. The Caché wizard does the rest – adding HTML and Caché Application Tags to the page. Since the wizard outputs HTML, if the result is not exactly what you want, it is easy to edit it.
The CSP File approach is powerful because:
* Web artists can design the visual layout while programmers concentrate on the code.
* Much of the user interface can be programmed non-procedurally in a visual environment and kept isolated from the business and database logic.
* It is often easier to customize an application for a particular user by allowing non-programmers to modify the visual presentation and add simple capabilities.
Since the visual specifications of the application are kept separate from most of the programming logic, it is relatively easy to change the appearance without reprogramming. Simply edit the HTML or XML file and recompile the page.
Although a complete simple application can be created this way, more commonly a programmer supplies additional code. This additional code is provided though application tags that either include the procedural code or invoke code in other classes. However, complex pages with a lot of procedural code are often easier to write using the direct programming approach rather than a CSP file.
Caché also includes an add-in for Dreamweaver, the popular Web page design tool. It provides point-and-click support for adding Caché Application Tags as well as a Caché Form Wizard that automatically generates the code needed to view or edit a database object.
Caché Application Tags
Caché Application Tags can be added to CSP Files. They are used just like standard HTML tags, but they are really instructions to the Caché Web Compiler to generate application code that provides a variety of functionality – such as accessing database objects, running queries, program flow control, and executing code on the Caché Application Server. Caché Application Tags are extensible – developers can create their own to suit their specific needs.
Caché Application Tags are not embedded in HTML that is sent to a browser – they are only in the CSP file read by the Caché Web Compiler. That compiler automatically transforms them into standard HTML, which can be processed by any browser.
Hyper-events
CSP hyper-events allow events occurring on a browser (such as mouse clicks, field value changes, or timeouts) to invoke server-side methods and to update the current page without repainting it. After taking the appropriate action, that server method can return code – typically JavaScript – for execution by the browser. Using hyper-events, Web applications can become more interactive and responsive.
Within a CSP page, a server-side method is invoked simply with the syntax “#server(...)#”. For example, suppose that when the user clicks on a shopping cart image we want to call a server method called AddToCart(). Then the HTML definition for the image might include:
onClick=”#server(..AddToCart())#”
The Web compiler will replace this syntax with JavaScript code that, when run on the browser, will invoke the Caché server method.
Hyper-events
HTML or XML?
HTML is the traditional “language” of the Web, and it is one of the most widely known programming languages in the world. This makes HTML a natural choice for many. An increasingly popular alternate to HTML is using XML. Caché is particularly well suited to XML since Caché can automatically produce XML documents. XML supports an object structure and maps well to an object representation of data.
With XML, instead of sending a complete description of the page to the browser, just the data is sent to the browser in a structured form. The browser is also instructed to use a particular “Style Sheet” for that page that contains a description of what to do with that data. Once the browser has that style sheet, it can remember it and use it again later if the page (or another page with the same style sheet) uses it.
XML is particularly effective for transaction-based applications that repetitively use the same pages with different data. Only the data needs to be transmitted to the browser, not an entire HTML description. Another attraction of XML is that it provides a clean separation between the data contents (encoded in XML) and the behavior to display and edit it (encoded in the Style Sheets).
CSP works the same way with XML as it does with HTML. Instead of the programmer supplying HTML in the Page() method, XML is provided. That XML is easily derived from the database classes by running the XML Wizard in Studio – simply specify the names of the properties to be included and the wizard generates a method to provide the XML document.
With XML the programmer also has to provide a Style Sheet. That could either be provided as a separate page class whose Page() method simply writes the Style Sheet to the browser, or, more commonly, it is a simple sequential file that is transmitted to the browser by the Web server like any other file.
Chapter Five:
Caché’s Security Model
security modelCaché has a modern security model, designed to support application development in three ways:
1. By securing the Caché environment itself.
2. By making it easy for developers to build security features into their applications.
3. By ensuring that Caché works effectively with – and does not compromise – the security technologies of the operating environment.
Caché provides these security capabilities while minimizing the burden on application performance.
* Privileges: Caché’s security features work by controlling access to Caché resources: data, programs, services, utilities, etc. Privileges (such as READ, WRITE, or DELETE privileges) can be assigned in several ways:
* Users: Privileges (permission to use various resources) are assigned to users or applications. A “user” is not necessarily a human being. It could, for example, be a measurement device generating data to be stored in Caché, an application, or another Caché system.
* Roles: Privileges can be grouped into roles, and roles assigned to users. This makes it easier to manage privileges.
* Applications: If permission to use certain resources is assigned to applications, then it is not necessary to grant those privileges to individual users. Instead, users are allowed to run the appropriate applications. In addition to being more secure (users cannot directly access Caché resources), this makes it easier to manage privileges.
The assignation and management of privileges is performed through the Caché Management Portal.
* Authentication: Caché supports various levels of authentication, ranging from none, to the use of passwords, to the use of the Kerberos protocol to authenticate the identity of users. Kerberos provides very strong authentication, and has the advantages of being fast, scalable, and easy to use. With Kerberos, passwords are never transmitted over the network, which provides an extra measure of security.
Caché supports the implementation of a single sign-on.
* Database Encryption: Caché enables database encryption (the encryption of data-at-rest) with minimal effect on application performance. Developers can mark which databases, or even which blocks of data within a database, they wish to encrypt. In Caché, databases are encrypted at the data level, so all data and indexes are secured.
By default, Caché encrypts data with an implementation of the Advanced Encryption Standard (AES), a symmetric algorithm that supports keys of 128, 192, or 256 bits. Encryption keys are stored in a protected memory location. Caché provides full capabilities for key management.
* Auditing: Many applications, especially those that must comply with government regulations like HIPPA or Sarbanes-Oxley, need to provide some sort of secure auditing. In Caché, all system and application events are recorded in an append-only log, which is compatible with any query or reporting tool that uses SQL.