Release 9.0.1.1.0
Part Number A90093-02
 Contents |
 Index |
| Oracle Internet File System Developer Reference Release 9.0.1.1.0 Part Number A90093-02 |
|
This chapter offers an introduction to Oracle 9iFS, briefly outlining system elements, describing key database features, and identifying points of extensibility. It is meant to give developers an understanding of the architecture of Oracle 9iFS so that they can plan basic customization of the out-of-the-box product and add functionality by modifying existing elements or creating new elements. Topics include:
The fundamental task performed by Oracle Internet File System (Oracle 9iFS) is to manage objects. Objects take many forms:
The term manage encompasses activities such as adding, changing, deleting, versioning, and organizing files.
Out of the box, Oracle 9iFS provides users with a number of graphical interfaces to manipulate objects. The end user can make use of the content management, search, versioning, and security features of Oracle 9iFS without knowing about the underlying database schema. Users connect to Oracle 9iFS as they would any file server, and manipulate the files stored there as they would on any shared network storage device.
Oracle 9iFS is a pure Java application that interacts with the Oracle9i database using JDBC classes. Files and folders are presented using transient instances of Java class objects, then stored persistently as records in the database. The complexity of storing and retrieving the files is handled transparently and efficiently by the Oracle 9iFS API.
Oracle 9iFS supports many features of the emerging XML standard. XML files can be used not only to store and transfer data, but also as a mechanism for configuring and customizing Oracle 9iFS to meet your specific data storage needs.
While the Java representations of Oracle 9iFS objects can be manipulated at the presentation layer, the underlying records are stored as relational records in the Oracle9i database. This brings increased power and flexibility not found in standard file systems.
The Oracle 9iFS security model features configurable access control on a per-object basis. Access Control Lists (ACLs) can specify, for each document, which users or groups have discover (the ability to locate the file by either searching or navigating through the folder hierarchy), read, write, or delete access to each file.
Oracle 9iFS enables users to search for documents based on their attributes (such as name, description, modification date, or custom attributes defined by a developer). Oracle 9iFS also exposes the indexing capabilities of the Oracle Text, which allows searches of document content (including the text elements of multimedia files), thousands of times faster than the full content search features of standard file systems.
Oracle 9iFS has content management and collaboration features superior to any standard file system. Files can be versioned: each time a user checks out, modifies, and checks in the document, a new version is created. Users can go back to any iteration of the document and access the earlier content.
Files can be accessed through a number of protocols, making them available to users wherever they are in the world. Centralized storage simplifies the administrative tasks involved with maintaining the data, such as security and backup.
The same file can appear in multiple files. Users can place the files they use into a directory structure most convenient for their personal use. Only one copy of the file is stored in Oracle 9iFS: when it is updated in one location, it is updated in all locations. If the file is deleted from one directory, it will still appear in all other directories. Only when the file is deleted from all its parent folders is the file removed from the Oracle 9iFS repository.
This section provides a high-level description of the components of Oracle 9iFS (see Figure 2-1).
Text description of the illustration 1arch.gif
The Oracle 9iFS protocol servers are written using the Oracle 9iFS Java API, and allow clients to access objects in the repository using HTTP, Windows Explorer, NFS, FTP, Macintosh DAVE, and e-mail clients. Files and folders are presented to the end user in the appropriate way for each of the protocols.
Functionally, the repository is a single mechanism that performs the task of transforming the contents of database rows and tables into objects such as files, folders, users, and groups. From the developer's point of view, the repository actually consists of two parts: the Java API used to access the database, and the IFSSYS schema within an instance of an Oracle9i database.
The repository Java classes perform the following tasks:
A schema is the collection of tables and fields that belong to a specific user. The Oracle 9iFS schema, which is named IFSSYS, contains all objects used by Oracle 9iFS, with the exception of user credentials, stored in IFSSYS$CM.
Developing against Oracle 9iFS does not require dealing directly with the database on this level. The IFSSYS schema stores all the persistent objects managed by Oracle 9iFS.
For every Oracle 9iFS ClassObject, there is a table named ODM_<DatabaseObjectName> where <DatabaseObjectName> is the value of the DatabaseObjectName attribute for the ClassObject. In most cases, the DatabaseObjectName is the same as the name of the ClassObject, but if the name is more than 30 characters it is abbreviated (this is a limit of the Oracle9i database).
The first column in each table is the unique ID number of the row. This value cannot be null. One column stores each attribute. Attributes can be of any datatype supported by the database. In some cases, the value needs to be converted from a database data type to a data type compatible with the Java programming language. For this reason, attribute values are passed from Java to the database using AttributeValue objects. These objects are overloaded to accept any data type, and perform the conversion for insertion to or extraction from the database.
Oracle 9iFS supports storing any data type as an array of values of the same type. In those instances, Oracle 9iFS stores the number of items in the array as the value in the object table. The array values themselves are stored in a separate table holding array values of that type. For example, if the custom array attribute HOLIDAYS were added to a subclass of the Document class, the column HOLIDAYS would store the number of date values for the specific record. The values themselves would be stored separately in the ODM_AVDATEARRAY table, linked to the parent record by its unique Document ID.
There are three types of persistent object stored in Oracle 9iFS. Every other object is a subclass of these three types. Table 2-1 describes the three types of persistent object stored in Oracle 9iFS.
Table 2-1 Persistent Object Types
All objects in Oracle 9iFS are subclasses of the three main types. For example, the Document subclass of PublicObject inherits all of the attributes of PublicObject, and adds two more attributes of its own. If you create a subclass of the Document class, the resulting class inherits all of the attributes of both PublicObject and Document. This enables you to quickly construct a sophisticated document storage model, adding only the specific attributes and behavior your application requires.
When files are placed into Oracle 9iFS from any of the protocols (HTTP or FTP, for example), the file's attributes are stored separately from its contents. If the content of the document is to be indexed using Oracle Text, the content is stored in the table ODMM_CONTENTSTORE. If it is not indexed, it is stored in ODMM_NONINDEXEDSTORE.
For each ODM_ table, a number of views are created. The most useful is ODMV_<DatabaseObjectName>, which displays a join of the most useful columns from its parent tables. For example, the view ODMV_PROPERTYBUNDLE contains columns from three tables: ODM_PROPERTYBUNDLE, ODM_APPLICATIONOBJECT, and ODM_PUBLICOBJECT.
You can use SQL*Plus to explore the IFSSYS schema, and look at the results of changes you make via the Java API. However, it cannot be stated emphatically enough that you should never directly change values in the Oracle 9iFS repository using SQL commands. Doing so will corrupt the schema, causing an unpredictable amount of data loss.
The Oracle 9iFS Java API makes advanced file system and content management features readily available to developers. Some examples of development projects would include:
Virtually every advanced feature of Oracle 9iFS is exposed for customization. The following entry points are available:
The most straightforward way to modify the behavior of Oracle 9iFS is to extend an existing class to add custom attributes. You can extend the Document or Folder class, or your own custom subclasses. The subclass you create inherits all of the attributes of its parents, up through the PublicObject class. You can subclass using the Java API, XML configuration files, or the Oracle 9iFS Manager tool.
In the Java API, between every out-of-the-box class and its parent is a tie class. Tie classes are empty classes that inherit the behavior of the parent and pass the behavior to its subclass. For example, between the PublicObject class and the Document class is a class named TieDocument. TieDocument has no methods of its own.
The purpose of tie classes is to enable you to alter the behavior of out-of-the-box classes without changing the classes themselves. In TieDocument, for example, you can add behaviors that will be inherited by the Document class and all of its subclasses.
A parser is a program that is called when a document is inserted or updated in Oracle 9iFS. The parser extracts structured data from the file and stores it as an attribute of the file. A custom parser can be written for any kind of document if it has a predictable structure. The attribute could be identified as a name/value pair, or by HTML or XML tags. The attribute could be taken from a file that always puts a particular value in a predictable position in the file (Start, end or n characters from the top of the file). However the information is identified, the parser class intercepts the InputStream and extracts the data, performs any operations on the data that the developer chooses, then returns control to the Oracle 9iFS repository to complete the job of storing the file. There is also a ParserCallback mechanism that will call a program identified by the developer to perform post-processing, such as storing a copy of the file in a particular folder.
A renderer takes a Document object from the Oracle 9iFS repository and delivers it to the client in whatever form the developer chooses. It is not quite accurate to say that a renderer is the opposite of a parser. While it does reverse the process of a parser, taking an item from the repository and reconstructing it as a file, it does not necessarily have to restore the file in its original format. For example, you could have several renderers defined for a subclass of Document, and invoke a specific renderer based on the type of client that requests it.
Servers can be broken into two categories: protocol servers and agents. Protocol servers host the connections for the different protocols used to connect to Oracle 9iFS. Agents are programs that are triggered by events, either changes to the 9iFS repository or by the passage of a predefined length of time. You can define an agent that performs a certain task or set of tasks when an event occurs in the Oracle 9iFS repository.
Special methods have been provided in some of the classes that run on the server (rather than the client) with the sole purpose of providing a convenient place to override the default behavior of Oracle 9iFS. Out of the box, these methods are empty. You can add your own processing at these points without the risk of overriding the required default behaviors needed to maintain the integrity of the information stored in the Oracle 9iFS repository.
Most classes include the methods extendedPreInsert(), extendedPreUpdate(), and extendedPreFree(). These methods are called just prior to the creation, update, or deletion, respectively, of an Oracle 9iFS object.
The S_PublicObject class also includes the overrides extendedPostInsert(), extendedPostUpdate(), and extendedPostFree(), which allow you to add behaviors to be performed immediately after the corresponding action takes place.
The S_Folder class has its own special overrides: extendedPreAddItem(), extendedPostAddItem(), extendedPreRemoveItem(), extendedPostRemoveItem().
A servlet is a Java program that runs as a module inside an HTTP server to produce dynamic content. Servlets are written using the Sun Java Servlet API, but can run on any platform and on any web server. Essentially, servlets are Java programs that produce HTML code in response to a client request. Servlets use a high-performance, single process, multi-threaded architecture that minimizes the overhead required to serve each request.
Oracle 9iFS uses a custom servlet based on the HttpServlet class to provide HTTP protocol access to the repository, as well as some support for Distributed Authoring and Versioning (DAV). This servlet works with the Oracle HTTP Server, powered by Apache.
Java Server Pages (JSPs) provide a different approach to creating servlets. Rather than a Java program with embedded HTML code, a JSP is an HTML page with embedded Java code. JSPs can separate the task of creating the user interface from the task of developing the business logic that provides the information. Most of the time, JSPs will have a JavaBean on the server that provides accessor and mutator methods (getters and setters) for the data elements of the page. For more information on servlets and JSPs, see Chapter 12, "Web Interface Customization".
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|
