|
|  | nextpage client AgentThe NextPage Client Agent runs on each user’s computer. It contains services for tracking, classification and policy enforcement. Together, these components perform the following functions with minimal user intervention:  | Stamp files with NextPage metadata (“DNA”) when appropriate | | | Track files in email and on users’ hard drives, whether or not they are stamped | | | Confirm decisions with the Enterprise Service when they require global consistency | | | Populate certain reports that appear on end users' computers | | | Enable automatic policy to be applied |
The tracking service can track any type of file by recognizing its hash; this basic level of tracking works even if a file is renamed, moved, copied, sent or even edited. For some file types - Microsoft® Word, PowerPoint and Excel (binary or OpenXML) - it provides additional capabilities such as the ability to track a file even when it has been edited on a machine that does not have NextPage installed. To support those additional capabilities, and to track attachments in Microsoft Outlook® and Lotus Notes, the tracking service also integrates with selected applications. From an architectural standpoint, the integration for each supported document application has been kept as simple as possible. NextPage inserts user interface elements such as a NextPage menu. It detects user operations such as file opens, saves and closes. The application then acts as the Client Agents’s interface to the application’s particular method for storing NextPage metadata. The application integrations are add-ins for Microsoft Word, PowerPoint and Excel. They are written in C# and communicate with their respective applications via published COM interfaces. Microsoft applications store key-value pairs in OLE structured storage and expose them via published interfaces as standard and custom properties. The NextPage add-ins all use this facility to store metadata. The NextPage Client Agent's file system integration tracks files in response to certain trigger events: | On a local file system, all file writes, deletes, moves and renames generate trigger events with a sub-second response time. | | | On a removable or network-mounted drive, file opens and saves generate trigger events. As on the local file system, tracking continues uninterrupted through renames and file moves. The only difference on a network or shared drive is the timing of the triggers, which do not occur immediately as files appear and disappear. |
The role of the Classification Service is similar to that of the file system integration. It detects each time a document is created, edited, moved, renamed, copied or sent, and determines a classification. The classification can be computed from automatic rules based on the file's attributes, such as its location, extension or other properties. A plug-in architecture allows custom rules to be implemented easily. Optionally, in the event that a file's classification is not determined by any automatic rule, the classification can be gathered from user input via a prompt that occurs on the first save of a document. Some customers opt for NextPage to be essentially invisible to the end user by arranging for this classification prompt never to appear. The NextPage Policy Service enables the client to execute policies with or without manual intervention. A policy is created and defined in the Enterprise Service, either interactively (via the admin console) or automatically (via an XML feed). The Policy Service on the client reads the variables and policy parameters and enforces the appropriate actions on the users' desktop. NextPage Enterprise ServiceThe NextPage Enterprise Service is a collection of hosted capabilities. Interactions between the Client Agent and the Enterprise Service are fully asynchronous. This means that a client can run indefinitely while offline or with a bad network connection. Client operations execute without waiting for the Enterprise Service to respond. Non-trivial messages that pass between the Client Agent and the Enterprise Service travel securely via HTTPS/443. For compatibility with private address spaces, the Enterprise Service never initiates contact with the Client Agent. Instead, the Client Agent polls the Enterprise Service using lightweight queries via HTTP/80. Unlike a centralized document-management or ECM system, the Enterprise Service does not store documents. Instead, they stay in place; the Enterprise Service needs only the genetic information maintained by the NextPage Digital Thread™ technology. This genetic information is completely anonymous. It is composed of identifiers that, like Swiss bank-account numbers, are completely opaque—they cannot be traced back to files users do not have access to, or even to specific file names. To unlock their meaning, users must have physical possession of the files to which they refer. Because the NextPage service does not rely on a centralized repository, there are no files to protect from unauthorized viewing, modification or deletion. Users and system administrators have their usual control over access to files, and they have complete freedom to take advantage of any existing access security capabilities. For example, users can store files on personal computers and not allow access to anyone else. They can also post files on network repositories and use built-in access controls to assign and control permissions. With the information described above, the Enterprise Service can generate statistical reports that involve file counts. Optionally, a customer can elect that additional information be transmitted to the Enterprise Service. This information includes attributes such as filenames, sizes, dates and other properties. This is necessary if any required use cases involve generating reports that involve listing files and their attributes one by one, either at the Enterprise Service or at an end user's machine. Designed for Complete CoverageA traditional centralized document repository has two inherent, fundamental limitations related to coverage. First, it has no awareness of files outside itself. Second, unless users are completely consistent about initiating documents within the repository instead of on their own hard drives, it has no control over early stages of the document lifecycle. The NextPage system architecture addresses both of these limitations. It does not replace a centralized repository; rather, it forms a comprehensive umbrella that places centralized repositories, end-user machines, and other locations under a single locus of control. | |
|
|
