MXPA06001986A

MXPA06001986A - Sistemas y metodos para modelar datos en una plataforma de almacenamiento basada en elementos.

Info

Publication number: MXPA06001986A
Application number: MXPA06001986A
Authority: MX
Inventors: Soner F Terek
Original assignee: Microsoft Corp
Priority date: 2003-08-21
Filing date: 2003-08-21
Publication date: 2006-05-17
Also published as: EP1658555A4; BR0318469A; AU2003259959A1; AU2003259959A2; AU2003259959B2; KR20060080921A; JP4394643B2; CN100570549C; JP2007521532A; CN1820245A; KR101024730B1; CA2533088A1; EP1658555A1; CA2533088C; WO2005029313A1

Abstract

Varias modalidades de la presente invencion estan dirigidas a un almacen de datos (302) que comprende articulos, elementos y relaciones; un articulo es una unidad de datos que se puede almacenar en un almacen de datos (302) y ademas comprende dicho elemento y dicha relacion; un elemento es una instancia de un tipo que comprende uno o mas campos; una relacion es un enlace entre al menos dos articulos. El almacen de datos (302) que ademas comprende un esquema nucleo (340) para definir un conjunto de articulos nucleo mediante el cual un sistema de interfases de componentes fisicos de computacion/programas y sistemas de programacion comprende y procesa directamente dicho conjunto de articulos nucleo de una manera predeterminada y predecible; los articulos nucleo se derivan de un articulo base unico, que a su vez es un articulo fundamental en un esquema base.

Description

SISTEMAS Y METODOS PARA MODELAR DATOS EN UNA PLATAFORMA DE ALMACENAMIENTO BASADA EN ELEMENTOS REFERENCIA CRUZADA CON SOLICITUDES RELACIONADAS Esta solicitud está relacionada por la materia objeto a las invenciones que se revelan en las siguientes solicitudes asignadas comúnmente: Número de solicitud de patente en EE.UU. (aún no asignada) (número de caso MSFF-1748), presentada en la misma fecha de manera adjunta, titulada "SISTEMAS Y MÉTODOS PARA REPRESENTAR UNIDADES DE INFORMACIÓN MANEJABLES MEDIANTE UN SISTEMA DE I NTERFASES DE COMPONENTES FÍSICOS DE COMPUTACIÓN/PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN INDEPENDIENTES EN SU REPRESENTACIÓN FÍSICA"; Número de solicitud de patente en EE.UU. (aún no asignada) (número de caso MSFT-1749), presentada en la misma fecha de manera adjunta, titulada "SISTEMAS Y MÉTODOS PARA SEPARAR UNIDADES DE INFORMACIÓN MANEJABLES MEDIANTE UN SISTEMA DE I NTERFASES DE COMPONENTES FÍSICOS DE COMPUTACIÓN/PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN EN SU ORGANIZACIÓN FÍSICA"; Número de solicitud de patente en EE.UU. (aún no asignada) (número de caso MSFT-1750), presentada en la misma fecha de manera adjunta, titulada "SISTEMAS Y MÉTODOS PARA LA IMPLEMENTACIÓN DE UN ESQUEMA BASE PARA ORGANIZAR UNIDADES DE INFORMACIÓN MANEJABLES MEDIANTE UN SISTEMA DE INTERFASES DE COMPONENTES FÍSICOS DE COMPUTACIÓN/PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN"; Número de solicitud de patente en EE.UU (aún no asignada) (número de caso MSFT-1751), presentada en la misma fecha de manera adjunta, titulada "SISTEMAS Y MÉTODOS PARA LA IMPLEMENTACIÓN DE UN ESQUEMA NÚCLEO PARA PROVEER UNA ESTRUCTURA DE NIVEL SUPERIOR PARA ORGANIZAR UNIDADES DE INFORMACIÓN MANEJABLES MEDIANTE UN SISTEMA DE INTERFASES DE COMPONENTES FÍSICOS DE COMPUTACIÓN/PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN"; Número de solicitud de patente en EE.UU. (aún no asignada) (número de caso MSFT- 752), presentada en la misma fecha de manera adjunta, titulada "SISTEMAS Y MÉTODO PARA REPRESENTAR RELACIONES ENTRE UNIDADES DE INFORMACIÓN MANEJABLES MEDIANTE UN SISTEMA DE INTERFASES DE COMPONENTES FÍSICOS DE COMPUTACIÓN/PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN"; Número de solicitud de patente en EE.UU. (aún no asignada) (número de caso MSFT-2733), presentada en la misma fecha de manera adjunta, titulada "SISTEMAS Y MÉTODOS PARA CONECTAR CON UNA I NTERFASE PROGRAMAS DE APLCIACIÓN CON UNA PLATAFORMA DE ALMACENAMIENTO BASADA EN ELEMENTOS"; Número de solicitud de patente en EE.UU. (aún no asignada) (número de caso MSFT-2734), presentada en la misma fecha de manera adjunta, titulada "PLATAFORMA DE ALMACENAMIENTO PARA ORGANIZAR, BUSCAR Y COMARTIR DATOS". Campo de la Invención La presente invención se refiere en general al campo del almacenamiento de información y a su recuperación, y de manera más particular, a una plataforma de almacenamiento activa para organizar, buscar y compartir diferentes tipos de datos en un sistema computarizado. Antecedentes de la Invención La capacidad de disco individual ha aumentado cerca de un setenta por ciento (70%) anualmente durante la década pasada. La ley de Moore predijo de manera precisa los enormes beneficios en la potencia de una unidad de procesamiento central (CPU) que se ha presentado con el paso de los años. Las tecnologías cableadas inalámbricas han proporcionado una conectividad y ancho de banda grandiosas. Se presume que las tendencias actuales continúan, en algunos años la computadora portátil promedio poseerá una capacidad de almacenamiento de cerca de un terabyte (TB) y contendrá millones de archivos y unidades de 500 gigabytes (GB) se convertirán en cosas comunes. Los consumidores usa sus computadoras principalmente para establecer comunicación y para organizar información personal, ya sean datos en un estilo de administración de información personal (PI ) tradicional, o bien medios como música o fotografías digitales. La cantidad del contenido digital y la capacidad de almacenar bytes sin procesar ha aumentado en gran medida, sin embargo, los métodos disponibles para los consumidores para la organización y unificación de sus datos no han seguido este paso. Los trabajadores intelectuales invierten una enorme cantidad de tiempo en la administración de la información y para compartirla, y algunos estudios estiman que los trabajadores intelectuales invierten entre el 15 y el 25% de su tiempo en actividades no productivas relacionadas con la información. Otros estudios estiman que un trabajador intelectual típico invierte cerca de 2.5 horas diarias buscando información. Los desabolladores y los departamentos de tecnología de información (TI) invierten cantidades importantes de tiempo y dinero en la construcción de sus propios almacenes de datos para abstracciones de almacenamiento común y representar cosas como personas, lugares, horarios y eventos. No sólo ocasiona general duplicado, también crea islas de datos comunes sin mecanismos para una búsqueda común o para compartir datos. Tan sólo considere cuántas libretas de direcciones pueden existir actualmente en una computadora que se ejecuta bajo el sistema operativo Windows de Microsoft. Diversas aplicaciones, como los clientes de correo electrónico y programas de finanzas personales, guardan libretas de direcciones individuales y tienen poca información compartida entre las aplicaciones de los datos de las libretas de direcciones que cada programa mantiene de manera individual. En consecuencia, un programa de finanzas (como Microsoft Money) no comparte direcciones para los beneficiarios con las direcciones que se mantienen en una carpeta de contactos de correo electrónico (como el de Microsoft Outlook). De hecho, muchos usuarios tienen múltiples dispositivos y sincronizan de manera lógica sus datos personales entre éstos y a través de una amplia variedad de fuentes adicionales, entre éstas, teléfonos celulares con servicios comerciales como MSN y AOL; sin embargo, la colaboración de los documentos compartidos se logra en gran medida anexando documentos a mensajes de correo electrónico, esto es, de manera manual e ineficiente.

Una razón para esta falta de colaboración es que los enfoques tradicionales a la organización de la información en sistemas de cómputo se han centrado en el uso de sistemas basados en archivo-carpeta-directorio ("sistemas de archivos") para organizar pluralidades de archivos en jerarquías de directorios de carpetas con base en una abstracción de la organización física del medio de almacenamiento que se usa para almacenar los archivos. El sistema operativo ultics, desarrollado durante 1960, puede recibir el crédito de ser el pionero en el uso de archivos, carpetas y directorios para administrar unidades de datos que se pueden almacenar en un nivel de sistema operativo. Específicamente, Multics usaba direcciones simbólicas dentro de una jerarquía de archivos (de esta manera presentaba la ¡dea de una ruta de archivos) en donde las direcciones físicas de los archivos no eran transparentes al usuario (aplicaciones y usuarios finales). Este sistema de archivos era completamente indiferente al formato de archivos de cualquier archivo individual y las relaciones entre los archivos se consideraban irrelevantes en el nivel de sistema operativo (esto es, diferente a la ubicación del archivo dentro de la jerarquía). Desde la llegada de Multics, los datos que se pueden almacenar se han organizado en archivos, carpetas y directorios en el nivel de sistema operativo. Estos archivos en general incluyen la jerarquía de archivos en sí mismos (el "directorio") representado en un archivo especial que mantiene el sistema de archivos. Este directorio, a su vez, mantiene una lista de entradas que corresponden a todos los otros archivos dentro del directorio y las ubicaciones nodales de dichos archivos en la jerarquía (en la presente se hace referencia a ésta como carpeta). Esto se ha mantenido como el diseño de última generación durante aproximadamente 40 años. Sin embargo, al proveer una representación razonable de información que reside en el sistema de almacenamiento físico de la computadora, un sistema de archivos no obstante es una abstracción de dicho sistema de almacenamiento físico, y por lo tanto la utilización de los archivos requiere un nivel de interpretación entre lo que el usuario manipula (unidades que tienen contexto, características y relaciones con otras unidades) y lo que provee el sistema operativo (archivos, carpetas y directorios). En consecuencia, los usuarios (aplicaciones y/o usuarios finales) no tienen otra opción más que forzar las unidades de información en una estructura de sistemas de archivos, incluso cuando lo hacen de una manera ineficiente, inconsistente o indeseable. Adicionalmente, los sistemas de archivos existentes no conocen la estructura de los datos almacenados en los archivos individuales, y debido a esto, la mayoría de la información permanece bloqueada en archivos a los que sólo se puede tener acceso (y es comprensible) a través de las aplicaciones mediante las cuales se escribieron. En consecuencia, esta falta de descripción esquemática de información y mecanismos para administrar la información, conduce a la creación de silos de datos con una baja capacidad de compartir datos entre los silos individuales. Por ejemplo, muchos usuarios de computadoras personales (PC) tiene más de cinco diferentes almacenes que contienen información sobre las personas con las que ¡nteractúan en algún nivel, por ejemplo, contactos de Outlook, direcciones de una cuenta en línea, una libreta de direcciones de Windows, beneficiarios de Quicken y una lista de amigos para su mensajero instantáneo, debido a que la organización de estos archivos presenta un reto importante para los usuarios de una computadora personal. Debido a que la mayoría de los sistemas de archivos existentes utilizan una metáfora de carpetas alojadas para organizar archivos y carpetas, y ya que el número de archivos aumenta, el esfuerzo necesario para mantener un esquema de organización que sea flexible y eficiente se convierte en un asunto desalentador. En situaciones como ésta, sería muy útil contar con diversas clasificaciones para un solo archivo; sin embargo, es difícil y complicado mantener el uso de enlaces físicos o enlaces lógicos en los sistemas de archivos existentes. En el pasado se han realizado diversos intentos para solucionar los inconvenientes de estos sistemas de archivos que, infortunadamente, no han tenido un resultado satisfactorio. Algunos de estos intentos anteriores han involucrado el uso de una memoria que está dirigida al contenido para proveer un mecanismo en donde se puede acceder a los datos a través del contenido, en lugar de una dirección física. Sin embargo, estos esfuerzos han probado que no son satisfactorios, ya que, aunque una memoria que puede dirigirse al contenido ha probado ser útil para un uso en pequeña escala por dispositivos como memorias intermedias y unidades de administración de memoria, el uso en gran escala para dispositivos como medios de almacenamiento físico no ha sido posible por diversas razones, y de esta manera, una solución como ésta no existe. Se han hecho otros intentos que usan sistemas de bases de datos orientados por objetos (OODB), pero estos intentos, mientras presentan fuertes características de bases de datos y buenas representaciones que no se refieren a archivos, no son efectivos en el manejo de representaciones de archivos y no pueden replicar la velocidad, eficiencia y simplicidad de la estructura jerárquica basada en archivos y carpetas en el nivel de un sistema de interfase de componentes físicos de computación y programas y sistemas de computación. Otros esfuerzos como los que han intentado usar SmallTalk (y otros derivados), probaron ser algo efectivos en el manejo de archivos y representaciones diferentes de archivos, pero carecieron de las características de bases de datos necesarias para organizar y utilizar de manera eficiente las relaciones que existen entre los diversos archivos de datos, y de esta manera la eficiencia general de dichos sistemas fue inaceptable. Otros intentos de usar BeOS (y otra investigación de sistemas operativos como tales) probaron ser inadecuados en el manejo de las representaciones diferentes de archivos, el mismo inconveniente central de los sistemas de archivos tradicionales, a pesar de poder representar de manera adecuada archivos mientras provee algunas características de bases de datos necesarias. La tecnología de las bases de datos es otra área en la técnica en donde existen retos similares. Por ejemplo, aunque el modelo de base de datos de relación ha sido un gran éxito comercial, entre los vendedores de programas y sistemas de computación independientes (ISV) reales generalmente ejecutan una pequeña porción de la funcionalidad disponible en los productos de programas y sistemas de programación de la base de datos relacional (por ejemplo el servidor SQL de Microsoft). En su lugar, la mayor parte de la interacción de una aplicación con un producto como tal es en la forma simple de "obtener" y "colocar". Aunque existe un número de razones evidentemente fáciles para esto, como puede ser una plataforma o una base de datos agnóstica, una razón clave que con frecuencia no se observa es que la base de datos no necesariamente provee las abstracciones exactas que necesita en realidad un vendedor de aplicaciones comerciales principal. Por ejemplo, mientras el mundo real sabe que los "elementos", como "cliente" o "solicitudes" (junto con "elementos de línea" incrustados en una solicitud como elementos dentro y de sí mismos), las bases de datos relaciónales sólo se refieren a tablas y filas. En consecuencia, aunque puede ser deseable que la aplicación tenga aspectos referentes a la consistencia, bloqueo, seguridad y/o se active en el nivel de elemento (sólo por nombrar algunos), las bases de datos en general proporcionan estas características sólo en un nivel de tabla/fila. Aunque esto puede funcionar bien si cada elemento se correlaciona con una sola fila en una tabla en la base de datos, en el caso de una solicitud con múltiples elementos en la línea puede haber razones por las que un elemento se correlaciona en realidad con diversas tablas y, cuando éste es el caso, el sistema de base de datos relaciónales simples no proporciona las abstracciones correctas. En consecuencia, una aplicación debe construir una lógica en la parte superior de la base de datos para proveer estas abstracciones lógicas. En otras palabras, el modelo relacional básico no proporciona una plataforma suficiente para el almacenamiento de datos en los que las aplicaciones de niveles superiores pueden desarrollarse fácilmente debido a que el modelo relacional básico requiere un nivel de interpretación entre la aplicación y el sistema de almacenamiento, en donde la estructura semántica de los datos sólo puede ser visible en la aplicación en algunas circunstancias. Mientras que algunos vendedores de bases de datos están construyendo un nivel superior de funcionalidad en sus productos, por ejemplo al proveer capacidades relaciónales de objetos, los nuevos modelos organizacionales y similares, ninguno ha logrado proveer una clase de solución completa necesaria, en donde una solución completa real es la que proporciona tanto abstracciones de modelo de datos útiles (por ejemplo "elemento", "extensiones", "relaciones", etcétera) como abstracciones de dominio útil (por ejemplo "persona", "ubicaciones", "evento", etcétera). Tomando en cuenta las deficiencias mencionadas en los sistemas de almacenamiento de datos existentes y en la tecnología de bases de datos, existe la necesidad de una nueva plataforma de almacenamiento que provea una capacidad mejorada para organizar, buscar y compartir todos los tipos de datos en un sistema de cómputo, una plataforma de almacenamiento que extiende y amplía la plataforma de datos más allá de los sistemas de los archivos existentes y los sistemas de las bases de datos, y que está diseñada para almacenar todo tipo de datos. La presente invención satisface esta necesidad. Sumario de la Invención La siguiente breve descripción proporciona una descripción general de diversos aspectos de la invención. No tiene la intención de proveer una descripción completa de todos los aspectos importantes de la invención, tampoco de definir el alcance de la invención. En su lugar, esta breve descripción tiene la intención de servir como una introducción a la descripción detallada y las figuras a continuación. La presente invención está dirigida a una plataforma de almacenamiento para organizar, buscar y compartir datos. La plataforma de almacenamiento de la presente invención extiende y amplía el concepto de almacenamiento de datos más allá de los sistemas de archivos existentes y los sistemas de base de datos existentes, y está diseñada para almacenar todo tipo de datos, incluyendo datos estructurados, no estructurados o semiestructurados. De conformidad con un aspecto de la presente invención, la plataforma de almacenamiento de la presente invención comprende un almacén de datos implementado en un motor de base de datos. En varias modalidades de la presente invención, el motor de la base de datos comprende un motor de base de datos relacional con extensiones relaciónales por objeto. El almacén de datos implementa un modelo de datos que da soporte a las acciones de organizar, buscar, compartir, sincronizar y proporcionar seguridad a los datos. Los tipos específicos de datos se describen en esquemas y la plataforma proporciona un mecanismo para extender el conjunto de esquemas y definir nuevos tipos de datos (esencialmente subtipos de los tipos básicos que proporcionan los esquemas). Una capacidad de sincronización facilita compartir los datos entre los usuarios o sistemas. Se proporcionan capacidades similares a las de un sistema de archivos que permiten la interoperabilidad del almacén de datos con los sistemas de archivos existentes sin las limitaciones de dichos sistemas de archivos tradicionales. Un mecanismo de seguimiento de cambios proporciona la capacidad de dar seguimiento a los cambios que se hacen en el almacén de datos. La plataforma de almacenamiento además comprende un conjunto de interfases de programas de aplicación que permite que las aplicaciones accedan a todas las capacidades mencionadas de la plataforma de almacenamiento y para acceder a los datos descritos en los esquemas. De conformidad con otro aspecto de la presente invención, el modelo de datos implementado por el almacén de datos define unidades de almacenamiento de datos en términos de elementos, elementos y relaciones. Un elemento es una unidad de datos que puede almacenarse en un almacén de datos y puede comprender uno o más elementos y relaciones. Un elemento es por ejemplo un tipo que comprende uno o más campos (también denominado en la presente como propiedad). Una relación es un enlace entre dos elementos (como se usa en la presente, estos y otros términos específicos pueden mostrarse en mayúsculas para diferenciarlos de otros términos usados en cercanía, sin embargo, no hay intención alguna de distinguir entre un término en mayúsculas, por ejemplo "Elemento", y el mismo término cuando se muestra en minúsculas, por ejemplo "elemento", y no debe hacerse o implicar distinción alguna).

De conformidad con otro aspecto de la presente invención, un sistema de cómputo comprende una pluralidad de elementos, en donde cada elemento constituye una unidad discreta de información que se puede almacenar de manera discreta que se puede manipular a través de un sistema de interfases de componentes físicos de computación/programas y sistemas de programación; una pluralidad de carpetas de elementos que constituyen una estructura organizacional de dichos elementos; y un sistema de interfases de componentes físicos de computación/programas y sistemas de programación para manipular una pluralidad de elementos y en donde cada elemento pertenece al menos a una carpeta de elementos y puede pertenecer a más de una carpeta de elementos. De conformidad con otro aspecto de la presente invención, un sistema de cómputo comprende una pluralidad de elementos, en donde cada elemento constituye una unidad de información discreta que se puede almacenar y que se puede manipular a través de un sistema de interfases de componentes físicos de computación/programas y sistemas de programación, y el elemento o algunos valores de propiedad del elemento se calculan de manera dinámica de manera contraria a la derivación de un almacén persistente. En otras palabras, el sistema de interfases de componentes físicos de computación/programas y sistemas de programación no requiere que el elemento sea almacenado y soporta algunas operaciones, por ejemplo la capacidad de enumerar el conjunto actual de elementos o la capacidad de recuperar un elemento dado su identificador (que se describe detalladamente en las secciones que describen la interfase de programación de aplicaciones o API) de la plataforma de almacenamiento, por ejemplo, un elemento puede ser la ubicación actual de un teléfono celular o la lectura de la temperatura de un sensor de un termómetro. De conformidad con otro aspecto de la presente invención, el sistema de interfases de componentes físicos de computación/programas y sistemas de programación para un sistema de cómputo, en donde dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación manipula una pluralidad de elementos, además comprende elementos ¡nterconectados a través de una pluralidad de relaciones manejadas a través del sistema de interfases de componentes físicos de computación/programas y sistemas de programación. De conformidad con otro aspecto de la presente invención, el sistema de interfases de componentes físicos de computación/programas y sistemas de programación para un sistema de cómputo, en donde dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación manipula una pluralidad de unidades discretas de información que tiene propiedades que son comprendidas por dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación. De conformidad con otro aspecto de la • presente invención, un sistema de interfases de componentes físicos de computación/programas y sistemas de programación para un sistema de cómputo comprende un esquema núcleo para definir un conjunto de elementos de núcleo en donde dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación entiende y puede procesar de manera directa en una manera predecible y predeterminada. De conformidad con otro aspecto de la presente invención, un método para manipular una pluralidad de unidades discretas de información (elementos) en un sistema de ¡nterfaces de componentes físicos de computación/programas y sistemas de programación para un sistema de cómputo, dicho método comprende interconectar dichos elementos con una pluralidad de relaciones y administrar dichas relaciones en el nivel del sistema de interfases de componentes físicos de computación/programas y sistemas de programación, se describe. De conformidad con otra característica de la invención, la API de la plataforma de almacenamiento proporciona las clases de datos para cada elemento, la extensión del elemento y la relación definida en el conjunto de esquemas de la plataforma de almacenamiento. Además, la interfase de programación de aplicaciones proporciona un conjunto de clases de estructura que definen un conjunto común de conductas para las clases de datos y, junto con las clases de datos, proporcionan el modelo de programación básico para la API de la plataforma de almacenamiento. De conformidad con otra característica de la presente invención, la API de la plataforma de almacenamiento proporciona un modelo de consulta simplificado que permite que los programadores de la aplicación formulen consultas con base en varias propiedades de los elementos del almacén de datos, en una manera que aisla al programador de la aplicación de los detalles del lenguaje de consulta del motor de la base de datos subyacente. De conformidad con otro aspecto de la API de la plataforma del almacenamiento de la presente invención, la API también recolecta los cambios que se hicieron a un elemento a través de un programa de aplicación y después los organiza en las actualizaciones correctas requeridas por el motor de la base de datos (o cualquier tipo de motor de almacenamiento) en donde se implementa el almacén de datos. Esto permite que los programadores de la aplicación hagan cambios en un elemento dentro de la memoria, mientras dejan la complejidad de las actualizaciones del almacén de datos a la API. A través de estos fundamentos del almacenamiento común y los datos esquematizados, la plataforma de almacenamiento de la presente invención habilita un desarrollo más eficiente de la aplicación para los clientes, trabajadores intelectuales y las empresas. Ofrece una interfase de programación de aplicaciones rica y extensible que no sólo ofrece la disponibilidad de las capacidades inherentes a este modelo de datos, también involucra y extiende el sistema de archivos existentes y los métodos de acceso a la base de datos. Otras características y utilidades de la invención serán evidentes a partir de la siguiente descripción detallada de la invención y los dibujos anexos. Breve Descripción de los Dibujos La breve descripción mencionada, así como la siguiente descripción detallada de la invención se comprende de mejor manera al leerse en conjunto con los dibujos anexos. Con el objetivo de ilustrar la invención, se muestra en los dibujos modalidades ejemplares de diversos aspectos de la invención; sin embargo, la invención no está limitada a los métodos específicos y a las modalidades descritas. En los dibujos: La figura 1 es un diagrama de bloques que representa un sistema de cómputo en donde los aspectos de la presente invención se pueden incorporar; la figura 2 es un diagrama de bloques que ¡lustra un sistema de cómputo dividido en tres grupos de componentes: los componentes físicos de computación, el componente del sistema de interfases de los componentes físicos de computación/programas y sistemas de programación, y el componente de programas de la aplicación; la figura 2A ¡lustra la estructura jerárquica basada en árbol tradicional para los archivos agrupados en carpetas en un directorio en un sistema operativo basado en archivos; la figura 3 es un diagrama de bloques que ilustra una plataforma de almacenamiento de conformidad con la presente invención; la figura 4 ilustra la relación estructural entre los Elementos, las Carpetas de los Elementos y Categorías; la figura 5A es un diagrama de bloques que ilustra la estructura de un elemento; la figura 5B es un diagrama de bloques que ¡lustra los tipos de propiedades complejas de un elemento de la figura 5A; la figura 5C es un diagrama de bloques que ilustra el elemento de "ubicación" en donde sus tipos complejos se describen adicionalmente (se enumeran explícitamente); la figura 6A ¡lustra un elemento como un subtipo de un elemento que se encuentra en el esquema base; la figura 6B es un diagrama de bloques que ilustra el elemento subtipo de la figura 6A en donde sus tipos heredados se enumeran explícitamente (además de sus propiedades inmediatas); la figura 7 es un diagrama de bloques que ilustra el esquema base que incluye sus dos tipos de clases de nivel superior, el elemento y la propiedad base (Item y PropertyBase) y los tipos de esquema base adicionales derivados de éstos; la figura 8A es un diagrama de bloques que ilustra los elementos en el esquema núcleo; la figura 8B es un diagrama de bloques que ilustra los tipos de propiedad en el esquema núcleo; la figura 9 es un diagrama de bloques que ilustra una carpeta de elementos, sus elementos miembros y las relaciones de interconexión entre la carpeta de elementos y sus elementos miembros; la figura 10 es un diagrama de bloques que ¡lustra una categoría (la cual, nuevamente, es un elemento en sí mismo), sus elementos miembros y las relaciones de interconexión entre la categoría y sus elementos miembros; la figura 11 es un diagrama que ¡lustra una jerarquía del tipo de referencia del modelo de datos de la plataforma de almacenamiento; de conformidad con la presente invención la figura 12 es un diagrama que ilustra la manera en que se clasifican las relaciones, de conformidad con una modalidad de la presente invención; la figura 13 es un diagrama que ilustra un mecanismo de notificación, de conformidad con una modalidad de la presente invención; la figura 14 es un diagrama que ilustra un ejemplo en donde dos transacciones insertan un nuevo registro en el mismo árbol B; la figura 15 ¡lustra un proceso de detección de cambios, de conformidad con una modalidad de la presente invención; la figura 16 ilustra un árbol del directorio ejemplar; la figura 17 muestra un ejemplo en donde una carpeta existente de un sistema de archivos basado en un directorio se mueve en el almacén de datos de la plataforma de almacenamiento, de conformidad con un aspecto de la presente invención; la figura 18 ilustra el concepto de las carpetas de contención, de conformidad con un aspecto de la presente invención; la figura 19 ¡lustra la arquitectura básica de la API de la plataforma de almacenamiento; la figura 20 representa esquemáticamente los diversos componentes de la pila de la API de la plataforma de almacenamiento; las figuras 21A y 21B son una representación pictórica de un esquema de contactos ejemplar (Elementos y Elementos); la figura 22 ilustra la estructura del tiempo de ejecución de la API de la plataforma de almacenamiento, de conformidad con un aspecto de la presente invención; la figura 23 ilustra la ejecución de una operación de Buscar todo (FindAII), de conformidad con una modalidad de la presente invención; la figura 24 ilustra el proceso mediante el cual las clases de la API de la plataforma de almacenamiento se generan desde el esquema de la plataforma de almacenamiento, de conformidad con un aspecto de la presente invención; la figura 25 ilustra un esquema en el que se basa una API de archivos, de conformidad con otro aspecto de la presente invención; la figura 26 es un diagrama que ilustra un formato de máscara de acceso que se usa con el objetivo de seguridad de los datos, de conformidad con una modalidad de la presente invención; las figuras 27(a), (b) y (c) ilustran una región de seguridad protegida de manera idéntica forjada de una región de seguridad existente de conformidad con una modalidad de un aspecto de la presente invención; la figura 28 es un diagrama que ¡lustra el concepto de un formulario de búsqueda de elementos, de conformidad con una modalidad de un aspecto de la presente invención; y la figura 29 es un diagrama que ¡lustra una jerarquía de elementos ejemplar, de conformidad con una modalidad de la presente invención; Desc ri pc i ón Detal lada de l a I nvenc i ón I N D I C E INTRODUCCIÓN A. ENTORNO DE CÓMPUTO EJEMPLAR B. ALMACENAMIENTO TRADICIONAL BASADO EN ARCHIVOS UNA NUEVA PLATAFORMA DE ALMACENAMIENTO PARA ORGANIZAR, BUSCAR Y COMPARTIR DATOS A. GLOSARIO B. DESCRIPCIÓN GENERAL DE LA PLATAFORMA DE ALMACENAMIENTO C. MODELO DE DATOS 1. Elementos 2. Identificación de elementos a) Referencias de elementos (1) ItemIDReference (Referencia de la identificación del elemento) (2) ItemPathReference (Referencia del trayecto del elemento) b) Jerarquía del tipo de referencias 3. Carpetas y categorías del elemento 4. Esquemas 68 a) Esquema Base b) Esquema Núcleo 5. Relaciones 75 a) Relación de declaración 76 b) Relaciones de propiedad 79 c) Relaciones de incrustación 81 d) Relaciones de referencia e) Reglas y restricciones f) Orden de las relaciones < 6. Capacidad de extensión 96 a) Extensiones del elemento ^8 b) Extensión de los tipos de elementos anidados (NestedElement) 105 D. MOTOR DE LA BASE DE DATOS 08 1. Implementación del almacén de datos usando UDT ^ 1 ^ 2. Correlación de elementos ^ 3. Correlación de extensiones 120 4. Correlación de elementos anidados ^ 5. Identidad del objeto 123 6. Denominación de objetos de SQL 123 7. Denominación de columnas 125 8. Formularios de búsqueda 125 a) Elemento ^27 (1 ) Formulario maestro de búsqueda de elementos ^27 (2) Formularios de búsqueda de elementos portipo 128 b) Extensiones del elemento 123 (1) Formulario maestro de búsqueda de extensiones ^23 (2) Formularios de búsqueda de extensiones por tipo ^ c) Elementos anidados ^ d) Relaciones 132 (1) Formulario maestro de búsqueda de relaciones ^32 133 (2) Formularlos de búsqueda de instancias de relación 9. Actualizaciones ' M 10. Seguimiento de cambios y lápidas 136 a) Seguimiento de cambios 136 137 (1) Seguimiento de cambios en formularios "maestro"de búsqueda 139 (2) Seguimiento de cambios en formularios de búsqueda "por tipo" b) Lápidas 140 (1 ) Lápidas de elementos 140 (2) Lápidas de extensiones 141 ^ (3) Lápida de relaciones 141 (4) Limpieza de lápidas 142 1 . Funciones y API de ayuda 43 a) Función [System.Storage].Getltem 143 b) Función [System.Storage].GetExtension 143 c) Función [System.Storage].GetRelafionship 143 12. Metadatos 4 a) Metadatos de esquema 44 b) Metadatos de instancia 144 E. SEGURIDAD 45 1. Descripción general 45 0 2. Descripción detallada del modelo de seguridad 155 a) Estructura del descriptor de seguridad 155 (1 ) Formato de máscara de acceso 158 (2) Derechos de acceso genérico 58 (3) Derechos de acceso estándar 59 b) Derechos específicos del elemento 60 (1 ) Derechos específicos del objeta de Archivo y Directorio 160 (2) Lectura de elementos WinFS (WinFSItemRead) 63 (3) Atributos de lectura de los elementos inFS 163 (WlnFSltemReadAttributes ) (4) Atributos de escritura de los elementos WinFS 164 (WlnFSÍtemWriteAttributes) 5 (5) Escritura de elementos WinFS (WinFSItemWrite) 164 (6) Agregar enlace al elemento WinFS (WinFSAddLink) 165 (7) Eliminar enlace del elemento WinFS (WinFSDeleteLink) 166 (8) Derechos para eliminar un elemento ^ (9) Derechos para copiar un elemento 167 (10) Derechos para mover un elemento I*"7 (11 ) Derechos para visualizar la política de seguridad en un 169 elemento (12) Derechos para cambiar la política de seguridad en un 69 elemento (13) Derechos que no tienen un equivalente directo 1*>9 Q 3. Implementación 170 a) Creación de un elemento nuevo en un contenedor 7 b) Adición de una ACL explícita en un elemento c) Adición de una relación de propiedad a un elemento d) Eliminación de una relación de propiedad de un elemento e) Eliminación de una ACL explícita de un elemento f) Modificación de una ACL asociada con un elemento F. SEGUIMIENTO DE CAMBIOS Y NOTIFICACIONES 1. Eventos de cambio en el almacenamiento 176 a) Eventos 177 b) Vigilantes 2. Mecanismo para el seguimiento de cambios y generación de notificaciones '° ' a) Seguimiento de cambios 185 b) Gestión del reto) marcador 186 c) Detección de cambios en los datos - Detección de eventos ^ 8 G. SINCRONIZACIÓN 189 1. Sincronización de plataforma de almacenamiento - plataforma de almacenamiento ^1 a) Aplicaciones de control de sincronización (Sync) ^9 b) Anotación de esquemas 193 c) Configuración de sincronización ^ (1) Correlaciones de las carpetas de comunidad ^ 8 (2) Perfiles 199 (3) Programaciones 201 d) Manejo de conflictos 202 (1) Detección de conflictos 2"3 (a) Conflictos basados en el 203 conocimiento (b) Conflictos basados en las 204 restricciones (2) Procesamiento de conflictos 204 206 ^ Q (a) Resolución automática de conflictos (b) Registro de conflictos 207 208 (c) Inspección y resolución de conflictos (d) Convergencia de réplicas y 209 propagación de resoluciones de conflictos 210 2. Sincronización de almacenes de datos diferentes de la plataforma de almacenamiento a) Servicios de sincronización 211 (1 ) Enumeración de cambios ^ ^ (2) Aplicación de cambios 213 (3) Resolución de conflictos 2^ 15 t,) Implementación del adaptador 215 3. Seguridad 16 4. Capacidad de gestión 217 H. INTEROPERABILIDAD CON EL SISTEMA DE ARCHIVOS TRADICIONAL 218 1. Modelo de interoperabilidad 220 2. Características del almacén de datos 222 a) No es de volumen 222 b) Estructura del almacén 223 c) No han mígrado todos los archivos 224 d) Acceso de espacio de nombre NTFS para los archivos de la plataforma de 224 almacenamiento 0 e) Letras esperadas para el espacio de nombre/unidades 225 I. API DE LA PLATAFORMA DE ALMACENAMIENTO 2 5 1. Descripción general 8 2. Denominaciones y alcances 228 3. Componentes de la API de la plataforma de almacenamiento 232 4. Clases de datos 234 5. Estructura del tiempo de ejecución 7 a) Clases de estructuras del tiempo de ejecución 4 (1) Contexto del elemento (ItemContext) (2) Buscador de elementos (ItemSearcher) 5 (a) Tipo de objetivo 251 (b) Filtros 252 (c) Preparación de 252 búsquedas (d) Opciones de búsqueda 2^8 256 (3) Flujo de resultados del elemento ("FindResults") b) Estructura del tiempo de ejecución en la operación 258 c) Patrones de programación común 59 ? (1) Abertura y cierre de los objetos de contexto del 259 elemento (ItemContext) (2) Búsqueda de objetos ^1 (a) Opciones de 284 búsqueda (b) Encontrar uno 255 (FindOne) y Encontrar sólo (FindOnly) (c) Búsqueda de métodos 288 abreviados en el contexto del elemento (ItemContext) (d) Búsqueda por ID o por S^ 10 trayecto (e) Patrón para obtener 268 un buscador (GetSearcher) (3) Actualización del almacén 89 6. Seguridad 272 7. Soporte de relaciones 73 a) Tipos de relación Base 274 (1 ) Clase de Relación (Relationship) 275 (2) Clase de Referencia del elemento 276 (ItemReference) (3) Clase de Referencia de ID del Elemento 277 15 (ItemldReference) (4) Clase de Referencia de trayecto del elemento 278 (ItemPathReference) (5) Estructura de la Id de relación (Relationshipld) 280 (6) Clase de la colección de relaciones virtuales 28"1 (VirtualRelationshlpCollection) b) Tipos de relación Generada 285 (1 ) Tipos de relaciones Generadas 286 (2) Clase de prototipo de relaciones 287 (RelationshipPrototype) (3) Clase de colección de prototipos de la relación 88 (RelationshipPrototypeCollection) 20 c) Soporte de las relaciones en la clase de elemento 289 (1 ) Clase de elemento (Item) 290 (2) Clase de colección de relaciones 290 (RelatlonshipCollection) d) Soporte de las relaciones en las expresiones de búsqueda 291 (1 ) Cruce de elemento3 a relaciones ^ (2) Cruce de relaciones a elementos 292 (3) Combinación de cruce de relaciones 29<* e) Ejemplos de los usos del soporte de relación 295 (1 ) Búsqueda de relaciones 295 (2) Navegación de una relación a los elementos 297 origen y objetivo 25 (3) Navegación de los elementos de origen a 299 relaciones (4) Creación de relaciones (y elementos) 3u2 (5) Eliminación de relaciones (y elementos) 303 8. "Extensión" de la API de la plataforma de almacenamiento 3n a) Comportamientos de dominio 304 b) Comportamientos de valor agregado 06 c) Comportamientos de valor agregado como proveedores de servicio 9. Diseño de la estructura del tiempo 310 10. Formalismos de consulta 312 a) Puntos básicos de filtrado 312 b) Fusiones de tipo 315 c) Sintaxis de filtro 316 11. Acciones remotas 318 a) Transparencia local/remota en la API 3^ b) Implementacion da la plataforma de almacenamiento en las acciones 319 remotas c) Acceso a almacenes diferentes a la plataforma de almacenamiento 19 d) Relación con DFS 320 e) Relación con GXA/[ndigo 320 2. Restricciones 321 13. Compartir 325 a) Representación de una acción de compartir 26 b) Gestión de las partes 327 c) Acceso a las partes 3 d) Capacidad de descubrimiento 328 14. Valores semánticos de la búsqueda 3 ^ 15. API de contactos de la plataforma de almacenamiento 3 ^ a) Descripción de System.Storage.Contact 331 b) Conductas de dominio 3 ^ 16. API de los archivos de la plataforma de almacenamiento 334 a) Introducción 33 (1 ) Reflejo de un volumen de NTFS en la 334 plataforma de almacenamiento 335 (2) Creación de archivos y directorios en el espacio de nombre de la plataforma de almacenamiento b) Esquema de archivos 7 c) Descripción de System.Storage.FHes 7 d) Ejemplos de códigos 338 (1 ) Cómo abrir un archivo y escribir en él 338 (2) Uso de consultas 339 e) Comportamientos de dominio 340 J. Conclusiones 34" I. INTRODUCCIÓN La materia de objeto de la presente invención se describe de manera específica para cubrir los requerimientos establecidos por ley. Sin embargo, la descripción en sí misma no tiene la intención de limitar el alcance de esta patente. En su lugar, los inventores han contemplado que la materia que se reclama también se puede representar de otras maneras, para que incluya diferentes pasos o combinaciones de pasos, similares a los descritos en este documento, en conjunto con otras tecnologías presentes o futuras. Adicionalmente, aunque el término "paso" se puede usar en la presente para connotar diferentes elementos de los métodos que se emplean, el término no debe interpretarse con una implicación de un orden particular entre varios pasos descritos en la presente a menos y con la excepción de que el orden de los pasos individuales se describa de manera explícita. A. ENTORNO DE CÓMPUTO EJEMPLAR Diversas modalidades de la presente invención se pueden ejecutar en una computadora. La figura 1 y el análisis a continuación tienen la intención de proveer una descripción breve y general de un entorno de cómputo adecuado en donde la invención se puede implementar. Aunque no se requiere, diversos aspectos de la invención se pueden describir en el contexto general de las instrucciones ejecutables a través de una computadora, por ejemplo módulos de programa, ejecutados por una computadora, como estaciones de trabajo cliente o un servidor. En general, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos y similares que realizan tareas particulares o implementan tipos de datos abstractos. Adicionalmente, la invención se puede practicar con otras configuraciones de sistemas de cómputo, incluyendo dispositivos portátiles, sistemas con procesadores múltiples, aparatos electrónicos programables por el consumidor o basados en microprocesadores, computadoras personales conectadas en red, minicomputadoras, computadoras de estructura principal y similares. La invención también se puede practicar en entornos de cómputo distribuido, en donde las tareas se realizan a través de dispositivos de procesamiento remoto que se enlazan a través de una red de comunicaciones. En un entorno de cómputo distribuido, los módulos de programa se pueden ubicar en dispositivos de almacenamiento de memoria local o remota. Como se muestra en la figura 1, un sistema de cómputo de objetivo general ejemplar incluye una computadora personal 20 convencional o similar, que incluye una unidad de procesamiento 21, una memoria del sistema 22 y una barra de distribución del sistema 23 que acopla varios componentes del sistema, incluyendo la memoria del sistema a la unidad de procesamiento 21. La barra de distribución del sistema 23 puede ser cualquiera de diversos tipos de estructuras de barras de distribución, incluyendo una barra de distribución de memoria o controlador de memoria, una barra de distribución periférica y una barra de distribución local que usa cualquiera de una variedad de arquitecturas de barras de distribución. La memoria del sistema incluye una memoria de sólo lectura (ROM) 24 y una memoria de acceso aleatorio (RAM) 25. Un sistema básico de entradas y salidas (BIOS) 26, que contiene las rutinas básicas que ayudan a transferir información entre los elementos dentro de una computadora personal 20, por ejemplo durante el arranque, que se almacena en la memoria de sólo lectura (ROM) 24. La computadora personal 20 además incluye una unidad de disco duro 27 para leer y escribir en un disco duro, no se muestra, una unidad de disco magnético 28 para leer o escribir en un disco magnético extraíble 29, y una unidad de disco óptico 30 para leer o escribir en un disco óptico extraíble 31, por ejemplo un CD-ROM u otro medio óptico. La unidad de disco duro 27, la unidad de disco magnético 28 y la unidad de disco óptico 30 se conectan a la barra de distribución del sistema 23 a través de una ¡nterfase de disco duro 32, una ¡nterfase de unidad de disco magnético 33 y una interfase de unidad óptica 34, respectivamente. Las unidades y sus medios legibles a través de una computadora asociados proporcionan un almacenamiento permanente de las instrucciones legibles a través de una computadora, estructuras de datos, módulos de programas y otros datos de la computadora personal 20. Aunque el entorno ejemplar que se describe en la presente emplea una unidad de disco duro, un disco magnético extraíble 29 y un disco óptico extraíble 31, debe ser evidente para los expertos en la técnica que otros tipos de medios legibles por computadora que puedan almacenar datos accesibles a través de una computadora, como casetes magnéticos, tarjetas de memoria intermedia, discos de video digital, cartuchos de Bernoulli, memorias de acceso aleatorio (RAM), memorias de sólo lectura (ROM) y similares también se pueden usar en el entorno operativo ejemplar. De igual manera, el entorno operativo ejemplar también puede incluir muchos tipos de dispositivos de supervisión como sensores de calor y sistemas de alarma de seguridad o contra incendio, y otras fuentes de información.

Diversos módulos de programa se pueden almacenar en el disco duro, en el disco magnético 29, en el disco óptico 31, en la ROM 24 o en la RAM 25, incluyendo un sistema operativo 35, uno o más programas de aplicación 36, otros módulos de programa 37 y datos de programa 38. Un usuario puede introducir comandos e información en la computadora personal 20 a través de dispositivos de entrada como un teclado 40 o un dispositivo puntero 42. Otros dispositivos de entrada (no se muestran) pueden incluir un micrófono, una palanca de mando, una almohadilla de juegos, una antena parabólica, un digitalizador o similar. Estos y otros dispositivos de entrada con frecuencia se conectan a la unidad de procesamiento 21 a través de una interfase 46 de un puerto en serie que se acopla a la barra de distribución del sistema, pero puede estar conectado a través de otras interfases, por ejemplo un puerto paralelo, un puerto de juegos o una barra de distribución en serie universal (USB). Un monitor 47 u otro tipo de dispositivo de visualización también se conecta a la barra de distribución del sistema 23 a través de una interfase, por ejemplo un adaptador de video 48. Además del monitor 47, las computadoras personales típicamente incluyen otros dispositivos de salida periférica (no se muestran), por ejemplo altavoces e impresoras. El sistema ejemplar de la figura 1, también incluye un adaptador principal 55, una barra de distribución e interfase del sistema de cómputo pequeño (SCSI) 56, y un dispositivo de almacenamiento externo 52 conectado a la barra de distribución SCSI 56. La computadora personal 20 puede funcionar en un entorno conectado en red usando conexiones lógicas a una o más computadoras remotas, por ejemplo una computadora remota 49. La computadora remota 49 puede ser otra computadora personal como un servidor, un ruteador, una computadora personal en red, un dispositivo cliente u otro nodo de red común, y típicamente incluye varios o todos los elementos descritos en párrafos anteriores con relación a la computadora personal, aunque sólo un dispositivo de almacenamiento de memoria 50 se ilustra en la figura 1. Las conexiones lógicas que se ¡lustran en la figura 1 incluyen una red de área local (LAN) 51 y una red de área extensa (WAN) 52. Dichos entornos conectados en red son lugares comunes en oficinas, en redes de cómputo de toda una empresa, redes internas así como en Internet. Cuando se usa en un entorno conectado en red en una red de área local, la computadora personal 20 se conecta a la red de área local 51 a través de una interfase de red o adaptador 53. Cuando se usa en un entorno conectado en red en una red de área extensa, la computadora personal 20 típicamente incluye un módem 54 u otros medios para establecer comunicaciones sobre la red de área extensa 52, por ejemplo Internet. El módem 54, que puede ser interno o externo, se conecta a la barra de distribución del sistema 23 a través de una interfaz de un puerto en serie 46. En un entorno conectado en red, los módulos de programa que se ilustran con relación a la computadora personal 20, o porciones de ésta, se pueden almacenar en el dispositivo de almacenamiento de memoria remota. Será evidente que las conexiones en red que se muestran son ejemplares y que se puede usar otros medios para establecer un enlace de comunicación entre las computadoras. Como se ilustra en el diagrama de bloques de la figura 2, un sistema de cómputo 200 se puede dividir aproximadamente en tres grupos de componentes: los componentes físicos de computación 202, el componente del sistema de interfases de componentes físicos de computación/programas y sistemas de programación 204 y el componente de programas de aplicaciones 206 (también denominado como el "componente de usuario" o "componente de programas y sistemas de programación" en algunos contextos de la presente). En diversas modalidades de un sistema de cómputo 200 haciendo referencia nuevamente a la figura 1, los componentes físicos de computación 202 pueden comprender la unidad de procesamiento central (CPU) 21, la memoria (tanto la memoria de sólo lectura (ROM) 24, como la memoria de acceso aleatorio (RAM) 25), el sistema básico de entradas y salidas (BIOS) 26, y diversos dispositivos de entradas/salidas (l/O) como un teclado 40, un ratón 42, un monitor 47 y/o una impresora (no se muestra), entre otras cosas. Los componentes físicos de computación 202 comprenden la infraestructura física básica para el sistema de cómputo 200. El componente 206 de los programas de aplicaciones comprende varios programas de los programas y sistemas de programación que incluyen, sin limitarse a esto, compiladores, sistemas de bases de datos, procesadores de palabras, programas de negocios, videojuegos, etc. Los programas de aplicación proporcionan los medios mediante los cuales se usan los recursos de la computadora para resolver problemas, proveer soluciones y procesar datos para diversos usuarios (máquinas, otros sistemas de cómputo, y/o usuarios finales). El componente 204 del sistema de interfases de componentes físicos de computación/programas y sistemas de programación comprende (y, en algunas modalidades, puede consistir únicamente de) un sistema operativo que en sí mismo comprende, en la mayoría de los casos, una cubierta y un núcleo. Un "sistema operativo" (OS) es un programa especial que actúa como un intermediario entre los programas de aplicación y los componentes físicos de la computadora. El componente 204 del sistema de interfases de los componentes físicos de computación y de programas y sistemas de programación también pueden comprender un administrador de máquina virtual (VMM), un tiempo de ejecución de lenguaje común (CLR) o su equivalente funcional, una máquina virtual Java (JVM) o su equivalente funcional, u otros componentes de programas y sistemas de programación en lugar de o además del sistema operativo en un sistema de cómputo. El objetivo de un sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación es proveer un entorno en donde un usuario pueda ejecutar programas de aplicación. El objetivo de cualquier sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación es hacer un uso cómodo del sistema de cómputo, así como utilizar los componentes físicos de cómputo de una manera eficiente. El sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación generalmente se cargan en un sistema de cómputo al inicio y después administra todos los programas de aplicación en el sistema de cómputo. Los programas de aplicación interactúan con el sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación al solicitar los servicios a través de una interfaz del programa de aplicación (API). Algunos programas de aplicación permiten que los usuarios finales interactúen con el sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación a través de una ¡nterfase de usuario como una interfase de lenguaje de comandos o una inferíase gráfica del usuario (GUI). Un sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación tradicionalmente realizan una variedad de servicios para las aplicaciones. En un sistema de interfases de componentes físicos de computación/programas y sistemas de programación de tareas múltiples, en donde diversos programas se pueden ejecutar al mismo tiempo, el sistema de interfases de componentes físicos de computación/programas y sistemas de programación determina las aplicaciones que se deben ejecutar, el orden y el tiempo que se debe permitir a cada aplicación antes de cambiar a otra aplicación para que tome su turno. El sistema de interfases de componentes físicos de computación/programas y sistemas de programación también administran la manera de compartir la memoria interna entre múltiples aplicaciones y maneja la entrada y salida hacia y desde los dispositivos de los componentes físicos de computación anexados como discos duros, impresoras, puertos de marcación. El sistema de interfases de componentes físicos de computación/programas y sistemas de programación también envía mensajes a cada aplicación (y, en algunos casos, al usuario final) observando el estado de las operaciones y los errores que pueden haberse generado. El sistema de interfases de componentes físicos de computación/programas y sistemas de programación también puede descargar la administración de las tareas en lote (por ejemplo, la impresión) de manera que la aplicación que inicia se libera de este trabajo y puede reanudar otro proceso y/u otras operaciones. Las computadoras que pueden proveer un procesamiento paralelo, un sistema de interfases de componentes físicos de computación/programas y sistemas de programación también administra la división de un programa de manera que se ejecuta en más de un procesador a la vez. Una cubierta del sistema de interfases de componentes físicos de computación/programas y sistemas de programación (denominada simplemente en la presente como "cubierta") es una interfase interactiva del usuario final con un sistema de interfases de componentes físicos de computación/programas y sistemas de programación (una cubierta también se puede denominar como un "intérprete de comando" o, en un sistema operativo, una "cubierta del sistema operativo"). Una cubierta es la capa externa del sistema de interfases de componentes físicos de computación/programas y sistemas de programación al que se puede tener acceso directamente a través de los programas de la aplicación y/o los usuarios finales. En contraste a una cubierta, un núcleo es la capa más interna del sistema de interfases y componentes físicos de computación/programas y sistemas de programación que interactúan directamente con los componentes físicos de computación.

Aunque se prevé que diversas modalidades de la presente invención estén bien adecuadas para los sistemas computarizados, nada contenido en este documento tiene la intención de limitar la invención a dichas modalidades. Por el contrario, como se usa en la presente, el término "sistema de cómputo" tiene la intención de incluir cualquiera y todos los dispositivos capaces de almacenar y procesar información y/o capaces de usar la información almacenada para controlar la conducta o la ejecución dei dispositivo en sí mismo, sin importar si dichos dispositivos son electrónicos, mecánicos, lógicos o virtuales por naturaleza. B. ALMACENAMIENTO TRADICIONAL BASADO EN ARCHIVOS En la mayoría de los sistemas de cómputo actualmente, los "archivos" son unidades de información que pueden incluir el sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación, así como programas de aplicación, conjuntos de datos, etc. En todos los sistemas de interfases de componentes físicos de computación/programas y sistemas de programación modernos (como Windows, Unix, Linux, SO Macintosh, sistemas de máquinas virtuales, etcétera), los archivos son unidades de información básica discretas (que pueden almacenarse y recuperarse), por ejemplo, datos, programas, entre otros que se pueden manipular a través del sistema de interfases de componentes físicos de computación/programas y sistemas de programación. Los grupos de archivos generalmente se organizan en "carpetas". En Microsoft Windows, en el sistema operativo de Macintosh, y otros sistemas de interfases de componentes físicos de computación/programas y sistemas de programación, una carpeta es una colección de archivos que se pueden recuperar, mover y de otra manera manipular como unidades únicas de información. Estas carpetas, a su vez, están organizadas en una disposición jerárquica basada en árbol denominada "directorio" (que se analiza con mayor detalle en la presente en párrafos posteriores). En algunos otros sistemas de interfases de componentes físicos de computación/programas y sistemas de programación, por ejemplo DOS, z/OS y la mayoría de los sistemas operativos que se basan en Unix, los términos "directorio" y/o "carpeta" son intercambiables, y en los primeros sistemas de cómputo Apple (por ejemplo, el sistema Apple lie) usaba el término "catálogo" en lugar de directorio; sin embargo, como se usa en la presente, todos estos términos se consideran sinónimos y son intercambiables y tienen la intención de incluir todos los términos equivalentes y las referencias a las estructuras de almacenamiento de información jerárquica y sus componentes de carpetas y archivos. Tradicionalmente, un directorio (es decir, un directorio de carpetas) es una estructura jerárquica que se basa en una estructura de árbol, en donde los archivos se agrupan en carpetas y la carpeta, en su momento, se disponen de conformidad con las ubicaciones nodales relativas que comprenden el árbol del directorio. Por ejemplo, como se ¡lustra en la figura 2A, una carpeta basada en un sistema de archivos que se basa en DOS (o "directorio de raíz") 212, puede comprender una pluralidad de carpetas 214, cada una de las cuales además puede comprender carpetas adicionales (como "subcarpetas" de esa carpeta particular) 216, y cada una de éstas también puede comprender carpetas adicionales 218 de manera infinita. Cada una de estas carpetas puede tener uno o más archivos 220, aunque, en el nivel de sistema de interfases de componentes físicos de computación/programas y sistemas de programación, los archivos individuales de una carpeta no tienen nada en común además de su ubicación en la jerarquía de árbol. No es de sorprenderse que este enfoque de organización de archivos en jerarquías de carpetas refleja de manera indirecta la organización física de los medios de almacenamiento típico que se usa para almacenar estos archivos (por ejemplo, discos duros, discos flexibles, CD-ROM, etc.). Además de lo anterior, cada carpeta es un contenedor de sus subcarpetas y sus archivos, esto es, cada carpeta contiene sus propias subcarpetas y archivos. Por ejemplo, cuando una carpeta se borra a través del sistema de interfases de componentes físicos de computación/programas y sistemas de programación, dichas subcarpetas de la carpeta y sus archivos también se borran (lo que, en el caso de cada subcarpeta, nada más incluye sus propias subcarpetas y archivos de manera recurrente). De igual manera, cada archivo pertenece generalmente sólo a una carpeta y, aunque un archivo se pueda copiar y la copia se ubique en una carpeta diferente, la copia de un archivo es en sí misma es una unidad diferente y separada que no tiene una conexión directa con el original (por ejemplo, los cambios en el archivo original no se reflejan en el archivo de copia y en el nivel del sistema de interfases de componentes físicos de computación/programas y sistemas de programación). A este respecto, los archivos y las carpetas por lo tanto son característicamente "físicos" por naturaleza, ya que las carpetas son los contenedores físicos y los archivos reciben un trato de elementos discretos físicos separados dentro de estos contenedores. II. UNA NUEVA PLATAFORMA DE ALMACENAMIENTO PARA ORGANIZAR, BUSCAR Y COMPARTIR DATOS La presente invención está dirigida a una plataforma de almacenamiento para organizar, buscar y compartir datos. La plataforma de almacenamiento de la presente invención extiende y amplía la plataforma de datos más allá de los sistemas de archivos existentes y los sistemas de bases de datos existentes que se analizaron en párrafos anteriores, y está diseñada para almacenar todo tipo de datos, incluyendo una nueva forma de datos denominados elementos. A. GLOSARIO Como se usa en la presente y en las reivindicaciones, los siguientes términos tienen los siguientes significados: Un "elemento" es una unidad de información que se puede almacenar a la que se puede tener acceso a través de un sistema de interfases de componentes físicos de computación/programas y sistemas de programación que, a diferencia de un archivo simple, es un objeto que tiene un conjunto básico de propiedades que están soportadas de manera común a través de todos los objetos expuestos a un usuario final a través de la cubierta del sistema de interfases de componentes físicos de computación/programas y sistemas de programación. Los elementos también tienen propiedades y relaciones que están soportadas comúnmente a través de todos los tipos de elementos que incluyen características que permiten la introducción de nuevas propiedades y relaciones (como se analiza con mayor detalle posteriormente en la presente). Un "sistema operativo" (OS) es un programa especial que actúa como un intermediario entre los programas de aplicación y los componentes físicos de la computadora. Un sistema operativo comprende, en la mayoría de los casos, una cubierta y un núcleo. Un "sistema de interfases de componentes físicos de computación/programas y sistemas de programación" es una combinación de componentes físicos de computación y programas y sistemas de programación que funciona como la interfase entre los componentes físicos de computación subyacentes de un sistema de cómputo y las aplicaciones que se ejecutan en el sistema de cómputo. Un sistema de interfases de componentes físicos de computación/programas y sistemas de programación comprenden típicamente (y, en algunas modalidades, únicamente pueden consistir en) un sistema operativo. Un sistema de interfases de componentes físicos de computación/programas y sistemas de programación también pueden comprender un administrador de máquina virtual (VMM), un tiempo de ejecución de lenguaje común (CLR) o su equivalente funcional, una máquina virtual Java (JVM) o su equivalente funcional, u otros componentes de programas y sistemas de programación en lugar de o además del sistema operativo en un sistema de cómputo. El objetivo de un sistema de interfases de los componentes físicos de computación y los programas y sistemas de programación es proveer un entorno en donde un usuario pueda ejecutar programas de aplicación. El objetivo de cualquier sistema de interfases de componentes físicos de computación/programas y sistemas de programación es hacer un uso cómodo del sistema de cómputo, así como utilizar los componentes físicos de cómputo de una manera eficiente. B. DESCRIPCIÓN GENERAL DE LA PLATAFORMA DE ALMACENAMIENTO Haciendo referencia a la figura 3, una plataforma de almacenamiento 300, de conformidad con la presente invención, comprende un almacén de datos 302 implementado en un motor de una base de datos 314. En una modalidad, el motor de la base de datos comprende un motor de base de datos de relación con extensiones relaciónales de objeto. En una modalidad, el motor 314 de la base de datos relacional comprende el motor de base de datos relacional del servidor SQL de Microsoft. El almacén de datos 302 implementa un modelo de datos 304 que da soporte a las acciones de organizar, buscar, compartir, sincronizar y proporcionar seguridad a los datos. Los tipos específicos de los datos se describen en esquemas, como los esquemas 340 y la plataforma de almacenamiento 300, proporcionan herramientas 346 para desplegar los esquemas así como para extender esos esquemas, como se describe con mayor detalle a continuación.

Un mecanismo de seguimiento de cambios 306 que se implementa dentro del almacén de datos 302 proporciona la capacidad de dar seguimiento a los cambios en el almacén de datos. El almacén de datos 302 también proporciona capacidades de seguridad 308 y una capacidad de ascenso/degradación 310, los cuales se analizan con mayor detalle a continuación. El almacén de datos 302 también proporciona un conjunto de interfaces de programación de aplicaciones 312 para exponer las capacidades del almacén de datos 302 a otros componentes de la plataforma de almacenamiento y programas de aplicación (por ejemplo, los programas de aplicación 350a, 350b y 350c) que utilizan la plataforma de almacenamiento. La plataforma de almacenamiento de la presente invención adicionalmente comprende interfases de programación de aplicaciones (API) 322, que habilitan los programas de aplicación, por ejemplo los programas de aplicación 350a, 350b y 350c, para acceder a todas las capacidades anteriores de la plataforma de almacenamiento y para acceder a los datos descritos en los esquemas. La API 322 de la plataforma de almacenamiento se puede usar a través de los programas de aplicación en combinación con otras API, por ejemplo la API de la BD OLE 324 y la API 326 de Win32 de Microsoft Windows. La plataforma de almacenamiento 300 de la presente invención puede proveer una variedad de servicios 328 a los programas de aplicación, incluyendo un servicio de sincronización 330 que facilita compartir los datos entre usuarios o sistemas. Por ejemplo el servicio de sincronización 330 puede habilitar la interoperabilidad con otros almacenes de datos 340 que tengan el mismo formato que el almacén de datos 302, así como acceder a almacenes de datos 342 que tienen otros formatos. La plataforma de almacenamiento 300 también proporciona capacidades del sistema de archivos que permiten la interoperabilidad del almacén de datos 302 con los sistemas de archivos existentes, por ejemplo el sistema de archivos NTFS de Windows 318. En al menos algunas modalidades, la plataforma de almacenamiento 320 también puede proporcionar programas de aplicación con capacidades adicionales para habilitar que los datos se cumplan y para habilitar la interacción con otros sistemas. Estas capacidades se pueden representar en la forma de servicios adicionales 328, por ejemplo un servicio de un agente de información 334 y un servicio de notificación 332, así como en la forma de otras utilidades 336. AI menos en algunas modalidades, la plataforma de almacenamiento se representa en, o forma una parte integral del sistema de interfases de componentes físicos de cómputo/programas y sistemas de programación de un sistema de cómputo. Por ejemplo, y sin limitante alguna, la plataforma de almacenamiento de la presente invención se puede representar o puede formar parte integral de un sistema operativo, un administrador de una máquina virtual (VMM), un tiempo de ejecución de lenguaje común (CLR) o su equivalente funcional, o una máquina virtual Java (JVM) o su equivalente funcional. A través de estos fundamentos del almacenamiento común y los datos esquematizados, la plataforma de almacenamiento de la presente invención habilita un desarrollo más eficiente de la aplicación para los clientes, trabajadores intelectuales y las empresas. Ofrece un área de superficie de programación rica y extensible que no sólo ofrece la disponibilidad de las capacidades inherentes a este modelo de datos, también involucra y extiende el sistema de archivos existentes y los métodos de acceso a la base de datos. En la descripción a continuación, así como en algunas figuras, la plataforma de almacenamiento 300 de la presente invención se puede denominar "WinFS". Sin embargo, el uso de este nombre para referirse a la plataforma de almacenamiento únicamente es por comodidad de la descripción y no tiene la intención de limitarla en ningún sentido C. MODELO DE DATOS El almacén de datos 302 de la plataforma de almacenamiento 300 de la presente invención ¡mplementa un modelo de datos que da soporte a la organización, búsqueda, asignación múltiple, sincronización y seguridad de los datos que residen en el almacén. En el modelo de datos de la presente invención, un "elemento" es la unidad fundamental de la información de almacenamiento. El modelo de datos proporciona un mecanismo para declarar elementos y extensiones de los elementos y para establecer relaciones entre los elementos y para organizar los elementos en las carpetas de elementos y en categorías, como se describe con mayor detalle a continuación. El modelo de datos depende de dos mecanismos primitivos, Tipo y Relaciones. Los tipos son estructuras que proveen un formato que rige la forma de un ejemplo del Tipo. El formato se expresa como un conjunto ordenado de Propiedades. Una propiedad es un nombre para un valor o conjunto de valores de un Tipo determinado. Por ejemplo, un tipo DirecciónPostalenEEUU debe tener las propiedades de Calle, Ciudad, Código postal, Estado, en donde la Calle, la Ciudad y el Estado son del Tipo de Cadena y el Código postal es del Tipo Int32. El valor para Calle puede tener múltiples valores (es decir, un conjunto de valores) lo que permite que la dirección tenga más de un valor para la propiedad Calle. El sistema define ciertos tipos primitivos que se pueden usar en la construcción de otros tipos, entre éstos se incluye Cadena, Binario, Booleano, I n 116 , Int32, Int64, Único, doble, Byte, FechaHora, Decimal y GUID. Las Propiedades de un Tipo se pueden definir usando cualquiera de los tipos primitivos o (con algunas restricciones que se observan a continuación) cualquiera de los tipos construidos. Por ejemplo, un Tipo Ubicación se puede definir que tiene Propiedades Coordenadas y Dirección en donde la Propiedad Dirección es del Tipo DirecciónPostalenEEUU como se describió anteriormente. Las propiedades también pueden ser requeridas, o bien, opcionales. Las relaciones pueden ser declaradas y representar una correlación entre los conjuntos de ejemplos de dos tipos. Por ejemplo, puede haber una Relación declarada entre el Tipo Persona y el Tipo Ubicación denominada ViveEn, lo que define las personas que habitan en qué ubicación. La Relación tiene un nombre, dos puntos de extremo, a saber un punto de extremo de origen y un punto de extremo objetivo. Las relaciones también pueden tener un conjunto ordenado de propiedades. Ambos puntos de extremo, de origen y objetivo, tienen un Nombre y un Tipo. Por ejemplo, la Relación ViveEn tiene un Origen denominado Ocupante del tipo Persona y un Objetivo denominado Morada del tipo Ubicación y además tiene propiedades como FechaDelnicio y FechaDeTérmino que indican el periodo durante el cual el ocupante habitó dicha morada. Observe que una Persona puede habitar diferentes moradas con el paso del tiempo y una morada puede tener múltiples ocupantes, de manera que el lugar más seguro para colocar la FechaDelnicio y la FechaDeTérmino es en la relación misma. Las relaciones definen una correlación entre los ejemplos que se obligan a través de los tipos determinados como los tipos de puntos de extremo. Por ejemplo, en la relación ViveEn no puede ser una relación en la que un Automóvil sea un Ocupante, debido a que un Automóvil no es una Persona. El modelo de datos permite la definición de una relación del subtipo-supertipo entre los tipos. La relación subtipo-supertipo también conocida como la relación TipoBase se define de una manera tal, que si el Tipo A es TipoBase para el Tipo B, será el caso en que todos los ejemplos de B también sean un ejemplo de A. Otra manera de expresar esto es que cada ejemplo que se ajusta a B debe también ajustarse a A. Si, por ejemplo, A tiene un Nombre de propiedad de Tipo Cadena mientras que B tiene una propiedad de Edad del Tipo I n 116 , lo que sigue es que cualquier ejemplo de B debe tener un Nombre y Edad. La jerarquía del tipo se puede concebir como un árbol con un solo supertipo en la raíz. Las ramas desde la raíz proporcionan subtipos de primer nivel, las ramas en este nivel proporcionan los subtipos de segundo nivel, etc. hacia los subtipos hacia los extremos que en sí mismos no tienen ningún subtipo. El árbol no tiene la restricción de tener una profundidad uniforme, ni tampoco puede contener ningún ciclo. Un Tipo determinado puede tener cero subtipos o varios subtipos y cero o un supertipo. Un ejemplo determinado puede ajustarse cuando mucho a un tipo junto con los supertipos de ese tipo. Para explicarlo de otra manera, para un ejemplo determinado en cualquier nivel en el árbol, el ejemplo puede ajustarse cuando mucho a un subtipo en ese nivel. Se dice que un tipo es Abstracto si los ejemplos del tipo también deben ser ejemplos de un subtipo del tipo. 1. Elementos Un elemento es una unidad de información que se puede almacenar que, a diferencia de un archivo simple, es un objeto que tiene un conjunto básico de propiedades que están soportadas comúnmente a través de todos los objetos expuestos para un usuario final o programa de aplicación mediante la plataforma de almacenamiento. Los elementos también tienen propiedades y relaciones que están soportadas comúnmente a través de todos los tipos de elementos que incluyen características que permiten la introducción de nuevas propiedades y relaciones, como se analiza posteriormente en la presente. Los elementos son los objetos para las operaciones comunes, por ejemplo copiar, eliminar, mover, abrir, imprimir, respaldar, restaurar, duplicar, etc. Los elementos son las unidades que se pueden almacenar y recuperar y todas las formas de información que se pueden almacenar manipuladas mediante la plataforma de almacenamiento que existen como Elementos, propiedades de Elementos o Relaciones entre los Elementos, cada uno de los cuales se analiza con mayor detalle en la presente a continuación. Los elementos tienen la intención de representar unidades de datos comprensibles fácilmente y del mundo real como Contactos, Personas, Servicios, Ubicaciones, Documentos (de todas las clases), etc. La figura 5A es un diagrama de bloques que ilustra la estructura de un elemento. El nombre no calificado del elemento es "ubicación". El nombre calificado del elemento es "Núcleo. Ubicación" que indica que esta estructura del elemento se define como un tipo específico del elemento en el Esquema Núcleo (el Esquema Núcleo se analiza con mayor detalle posteriormente en la presente). El Elemento Ubicación tiene una pluralidad de propiedades que incluyen DireccionesElectrónicas, RegiónMetropolitana, Entorno y DlreccionesPostales. El tipo específico de propiedad para cada uno se indica inmediatamente después del nombre de la propiedad y se separa del nombre de la propiedad mediante el signo de puntuación de dos puntos (":"). A la derecha del nombre del tipo, el número de valores permitidos para dicho tipo de propiedad se indica entre ("[ ]") en donde un asterisco ("*") a la derecha de los dos puntos (":") indica un número no especificado y/o no limitado ("muchos"). Un "1" a la derecha de los dos puntos indica que puede haber un valor como máximo. Un cero ("0") a la izquierda de los dos puntos indica que la propiedad es opcional (puede no haber ningún valor). Un "1" a la izquierda de los dos puntos indica que debe haber al menos un valor (se requiere la propiedad). Entorno y RegiónMetropolitana ambos son del tipo "nvarchar" (o su equivalente) que son tipo de datos predefinidos o "tipo simple" (y en la presente se denota por la falta de mayúsculas). Sin embargo, las propiedades DireccionesElectrónicas y Direccionespostales son de los tipos definidos o "tipos complejos" (como se observa en la presente por el uso de mayúsculas) de los tipos DirecciónElectrónica y DirecciónPostal, respectivamente. Un tipo complejo es el tipo que se deriva de uno o más tipos de datos simples y/o de otros tipos complejos. Los tipos complejos para las propiedades en un Elemento también constituyen "elementos anidados", ya que los detalles del tipo complejo se anidan en el Elemento inmediato para definir sus propiedades, y la información que pertenece a estos tipos complejos se mantiene con el Elemento que tiene estas propiedades (dentro de los limites del elemento, como se analiza posteriormente en la presente). Estos conceptos de clasificación ya se conocen y son evidentes para los expertos en la técnica. La figura 5B es un diagrama de bloques que ilustra los tipos de propiedad compleja DirecciónPostal y DirecciónElectrónica. El tipo de propiedad DirecciónPostal define que se puede esperar que un elemento del tipo de propiedad DirecciónPostal tenga valores de cero o uno para Ciudad, valores de cero o uno para CódigodePaís, valores de cero o uno para Dirección I nterna y cualquier número (de cero a muchos) de TiposdeDirecciónPostal, etc. De esta manera, se define en la presente la forma de los datos para una propiedad particular en un Elemento. El tipo de propiedad DirecciónElectrónica se define de manera similar como se muestra. Aunque se usa de manera opcional en esta solicitud, otra manera de representar los tipos complejos en el elemento Ubicación es extraer el elemento con las propiedades individuales de cada tipo complejo enumerado allí La figura 5 es un diagrama de bloques que ilustra el Elemento Ubicación en donde se describen adicionalmente los tipos complejos. Sin embargo, debe comprenderse que esta representación alternativa del Elemento Ubicación en esta figura 5C es para el Elemento exactamente igual que se ilustra en la figura 5A. La plataforma de almacenamiento de la presente invención también permite la subclasificación en donde un tipo de propiedad puede ser un subtipo de otro (en donde el tipo de propiedad hereda las propiedades de otro, como el tipo de propiedad de origen). Los elementos son similares pero diferentes en propiedades y sus tipos de propiedades, y representan de manera inherente sus propios Tipos de Elementos que también pueden ser sujetos de subclasificación. En otras palabras, la plataforma de almacenamiento en diversas modalidades de la presente invención permite que un Elemento sea un subtipo de otro elemento (en donde el Elemento hereda las propiedades de otro, del elemento origen). Adicionalmente, para diversas modalidades de la presente invención, cada Elemento es un subtipo del tipo de Elemento "Elemento" que es el primer tipo de elemento y fundamental encontrado en el Esquema Base (el Esquema Base también se analiza con detalle posteriormente en la presente). La figura 6A ilustra un Elemento, el Elemento Ubicación en este ejemplo, siendo un subtipo del tipo de Elemento Elemento que se encuentra en el Esquema Base. En esta figura, la flecha indica que el Elemento Ubicación (como todos los otros Elementos) es un subtipo de un tipo de Elemento Elemento. El tipo de Elemento Elemento, siendo el Elemento fundamental desde el cual se derivan todos los demás elementos, tiene un número de propiedades importantes como pueden ser una IddeElelemento y diversos RelojMarcador, y de esta manera define las propiedades estándar de todos los elementos en un sistema operativo. En esta figura, estas propiedades del tipo de Elemento Elemento las hereda de Ubicación y de esta manera se convierten en propiedades de Ubicación. Otra manera de representar las propiedades de elemento Ubicación heredadas del tipo de Elemento Elemento es extraer la Ubicación con las propiedades individuales de cada tipo de propiedad del Elemento de origen enumerado en éste. La figura 6B es un diagrama de bloques que ¡lustra el Elemento Ubicación en donde se describen sus tipos heredados además de sus propiedades inmediatas. Debe observarse y comprenderse que este Elemento es el mismo que se ilustra en la figura 5A, aunque en la figura actual Ubicación se ilustra con todas sus propiedades, tanto inmediatas, que se muestran tanto en esta figura como en la'figura 5A, como las heredadas, que se muestran en esta figura pero no en la figura 5 (mientras que en la figura 5 se hace referencia a otras propiedades mostrando con una flecha que el Elemento Ubicación es un subtipo del tipo de Elemento Elemento).

Los elementos son objetos autónomos; de esta manera, si elimina un elemento, todos los elementos inmediatos y las propiedades heredadas también se eliminan. De manera similar, cuando se recupera un elemento, lo que se recibe es el Elemento y todas sus propiedades inmediatas y heredadas (incluyendo la información que pertenece a sus tipos de propiedades complejas). Algunas modalidades de la presente invención pueden habilitar a alguien para que solicite un subconjunto de propiedades cuando recupera un Elemento específico; sin embargo, el valor predeterminado para muchas de estas modalidades es proveer un elemento con todas sus propiedades inmediatas y heredadas cuando se recupera. Además, las propiedades de los elementos también se pueden extender añadiendo nuevas propiedades de las propiedades existentes de ese tipo de elemento. Estas "extensiones" por lo tanto son propiedades genuinas del Elemento y los subtipos de ese tipo de Elemento automáticamente pueden incluir las propiedades de extensión. El "límite" del Elemento se representa a través de sus propiedades (incluyendo los tipos de propiedad compleja, las extensiones, etc.). Un límite de un elemento también representa el límite de una operación realizada en un Elemento por ejemplo copiar, borrar, mover, crear, etc. Por ejemplo, en algunas modalidades de la presente invención, cuando se copia un Elemento, todo lo que se encuentra dentro de los límites del elemento también se copia. Para cada elemento, el límite incluye lo siguiente: « El tipo Elemento del Elemento y, si el Elemento es un subtipo de otro Elemento (como es el caso en diversas modalidades de la presente invención en donde todos los Elementos se derivan de un solo Elemento y el Tipo Elemento en el Esquema Base), cualquier información del subtipo aplicable (esto es, información que pertenece al Tipo de Elemento origen). Si el Elemento original que se copia es un subtipo de otro Elemento, la copia también puede ser un subtipo del mismo Elemento. • Las propiedades del tipo complejo del Elemento y sus extensiones, si hubiere alguna. Si el Elemento original tiene propiedades de los tipos complejos (nativos o extendidos), la copia también debe tener los mismos tipos complejos. • Los registros del Elemento en "relaciones de propiedad", esto es, la propia lista del Elemento de los propios Elementos (los "Elementos Objeto") son propiedad del presente Elemento (el "Elemento Propietario"). Esto es particularmente pertinente con respecto a las Carpetas de Elementos, analizadas con mayor detalle a continuación, y la regla establecida a continuación de que todos los Elementos deben permanecer al menos a una Carpeta de Elementos. Adicionalmente, con respecto a los Elementos incrustados, analizados con mayor detalle a continuación, un elemento incrustado se considera parte del Elemento en el que está incrustado para las operaciones como copiar, borrar y similares. 2. Identificación de elementos Los Elementos se identifican de manera exclusiva dentro del espacio global de los elementos con una identificación del Elemento, ItemID (I DdeElemento). El tipo Base. Item (Base. Elemento) define un campo para la I DdeElemento, ItemID, de la GUID que almacena la identidad del Elemento. Un Elemento debe tener exactamente una identidad en el almacén de datos 302. a) Referencias de Elementos Una referencia del Elemento es una estructura de datos que contiene información para ubicar e identificar un Elemento. En el modelo de datos, un tipo abstracto se define denominado ItemReference, Referencia del Elemento, desde el cual se derivan todos los tipos de referencia del elemento. El tipo Itemreference define un método virtual denominado Resolve, Reso.lución. El método Resolve resuelve la ItemReference y devuelve un Item, Elemento. Este método se anula a través de los subtipos concretos de ItemReference, lo que implementa una función que recupera un Elemento dada una referencia. El método Resolve se invoca como parte de la API de plataforma de almacenamiento 322. (1) ItemIDReference (Referencia de identif icador del Elemento) ItemIDReference es un subtipo de ItemReference (Referencia del Elemento). Define un campo Locator (Ubicador) y un campo ItemID (Identificador del Elemento). El campo Locator menciona (es decir, identifica) un dominio para el elemento. Se procesa a través del método de resolución del ubicador que puede resolver el valor del ubicador en un dominio del elemento. El campo ItemID es del tipo de identificador del elemento. (2) ItemPathReference (Referencia del trayecto del elemento) ItemPathReference es una especialización de ItemReference que define un campo Locator (ubicador) y un campo Path (trayecto). El campo Locator identifica un dominio para el elemento. Se procesa a través del método de resolución del ubicador que puede resolver el valor del ubicador en un dominio del elemento. El campo Path contiene un trayecto (relativo) en el espacio del nombre de la plataforma de almacenamiento originado en el dominio del elemento provisto por el ubicador. Este tipo de referencia no se puede usar en una operación de configuración. La referencia generalmente se debe resolver a través de un proceso de resolución de trayecto. El método Resolve, resolución, de la API 322 de la plataforma de almacenamiento proporciona esta funcionalidad. b) Jerarquía del tipo de referencias Las formas de referencia analizadas en los párrafos anteriores se representan a través de la jerarquía del tipo de referencia que se ¡lustra en la figura 11. Los tipos de referencia adicionales que se heredan de estos tipos se pueden definir en los esquemas. Se pueden usar en una declaración de relación como el tipo del campo objetivo. 3. Carpetas y categorías del elemento Como se analiza con mayor detalle a continuación, los grupos de Elementos se pueden organizar en Elementos especiales denominados Carpetas de Elementos (que no deben confundirse con carpetas de archivos). Sin embargo, a diferencia de la mayoría de los sistemas de archivos, un Elemento puede pertenecer a más de una Carpeta de Elementos, de manera que cuando se accede a un Elemento en una Carpeta de Elementos y se revisa, entonces, se puede tener acceso a este Elemento revisado directamente desde otra Carpeta de Elementos. En esencia, aunque el acceso a un Elemento se puede producir desde diferentes Carpetas de Elementos, a lo que realmente se accede es al mismísimo Elemento. Sin embargo, una Carpeta de Elementos no necesariamente contiene todos sus Elementos miembros, o simplemente puede ser copropietaria de Elementos en conjunto con otras carpetas, de manera que la eliminación de una Carpeta de Elementos no necesariamente ocasiona la eliminación del Elemento. No obstante, en diversas modalidades de la presente invención, un Elemento debe pertenecer al menos a una Carpeta de elementos, de manera que si la sola Carpeta de Elemento para un Elemento particular se elimina, entonces, para algunas modalidades, el Elemento se elimina automáticamente o, en modalidades alternativas, el Elemento automáticamente se convierte en un miembro de una Carpeta de elementos predeterminada (por ejemplo, una Carpeta de Elementos "bandeja de reciclaje" que es conceptualmente similar a las carpetas nombradas de manera similar que se usan en diversos sistemas basados en archivos y carpetas). Como se analiza también con mayor detalle a continuación, los Elementos también pueden pertenecer a Categorías basadas en características comunes descritas como (a) un Tipo (o Tipos) de Elemento , (b) una propiedad (o propiedades) inmediata específica o heredada, o (c) un valor (o valores) específico que corresponden a una propiedad del Elemento. Por ejemplo, un Elemento que comprende propiedades específicas sobre información de contactos personales automáticamente puede pertenecer a una Categoría de Contactos y cualquier Elemento que tenga propiedades de información de contactos de igual manera automáticamente pertenece a esta categoría. De igual manera, cualquier Elemento que tenga una propiedad de ubicación con un valor de "Ciudad de Nueva York" puede pertenecer automáticamente a una categoría Ciudad de Nueva York. Las categorías son una forma diferente de las Carpetas de Elementos en que, mientras las Carpetas de Elementos pueden comprender Elementos que no están interrelacionados (es decir, sin una característica común descrita), cada elemento de una Categoría tiene un tipo común, una propiedad o un valor (una "convergencia") que se describe para esa Categoría, y es ésta la convergencia que forma la base para su relación y entre los otros Elementos en la Categoría. Adicional mente, mientras una membresía del Elemento en una Carpeta particular no se basa de manera obligatoria en ningún aspecto particular de ese Elemento, para ciertas modalidades todos los Elementos que tengan una convergencia relacionada categóricamente con una Categoría automáticamente se pueden convertir en un miembro de la Categoría en el nivel del sistema de interfases de componentes físicos de computación/programas y sistemas de programación. Conceptualmente, las Categorías también se pueden concebir como Carpetas de Elementos virtuales cuya membresía se basa en los resultados de una consulta específica (como en el contexto de una base de datos), y los Elementos que cumplen con las condiciones de esta consulta (definida por las convergencias de la Categoría) comprenderán la membresía de la Categoría. La figura 4 ilustra la relación estructural entre los Elementos, las Carpetas de Elementos y Categorías en varias modalidades de la presente invención. Una pluralidad de elementos 402, 404, 406, 408, 410, 412, 414, 416, 418 y 420 son miembros de diversas carpetas de elementos 422, 424, 426, 428 y 430. Algunos elementos pueden pertenecer a más de una Carpeta de Elementos, por ejemplo, el Elemento 402 pertenece a las Carpetas de Elementos 422 y 424. Algunos elementos, por ejemplo, el elemento 402, 404, 406, 408, 410 y 412 también son miembros de una o más Categorías 432, 434 y 436, mientras en otras ocasiones, por ejemplo los Elementos 414, 416, 418 y 420 puede no pertenecer a ninguna categoría (aunque esto es poco probable en algunas modalidades, en donde la posesión de cualquier propiedad automáticamente implica la membresía de una Categoría, y de esta manera un Elemento no tendría características por completo para que no fuera miembro de ninguna categoría en una modalidad tal). En contraste con la estructura jerárquica de las carpetas, tanto las Categorías como las Carpetas de Elementos tienen estructuras más similares a las gráficas dirigidas como se muestra. En cualquier evento, los Elementos, Carpetas de Elementos y Categorías todos son Elementos (aunque de diferentes Tipos de Elementos). En contraste con los archivos, carpetas y directorios, los Elementos, Carpetas de Elementos y Categorías de la presente invención no son característicamente "físicos" en naturaleza, debido a que no tienen equivalentes conceptuales de contenedores físicos, y por lo tanto los Elementos pueden existir en más de una ubicación. La capacidad de existencia de los elementos en más de una ubicación de Carpeta de Elementos, así como la organización en Categorías proporciona un grado mejorado y enriquecido para manipular datos y las capacidades de estructurar el almacenamiento en el nivel de las interfases de los componentes físicos/los programas y sistemas de programación, más allá de los disponible actualmente en la técnica. 4. Esquemas (a) Esquema Base Para proveer un fundamento universal para la creación y uso de Elementos, diversas modalidades de la plataforma de almacenamiento de la presente invención comprenden un Esquema Base que establece una estructura conceptual para crear y organizar Elementos y Propiedades. El esquema base define ciertos tipos especiales de Elementos y Propiedades, y las características de estos tipos fundamentales especiales desde los cuales se puede dividir adicionalmente los subtipos. El uso de este Esquema Base permite que un programador distinga conceptualmente a los Elementos (y sus tipos respectivos) de las Propiedades (y sus tipos respectivos). Adicionalmente, el Esquema Base establece el conjunto de fundamentos de las propiedades que todos los Elementos pueden poseer como todos los Elementos (y sus Tipos de Elementos correspondientes) se derivan de este Elemento fundamental en el Esquema Base (y su Tipo de Elemento correspondiente). Como se ilustra en la figura 7, y con respecto a diversas modalidades de la presente invención, el Esquema Base define tres tipos de nivel superior: Elemento, Extensión y Base de Propiedad. Como se muestra, el tipo de Elemento se define por las propiedades de este tipo de elemento "Elemento" fundamental. En contraste, el tipo de propiedad de nivel superior "PropertyBase" (base de propiedad) no tiene propiedades definidas previamente y es meramente el ancla desde la cual todos los tipos de propiedades se derivan a través de la cual todos los tipos de propiedades derivadas se interrelacionan (se derivan comúnmente del tipo de propiedad único). Las propiedades del tipo Extensión definen qué elemento extiende la extensión así como la identificación para distinguir una extensión de otra, ya que un elemento puede tener diversas extensiones. ItemFolder (CarpetadeElementos) es un subtipo del tipo de Elemento Elemento que, además de las propiedades heredadas del elemento, cuenta con una Relación para establecer enlaces con sus miembros (si tiene alguno), mientras que IdentityKey (Clavedeidentidad) y Property (Propiedad) son subtipos de PropertyBase (BasedePropiedad). En su momento, CategoryRef (ReferenciadeCategoría) es un subtipo de IdentitiKey. (b) Esquema Núcleo Diversas modalidades de la plataforma de almacenamiento de la presente invención además comprenden un Esquema Núcleo que proporciona una estructura conceptual para las estructuras de tipo de Elementos de nivel superior. La figura 8A es un diagrama de bloques que ilustra los Elementos en el Esquema Núcleo, y la figura 8B es un diagrama de bloques que ilustra los tipos de propiedad en el Esquema Núcleo. La distinción que se hace entre los archivos con diferentes extensiones (*.com, *.exe, *.bat, *sys, etc.) y otros criterios similares en los sistemas basados en archivo y carpetas es análogo a la función del Esquema Núcleo. En el sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación, el Esquema Núcleo define un conjunto de tipos de Elemento núcleo que, directamente (por Tipo de Elemento) o indirectamente (por Subtipo de Elemento), caracterizan todos los elementos en uno o más tipos de Elemento del Esquema Núcleo, lo que comprende el sistema de interfases de componentes físicos de computación/programas y sistemas de programación basados en elementos y puede procesar directamente de una manera predeterminada y predecible. Los tipos de Elementos predefinidos reflejan los Elementos más comunes en el sistema de interfases de componentes físicos de computación/programas y sistemas de programación basados en elementos y de esta manera se obtiene un nivel de eficiencia a través del sistema de interfases de elementos físicos de computación/programas y sistemas de programación basados en elementos comprendiendo estos tipos de Elementos predefinidos que comprende el Esquema Núcleo. En algunas modalidades, el Esquema Núcleo no puede extenderse, esto es, no se puede subdividir en tipos de Elementos adicionales directamente desde el tipo de Elemento en el Esquema Base, con excepción de los tipos de Elementos derivados predefinidos específicamente que son parte del Esquema Núcleo. Al evitar las extensiones en el Esquema Núcleo (es decir, al evitar la adición de nuevos Elementos al Esquema Núcleo), la plataforma de almacenamiento indica el uso de los tipos del Elemento de Esquema Núcleo, ya que cada tipo de Elemento subsiguiente es necesariamente un subtipo del tipo de Elemento de Esquema Núcleo. Esta estructura permite un grado razonable de flexibilidad en la definición de los tipos de elementos adicionales mientras que conserva los beneficios de tener un conjunto predefinido de tipos de elementos de núcleo. Para diversas modalidades de la presente invención, y haciendo referencia a la figura 8A, los tipos de elementos específicos soportados por el Esquema Núcleo pueden Incluir uno o más de lo siguiente: • Categorías: Elementos de este Tipo de Elemento (y los subtipos derivados de éste) representan las Categorías válidas en el sistema de interfases de componentes físicos de computación/programas y sistemas de programación basados en elementos. • Productos: Elementos que son cosas de valor identiflcable. · Dispositivos: Elementos que tienen una estructura lógica que soporta las capacidades de procesamiento de información . • Documentos: Elementos con contenido que no se interpreta a través del sistema de interfases de componentes físicos de computación/programas y sistemas de programación basados en elementos, en su lugar se interpretan a través de un programa de aplicaciones que corresponde al tipo de documento. • Eventos: Elementos que registran ciertas ocurrencias en el entorno. • Ubicaciones: Elementos que representan ubicaciones físicas (por ejemplo ubicaciones geográficas). • Mensajes: Elementos de comunicación entre dos o más elementos principales (definidos a continuación). · Elementos principales: Elementos que tienen al menos una identidad probable definitivamente además de un identif icador del elemento (por ejemplo, la identificación de una persona, organización, grupo, agrupación, autoridad, servicio, etc.). · Afirmaciones: Elementos que tiene información especial con respecto al entorno que incluye, sin limitarse a esto, políticas, suscripciones, referencias, etc. De igual manera, y haciendo referencia a la figura 8B, los tipos de propiedades específicos soportados por el Esquema Núcleo pueden incluir uno o más de lo siguiente: • Certificados (derivados del tipo fundamental PropertyBase (BasePropiedad) en el Esquema Base). • Claves de identidad de elemento principal (derivadas del tipo IdentitiKey (Clavedel dentidad) en el Esquema Base). · Dirección Postal (derivada del tipo Property (Propiedad) en el Esquema Base). • Texto enriquecido (derivado del tipo Property (Propiedad) en el Esquema Base). • Dirección Electrónica (derivada del tipo Property (Propiedad) en el Esquema Base). • IdentitySecurityPackage (PaquetedeSeguridaddeldentidad) (derivada del tipo Relationship (Relación) en el Esquema Base). • RoleOccupancy (OcupacióndeRol) (derivada del tipo Relationship (Relación) en el Esquema Base). • BasicPresence (PresenciaBásica) (derivada del tipo Relationship (Relación) en el Esquema Base). Estos Elementos y Propiedades se describen adicional mente mediante sus propiedades respectivas que se establecen en las figuras 8A y 8B. 5. Relaciones Las Relaciones son relaciones binarias en donde un Elemento está diseñado como origen y el otro elemento como objetivo. El Elemento origen y el Elemento objetivo están relacionados por la relación. El Elemento fuente generalmente controla el tiempo de vida útil de la relación. Es decir, cuando el Elemento fuente se elimina, la relación entre los Elementos también se elimina. Las Relaciones se clasifican en: Relaciones de Contención y de Referencia. Las relaciones de Contención controlan el tiempo de vida útil de los Elementos objetivo, mientras las relaciones de Referencia no proporcionan ninguna semántica de administración del tiempo de vida útil. La figura 12 ilustra la manera en que se clasifican las relaciones. Los tipos de relación de Contención además se clasifican en relaciones de Propiedad e Incrustación. Cuando todas las relaciones de Propiedad en un Elemento se retiran, el Elemento se elimina. Una relación de propiedad controla el tiempo de vida útil del objetivo a través de un mecanismo de conteo de referencia. Las relaciones de incrustación permiten modelar los Elementos compuestos y se puede concebir como relaciones de propiedad exclusiva. Un Elemento puede ser un objetivo de una o más relaciones de propiedad; pero un elemento puede ser el objetivo de exactamente una relación de incrustación. Un elemento que es un objetivo de una relación de incrustación no puede ser un objetivo de ninguna otra relación de propiedad o incrustación. Las relaciones de Referencia no controlan el tiempo de vida útil del Elemento objetivo. Pueden estar pendientes, el elemento objetivo puede no existir. Las relaciones de referencia se pueden usar para modelar referencias para los elementos en cualquier momento en el espacio de nombre del Elemento global (es decir, incluyendo almacenes de datos remotos). La búsqueda de un elemento no atrae automáticamente su relación. Las aplicaciones deben solicitar explícitamente las relaciones de un Elemento. Además, la modificación de una relación no modifica el Elemento origen u objetivo; de manera similar, la adición de una relación no afecta el Elemento de origen/objetivo. a) Relación de declaración Los tipos de relaciones explícitas se definen con los siguientes elementos: • Un nombre de relación se especifica en el atributo ame (Nombre). • El tipo de relación es uno de los siguientes: Propiedad, Incrustación, Referencia. Esto se especifica en el atributo Type (Tipo). • Puntos de extremo de origen y objetivo. Cada punto de extremo especifica un nombre y el tipo del Elemento al que hace referencia. • En el campo del punto de extremo de origen generalmente del tipo ItemlD (I DdelElemento) (no declarado) y debe hacer referencia a un Elemento en el mismo almacén de datos como el ejemplo de relación. • Para las relaciones de Propiedad e Incrustación, el campo del punto de extremo objetivo debe ser del tipo ItemIDReference (Referenciadel DdelElmento) y debe hacer referencia a un elemento en el mismo almacén como en el ejemplo de relación. Para las relaciones de Referencia el punto de extremo objetivo puede ser de cualquier tipo ItemReference (ReferenicadelElemento) y puede hacer referencia a los Elementos en otros almacenes de datos de la plataforma de almacenamiento. • Opcionalmente uno o más campos de un tipo escalar o PropertyBase (BasedelaPropiedad) se pueden declarar. Estos campos pueden contener los datos asociados con la relación. • Los ejemplos de una relación se almacenan en una tabla de relaciones global. • Todos los ejemplos de relaciones se identifican de manera exclusiva mediante la combinación (identificador del elemento de origen, identificador de la relación). El identificador de la relación es único dentro de un identificador del elemento de origen determinado para toda las relaciones que se originan en un Elemento determinado sin importar su tipo. El Elemento fuente es el propietario de la relación.

Aunque un Elemento diseñado como el propietario controla el tipo de vida útil de la relación, la relación en sí misma está separada de los Elementos a los que se refiere. La API 322 de la plataforma de almacenamiento proporciona mecanismos para exponer las relaciones asociadas con un Elemento. A continuación se da un ejemplo de una declaración de relación: <Relations ip Name = "Employment" BaseType = "Reference" > <Source Name = "Employee" ltemType = "Contact. Person"/> <Target ame = " Employer" ltemType = "Contact.Organization" Refere nceType = "l temí D Refere nce"/> <Property Name = "StartDate" Type = "the storage platformTypes. Da teTi me "/> <Property Name = "EndDate" Type = "the storage platformTypes. DateT i me"/> <Property Name = "Office" Type = "the storage platformTypes.DateT¡me"/> </Relationshi p> Éste es un ejemplo de una relación Reference (de Referencia): La relación no se puede crear si el Elemento persona al que se hace referencia a través de la referencia fuente no existe. De igual manera, si el Elemento persona se borra, los ejemplos de la relación entre la persona y la organización se borran. Sin embargo, si el Elemento Organización se elimina, la relación no se elimina y queda pendiente. b) Relación de propiedad Las relaciones de Propiedad se usan para modelar una cuenta de referencia con base en la administración del tiempo de vida útil de los Elementos objetivo. Un Elemento puede ser un punto de extremo de origen para cero o más relaciones para los Elementos. Un Elemento que no es un Elemento incrustado puede ser un objetivo en una o más relaciones de propiedad. El tipo de referencia del punto de extremo de objetivo debe ser ItemIDReference (ReferenciadelDdelElemento) y debe hacer referencia a un Elemento en el mismo almacén que el ejemplo de la relación. Las relaciones de propiedad refuerzan la gestión del tiempo de vida útil del punto de extremo objetivo. La creación de un ejemplo de una relación de propiedad y el elemento al que se dirige es una operación atómica. Se pueden crear ejemplos adicionales de la relación de propiedad que se dirigen al mismo elemento. Cuando se borra el último ejemplo de relación de propiedad con un Elemento determinado como el punto de extremo objetivo, el Elemento objetivo también se borra. Los tipos de los Elementos del punto de extremo especificados en la relación de declaración generalmente se refuerzan cuando se crea un ejemplo de la relación. Los tipos de los Elementos de los puntos de extremo no se pueden cambiar después de que se ha establecido la relación. Las relaciones de propiedad juegan un papel clave en la formación del espacio de nombre del Elemento. Contienen la propiedad "Ñame" (Nombre) que define el nombre del Elemento objetivo con relación al Elemento de origen. Este nombre relativo es único para todas las relaciones de propiedad originadas desde un Elemento determinado. En la lista ordenada de estos nombres relativos iniciando desde el Elemento de raíz hacia un Elemento determinado se forma el nombre completo para el Elemento. Las relaciones de propiedad forman una gráfica acíclica dirigida (DAG). Cuando una relación de propiedad se crea el sistema se asegura que no se crea un ciclo, de esta manera se asegura de que el espacio de nombre del Elemento forma una DAG. Aunque la relación de propiedad controla el tiempo de vida útil del elemento objetivo, no controla la consistencia operativa del Elemento del punto de extremo objetivo. El elemento objetivo es independiente operativamente del Elemento que lo contiene a través de la relación de propiedad. Las operaciones de copiar, mover, hacer un respaldo además de otras para un elemento que es el origen de una relación de propiedad no afectan al elemento que es un objetivo de la misma relación; por ejemplo, esto es, respaldar un Elemento de Carpeta no respalda automáticamente todos los elementos dentro de la carpeta (los objetivos de la relación FolderMember (Miembro sdelaCarpeta). A continuación se da un ejemplo de una relación de propiedad : <Relationship Name = "FolderMembers" BaseType = "HoIding"> <Source Name="Folder" ltemType = "Base. FoIder"/> <Target Name = "ltem" ltemType = "Base. Item" ReferenceType = " Item I D Refere nce"/> </Relationship> La relación FolderMember (MiembrosdelaCarpeta) habilita el concepto de una Carpeta como una colección genérica de Elementos. c) Relaciones de incrustación Las relaciones de incrustación modelan el concepto de control exclusivo del tiempo de vida útil del elemento objetivo. Habilitan el concepto de Elementos compuestos. La creación de un ejemplo de una relación de incrustación y el Elemento al que se dirige es una operación atómica. El elemento puede ser una fuente de cero o más relaciones de incrustación. Sin embargo, un Elemento puede ser un objetivo de una y sólo una relación de incrustación. Un Elemento que es un objetivo de una relación de incrustación no puede ser un objetivo de una relación de propiedad. El tipo de referencia del punto de extremo de objetivo debe ser Iteml DReference (ReferenciadeIDdelElemento) y debe hacer referencia a un Elemento en el mismo almacén de datos que el ejemplo de la relación. Los tipos de los Elementos del punto de extremo especificados en la relación de declaración generalmente se refuerzan cuando se crea un ejemplo de la relación. Los tipos de los Elementos de los puntos de extremo no se pueden cambiar después de que se ha establecido la relación. Las relaciones de incrustación controlan la consistencia operativa del punto de extremo objetivo. Por ejemplo, la operación seriar un elemento puede incluir seriar todas las relaciones de incrustación que tienen como origen ese elemento, así como todos sus objetivos; el copiado de un elemento también copia todos sus elementos incrustados. A continuación se da un ejemplo de declaración: <Relationship Name = "ArchiveMembers" BaseType="Embedding"> <Source Name = "Archive" ltemType = "Zip. Archive"/> <Target Name = "Member" ltemType = "Base. Item " Ref eren ceType = " Iteml DRef eren ce"/> <Property Name = "ZipSize" Type = "the storage platformTypes.bigint"/> <Property Name = "SizeReduction" Type = "the storage platformTypes.float'7> </Relationship> d) Relaciones de referencia La relación de referencia no controla el tiempo de vida útil del Elemento al que hace referencia. Incluso, las relaciones de referencia no garantizan la existencia del objetivo, tampoco garantizan el tipo del objetivo como se especifica en la declaración de relación. Esto significa que las relaciones de referencia pueden quedar pendientes. De igual manera, la relación de referencia puede hacer referencia a los Elementos en otros almacenes de datos. Las relaciones de referencia también se pueden concebir como conceptos similares a enlaces en páginas de redes informáticas. Un ejemplo de una declaración de relación de referencia es la que se indica a continuación: <Relationship Name = "DocumentAuthor" BaseType = "Reference"> <Source ltemType = "Document" ltemType = "Base.Document'7> <Target ltemType = "Author" ltemType = "Base.Author" ReferenceType = "ltemlDReference"/> <Property Type = "Role" Type = "Core.CategoryRef'7> <Property Type = "DisplayName" Type = "the storage platformTypes.nvarchar(256)"/> </Relationship> En el punto de extremo objetivo se permite cualquier tipo de referencia. Los Elementos que participan en una relación de referencia pueden ser de cualquier tipo de Elemento. Las relaciones de referencia se usan para modelar la mayoría de las relaciones de gestión que no son del tiempo de vida útil entre los Elementos. Debido a que la existencia del objetivo no se refuerza, la relación de referencia es conveniente para modelar relaciones relacionadas de manera suelta. La relación de referencia se puede usar para dirigirse a elementos de otros almacenes de datos, incluyendo almacenes en otras computadoras. e) Reglas y restricciones Las siguientes reglas y restricciones adicionales aplican a las relaciones: 1. Un elemento debe ser un objetivo de (exactamente una relación de incrustación) o (una o más relaciones de propiedad). Una excepción es el elemento de raíz. El elemento puede ser un objetivo de cero o más relaciones de referencia. 2. Un elemento que es un objetivo de una relación de incrustación no puede ser el origen de las relaciones de propiedad.. Puede ser el origen de relaciones de referencia. 3. Un elemento no puede ser un origen de una relación de propiedad si se promueve desde un archivo. Puede ser el origen de relaciones de incrustación y relaciones de referencia. 4. Un elemento que se promueve desde un archivo no puede ser un objetivo de una relación de incrustación. f) Orden de las relaciones En al menos una modalidad, la plataforma de almacenamiento de la presente invención soporta ordenar las relaciones. El orden se logra a través de una propiedad denominada "Orden" en la definición de relación base. No hay una restricción única en el campo Order (Orden). El orden de las relaciones con el mismo valor de propiedad "Order" no está garantizado, sin embargo, se garantiza que estarán ordenadas después las relaciones con un valor de orden inferior y antes las relaciones con un valor en el campo "Order" superior. Las aplicaciones pueden obtener las relaciones en el orden predeterminado al ordenar con base en la combinación (SourceltemID, RelationshipID, Order) (IDdelElementoFuente, IDdelaRelación, Orden). Todos los ejemplos de relación que provienen de un Elemento determinado se ordenan como una colección única sin importar el tipo de las relaciones en la colección. Sin embargo, esto garantiza que todas las relaciones de un tipo determinado (por ejemplo, Folder ember MiembrosdelaCarpeta)) son un subconjunto ordenado de la colección de relaciones para un elemento determinado. La API 312 del almacén de datos para manipular las relaciones implementa un conjunto de operaciones que soportan el orden de las relaciones. Los siguientes términos se introducen para ayudar a explicar las operaciones: RelFirst es la primera relación en la colección ordenada con un valor de orden OrdFirst; RelLast es la última relación en la colección ordenada con un valor de orden OrdLast; RelX es una relación determinada en la colección con un valor de orden OrdX; RelPrev es una relación más cercana en la colección al valor RelX con un valor de orden OrdPrev más pequeño que OrdX; y ReINExt es una relación más cercana en la colección al valor RelX con un valor de orden OrdNext mayor que OrdX. InsertBef oreFirst (So urce Item I D, Relationship) Inserta la relación como la primera relación en la colección. El valor de la propiedad "Order" (Orden) de la nueva relación puede ser menor que OrdFirst. lnsertAfterLast(Sourcelteml D, Relationshlp) Inserta la relación como la última relación en la colección. El valor de la propiedad "Order" (Orden) de la nueva relación puede ser mayor que OrdLast. lnsertAt(SourceltemlD, ord, Relatlonship) Inserta una relación con el valor especificado para la propiedad "Order". lnsertBefore(SourceltemlD, ord, Relationship) Inserta la relación antes de la relación con el valor de orden determinado. La nueva relación se puede asignar con un valor de "Order" que está entre OrdPrev y ord no global. InsertAfter (SourceltemID, ord, Relationship) Inserta la relación después de la relación con el valor de orden determinado. La nueva relación se puede asignar con un valor de "Order" que está entre ord y OrdNext, no global. MoveBefore(SourceltemlD, ord, RelationshipID) Mueve la relación con el ID de la relación determinada antes de la relación con el valor de "Order" especificado. Se puede asignar un nuevo valor de "Order" a la relación, el cual está entre OrdPrev y ord, no global. MoveAfter(SourceltemlD, ord, RelationshipID) Mueve la relación con el ID de la relación determinada después de la relación con el valor de "Order" especificado. Se puede asignar un nuevo valor de orden a la relación, el cual está entre ord y OrdNext, no global. Como se mencionó anteriormente, cada Elemento debe ser parte de una Carpeta de Elementos. En términos de Relaciones, cada Elemento debe tener una relación con una Carpeta de Elementos. En diversas modalidades de la presente invención, ciertas relaciones se representan mediante las Relaciones que existen entre los Elementos. Como se implemento para diversas modalidades de la presente invención, una Relación proporciona una relación binaria dirigida que se "extiende" en un elemento (el origen) a otro elemento (el objetivo). Una relación pertenece a un Elemento de origen (el Elemento que lo extendió) y de esta manera la Relación se elimina si el origen se elimina (por ejemplo, la Relación se elimina cuando el elemento de origen se elimina). Adicionalmente, en algunos casos, una Relación puede compartir la propiedad (ser copropietario) del Elemento objetivo, y de esta manera la propiedad se puede reflejar en la propiedad IsOwned (o su equivalente) de la Relación (como se muestra en la figura 7 para el tipo de propiedad Relationship). En estas modalidades, la creación de una nueva Relación IsOwned automáticamente incrementa un conteo de referencia en el Elemento objetivo, y la eliminación de dicha Relación puede disminuir el conteo de referencia en el Elemento objetivo. Para estas modalidades específicas, los elementos siguen existiendo si tienen un conteo de referencia mayor que cero, y automáticamente se eliminan cuando el conteo llega a cero. Nuevamente, una Carpeta de Elemento es un Elemento que tiene (o es capaz de tener) un conjunto de Relaciones con otros elementos, estos otros Elementos comprenden la membresía de la Carpeta de Elementos. Otras implementaciones reales de , Relaciones son posibles y- se prevén mediante la presente invención para lograr la funcionalidad descrita en la presente. Sin tomar en cuenta la implementación real, una Relación es una colección que se puede seleccionar de un objeto a otro. La capacidad de un Elemento para pertenecer a más de una Carpeta de Elementos, así como una o más Categorías, y si estos Elementos, Carpetas y Categorías son públicas o privadas, se determina mediante los significados otorgados a la existencia (o falta) en una estructura basada en Elementos. Estas Relaciones lógicas son los significados asignados a un conjunto de Relaciones, sin importar la implementación física, las cuales se emplean específicamente para lograr la funcionalidad descrita en la presente. Las relaciones lógicas se establecen entre el Elemento y sus Carpetas de Elementos o Categorías (y viceversa) debido a que, en esencia, las Carpetas de Elementos y sus Categorías cada una son de un tipo especial de Elemento. En consecuencia, las Carpetas de Elementos y sus Categorías pueden actuar de la misma manera que cualquier otro elemento, copiarse, añadirse a un mensaje de correo electrónico, incrustarse en un documento, etc. sin limitarse, y las Carpetas de Elementos y las Categorías se pueden serializar y retirar la señalización (importarse y exportarse) usando el mismo mecanismo que para otros elementos (por ejemplo, en XML todos los Elementos pueden tener un formato de señalización, y este formato aplica de igual manera a Carpetas de Elementos, Categorías y Elementos). Las relaciones mencionadas anteriormente, que representan la relación entre un Elemento y una Carpeta de Elementos puede extenderse de manera lógica desde el Elemento hacia la Carpeta de Elementos, desde la Carpeta de Elementos hacia el Elemento, o ambos. Una relación que se extiende lógicamente desde un Elemento hacia una Carpeta de Elementos denota que la Carpeta de Elemento es pública para ese Elemento y comparte su información de membresía con ese Elemento, por el contrario, la falta de una Relación lógica de un Elemento con una Carpeta de Elementos denota que la Carpeta de Elementos es privada para ese Elemento y no comparte su información de membresía con ese Elemento. De manera similar, una Relación que se extiende lógicamente desde una Carpeta de Elementos hacia un Elemento denota que el Elemento es público y puede compartir con esa Carpeta de Elementos, mientras que la falta de una Relación lógica de la Carpeta de Elementos hacia el Elemento denota que el Elemento es privado y no se puede compartir. En consecuencia, cuando una Carpeta de Elementos se exporta a otro sistema, los Elementos "públicos" que están compartidos en el nuevo contexto, y cuando un Elemento busca sus Carpetas de Elementos para otros Elementos que pueden ser compartidos, las Carpetas de Elementos "públicos" son las que proveen el Elemento con información respecto a los Elementos que pueden compartir y que pertenecen a ésta. La figura 9 es un diagrama de bloques que ¡lustra una Carpeta de Elementos (la cual, nuevamente, es un Elemento), sus Elementos miembros y las Relaciones de interconexión entre la Carpeta de Elementos y sus Elementos miembros; La carpeta de elementos 900 tiene como miembros una pluralidad de elementos 902, 904 y 906. La carpeta de elementos 900 tiene una Relación 912 desde sí misma con el Elemento 902, lo que denota que el Elemento 902 es público y puede compartirse con la Carpeta de Elementos 900, sus miembros 904 y 906, y cualesquiera otras Carpetas de Elementos, Categorías o Elementos (no se muestran) que puedan acceder a la Carpeta de Elementos 900. Sin embargo, no hay relación del Elemento 902 con la Carpeta de Elementos 900, lo que denota que la Carpeta de Elementos 900 es privada para el Elemento 902 y que no comparte su información de membresía con el Elemento 902. El Elemento 904, por otro lado, tiene una Relación 924 desde sí mismo con la Carpeta de Elementos 900, lo que denota que la Carpeta de Elementos 900 es pública y comparte su información de membresía con el Elemento 904. Sin embargo, no hay una relación de la Carpeta de Elementos 900 con el Elemento 904 que denota que el Elemento 904 es privado y no puede compartir con la Carpeta de Elementos 900, sus otros miembros 902 y 906 y cualesquiera otras Carpetas de Elementos, Categorías y Elementos (no se muestran) que puedan acceder a la Carpeta de Elementos 900. En contraste con sus Relaciones (o falta de éstas) con los Elementos 902 y 904, la Carpeta de Elementos 900 tiene una Relación 916 desde sí misma con el elemento 906 y el elemento 906 tiene una relación 926 hacia la Carpeta de Elementos 900, lo que en conjunto denota que el Elemento 906 es público y puede compartir con la Carpeta de Elementos 900, sus miembros 902 y 904, y cualesquiera otras Carpetas de Elementos, Categorías o Elementos (no se muestran) que puedan tener acceso a la Carpeta de Elementos 900, y que la Carpeta de Elementos 900 es pública y comparte su información de membresía con el Elemento 906. Como se analizó anteriormente, los Elementos de una Carpeta de Elementos no necesitan compartir una convergencia debido a que las Carpetas de Elementos no se "describen". Por otro lado, las Categorías se describen a través de una convergencia que es común para todos los Elementos miembro. En consecuencia, la membresía de una Categoría se limita de manera inherente a los Elementos que tienen la convergencia descrita y, en algunas modalidades, todos los Elementos que cubren la descripción de una Categoría se hacen miembros automáticamente de la Categoría. De esta manera, mientras las Carpetas de Elementos permiten que las estructuras de tipo trivial se representen a través de sus membresías, las Categorías permiten las membresías basadas en las convergencias definidas. Desde luego las descripciones de las Categorías son lógicas por naturaleza, y por lo tanto, una Categoría se puede describir a través de cualquier representación lógica de tipos, propiedades y/o valores. Por ejemplo, una representación lógica de una Categoría puede ser su membresía que comprende los Elementos que tienen una de dos propiedades, o ambas. Si esas propiedades descritas para la Categoría son "A" y "B", entonces la membresía de las Categorías puede comprender Elementos que tienen la propiedad A, pero no la propiedad B, los Elementos que tienen la propiedad B pero no la A, y los Elementos que tienen ambas propiedades A y B. Esta representación lógica de propiedades se describe mediante el operador lógico "OR" (O) en donde el conjunto de miembros descritos por la Categoría son elementos que tienen una propiedad A OR B. Los operadores lógicos similares (incluyendo sin limitarse "A D" (Y), "XOR" (XO), y " N O T " (NO) solos o en combinación) también se puede usar para describir una categoría como será evidente para los expertos en la técnica. A pesar de las distinción entre las Carpetas de Elementos (no descritas) y las Categorías (descritas), la Relación de las Categorías con los Elementos y la Relación de Elementos con las Categorías esencialmente son de la misma manera como se describió anteriormente en la presente para las Carpetas de Elementos y los Elementos en muchas modalidades de la presente invención. La figura 10 es un diagrama de bloques que ilustra una Categoría (la cual, nuevamente, es un Elemento en sí mismo), sus Elementos miembros y las Relaciones de interconexión entre la Categoría y sus Elementos miembro. La Categoría 1000 tiene como miembros una pluralidad de Elementos 1002, 1004 y 1006, todos los cuales comparten alguna combinación de propiedades, valores o tipos 1008 comunes como se describió (descripción de convergencias 1008') mediante la Categoría 1000. La Categoría 1000 tiene una Relación 1012 desde sí misma con el Elemento 1002, lo que denota que el Elemento 1002 es público y puede compartirse con la Categoría 1000, sus miembros 1004 y 1006, y cualesquiera otras Categorías, Carpetas de Elementos o Elementos (no se muestran) que puedan acceder a la Categoría 1000. Sin embargo, no hay relación del Elemento 1002 con la Categoría 1000, lo que denota que la Categoría 1000 es privada para el Elemento 1002 y que no comparte su información de membresía con el Elemento 1002. El Elemento 1004, por otro lado, tiene una Relación 1024 desde sí mismo con la Categoría 1000, lo que denota que la Categoría 1000 es pública y comparte su información de membresía con el Elemento 1004. Sin embargo, no hay una relación extendida de la Categoría 1000 con el Elemento 1004, lo que denota que el Elemento 1004 es privado y no puede compartir con la Categoría 1000, sus otros miembros 1002 y 1006 y cualesquiera otras Categorías Carpetas de Elementos o Elementos (no se muestran) que puedan acceder a la Categoría 1000. En contraste con sus Relaciones (o falta de éstas) con los Elementos 1002 y 1004, la Categoría 1000 tiene una Relación 1016 desde sí misma con el Elemento 1006 y el Elemento 1006 tiene una Relación 1026 hacia la Categoría 1000, lo que en conjunto denota que el Elemento 1006 es público y puede compartir con la Categoría 1000, sus miembros 1002 y 1004, y cualesquiera otras Categorías, Carpetas de Elementos, o Elementos (no se muestran) que puedan tener acceso a la Categoría 1000, y que la Categoría 1000 es pública y comparte su información de membresía con el Elemento 1006. Finalmente, debido a que las Categorías y las Carpetas de Elementos son Elementos en sí mismos y los Elementos pueden relacionarse entre sí, las Categorías pueden relacionarse con las Carpetas de Elementos y viceversa, y las Categorías, Carpetas de Elementos y Elementos pueden relacionarse con otras Categorías, Carpetas de Elementos y Elementos respectivamente en ciertas modalidades alternativas. Sin embargo, en diversas modalidades, las estructuras de las Carpetas de Elementos y/o las estructuras de Categorías están prohibidas, en el nivel del sistema de interfases de componentes físicos de cómputo/programas y sistemas de programación, para contener ciclos. En donde la Carpeta de Elementos y las estructuras de Categorías son similares a las gráficas dirigidas, las modalidades que prohiben los ciclos son similares a las gráficas acíclicas dirigidas (DAG) que, a través de una definición matemática en la técnica de la teoría gráfica, son gráficas dirigidas en donde ningún trayecto inicia o termina en el mismo vértice. 6. Capacidad de extensión La plataforma de almacenamiento se creo para proveer un conjunto inicial de esquemas 340 como se describió en párrafos anteriores. Sin embargo, al menos en algunas modalidades, la plataforma de almacenamiento permite que los clientes, incluyendo a los vendedores de programas y sistemas de programación independientes (ISV), creen nuevos esquemas 344 (es decir, nuevos tipos de elementos y elementos anidados). Esta sección se dirige a los mecanismos para crear dichos esquemas al extender los tipos de elementos y los tipos de elementos anidados (o simplemente tipos "Elementos") definidos en el conjunto inicial de esquemas 340. Preferiblemente, la extensión del conjunto inicial de los tipos Elemento y Elemento anidado se restringe como se indica a continuación: Se permite que un ISV introduzca nuevos tipos de Elementos, es decir el subtipo Base. Item; Se permite que un ISV introduzca nuevos tipos de Elementos Anidados, es decir el subtipo Base.NestedElement; Se permite que un ISV introduzca nuevas extensiones, es decir el subtipo Base.NestedElement; pero, Un ISV no puede subdividir ninguno de los tipos (tipos Elemento, ElementoAnidado o Extensión) definidos por el conjunto inicial de los esquemas 340 de la plataforma de almacenamiento.

Debido a que es posible que un tipo Elemento o tipo ElementoAnidado definido por el conjunto inicial de los esquemas de la plataforma de almacenamiento no corresponda exactamente a la necesidad de una aplicación ISV, es necesario permitir que las ISV personalicen el tipo. Esto se permite conociendo las Extensiones. Las extensiones son ejemplos clasificados sólidamente, pero (a) no pueden existir de manera independiente y (b) deben anexarse a un Elemento o a un ElementoAnidado. Además de resolver la necesidad de la capacidad de extensión de los esquemas, las Extensiones también se crearon para resolver la situación de "clasificaciones múltiples". Debido a que, en algunas modalidades, es posible que la plataforma de almacenamiento no soporte múltiples subtipos de herencia o traslapos, las aplicaciones pueden usar Extensiones como una manera para modelar los ejemplos de tipos traslapantes (por ejemplo, un documento es un documento legal así como un documento seguro). a) Extensiones del elemento Para proveer una capacidad de extensión al elemento, el modelo de datos además define un tipo abstracto denominado Base. Extensión. Es un tipo de raíz para la jerarquía de tipos de extensión. Las aplicaciones pueden tener un subtipo Base. Extensión para crear los tipos de extensión específicos.

El tipo Base. Extensión se define en el esquema Base como se indica a continuación: <Type Name = "Base. Extensión" lsAbstract="True"> <Propety Name = "ltemlD" Type = "the storage platformTypes.uniqueidentified" Nullable = "false" Mult¡Valued = "false'7> <Property Name = "Extensionl D" Type = "the storage platformTypes.uniqueidentified" Nullable = "false" MultiValued = "false"/> </Type> El campo ItemID contiene el identificador del elemento con el que se asocia la extensión. Debe existir un elemento con este identificador de elemento. La extensión no se puede crear si el elemento con identificador del elemento determinado no existe. Cuando el elemento se elimina, todas las extensiones que tienen el mismo identificador de elemento se eliminan. La tupia (ItemID (IDdelElemento), ExtensionlD (IddelaExtensión) identifica de manera exclusiva un ejemplo de extensión). La estructura de un tipo de extensión es similar a la de un tipo de elemento: Los tipos Extensión tienen campos; Los campos pueden ser de tipos de elemento primitivo o anidado; y los tipos Extensión pueden tener subtipos. Las siguientes restricciones aplican a los tipos de extensión: Las Extensiones no pueden ser origen y objetivo de una relación; Los ejemplos del topo Extensión no existen de manera independiente de un elemento y Los tipos Extensión no se pueden usar como tipos de campo en las definiciones del tipo de plataforma de almacenamiento. No hay restricciones sobre los tipos de extensiones que se pueden asociar con un tipo de elemento determinado. Se permite que cualquier tipo de extensión extienda cualquier tipo de elemento. Cuando se anexan múltiples ejemplos de extensión a un elemento, son independientes entre sí tanto en estructura como en comportamiento. Los ejemplos de extensión se almacenan y se tiene acceso a éstos por separado desde el elemento. Se puede tener acceso a todos los ejemplos de tipos de extensiones desde un formulario de extensión global. Una consulta eficiente puede componerse de manera que regresará todos los ejemplos de un tipo determinado de extensión sin importar los tipos de elementos asociados a ésta. Las API de la plataforma de almacenamiento proporcionan un modelo de programación que puede almacenar, recuperar y modificar las extensiones de los elementos. Los tipos de extensiones pueden tener subtipos usando el modelo de herencia único de la plataforma de almacenamiento. La derivación de un tipo de extensión crea un nuevo tipo de extensión. La estructura o el comportamiento de una extensión no puede anular o reemplazar la estructura o los comportamientos de la jerarquía del tipo de elemento. De manera similar a los tipos de Elementos, se puede tener acceso a los ejemplos del tipo de Extensión de manera directa a través de un formulario asociado con el tipo de extensión. El identificador del elemento de la extensión indica a qué elemento pertenece y se pueden usar para recuperar el elemento correspondiente objetivo desde el formulario del elemento global. Las extensiones se consideran parte del elemento para propósitos de consistencia operativa. Las operaciones comunes como copiar/mover, respaldar/restaurar, así como otras, que la plataforma de almacenamiento define pueden operar en las extensiones como parte del elemento. Considere el siguiente ejemplo. Se define un tipo Contacto en el conjunto de tipos de Windows. <Type Name = "Contact" BaseType = "Base.ltem" > <Property Name = "Name" Type = "String" Nullable = "false" Mult¡Valued = "false"/> <Property Name = "Address" Typ8="Address" Nullable = "true" MultiValued = "false'7> </Type> Un desarrollador de una aplicación CRM puede desear anexar una extensión de aplicación CRM a los contactos almacenados en la plataforma de almacenamiento. El desarrollador de la aplicación puede definir una extensión CRM que puede contener la estructura de datos adicionales que la aplicación puede manipular. <Type Name = "CRMExtension" BaseType = "Base. Extensión" > <Property Name = "CustomerlD" Type = "String" Nullable = "false" MultiValued = "false"/> </Type> Un desarrollador de una aplicación HR puede desear también anexar datos adicionales con el Contacto. Estos datos son independientes de los datos de aplicación CRM.

Nuevamente el desarrollador de la aplicación puede crear una extensión. <Type Name = "HRExtension" EBaseType = "Base. Extensión" > <Property Name = "EmployeelD" Type = "String" Nullable = "false" MultiValued = "false'7> </Type> Las extensiones CRMExtension y HRExtension son dos extensiones independientes que se pueden anexar a los elementos Contacto. Se crean y se tiene acceso a éstos de manera independiente entre sí. En el ejemplo anterior, los campos y los métodos para el tipo CRMExtension no pueden anular los campos o los métodos de la jerarquía Contacto. Debe observarse que los ejemplos del tipo CRMExtension se pueden anexar a los tipos Elementos diferentes a Contacto. Cuando el elemento Contacto se recupera, las extensiones del elemento no se recuperan de manera automática. Dado un elemento Contacto, se puede tener acceso a las extensiones relacionadas del elemento mediante una consulta al formulario de extensión global para las extensiones con el mismo identificador de elemento. Se puede tener acceso a todas las extensiones CRMExtension en el sistema a través del formulario del tipo CRMExtension, sin tomar en cuenta a qué elemento pertenecen. Todas las extensiones de elemento de un elemento comparten el mismo identificador de elemento. En el ejemplo anterior, el ejemplo de elemento Contacto y los ejemplos adjuntos de las extensiones CRMExtension y HRExtension representan el mismo identificador del elemento. La siguiente tabla resume las similitudes y las diferencias entre los tipos Elemento, Extensión y ElementoAnidado: TABLA 1 Item versus Item Extensión versus NestedEIement b) Extensión de ios tipos de elementos anidados (NestedEIement) Los tipos Elementos Anidados no se extienden con el mismo mecanismo que los tipos Elemento. Las extensiones de los elementos anidados se almacenan y se tiene acceso a éstos con los mismos mecanismos que a los campos de los tipos de los elementos anidados. El modelo de datos define una raíz para los tipos de elemento anidado denominado Elemento: <Type Name = "Element" lsAbstract='True"> <Property Name = "ElementlD" Type = "the storage platformTypes. uniqueidentifier" Nullable = "false" MultiValued = "false"/> </Type> El tipo NestedElement (ElementoAnidado) se hereda de este tipo. El tipo de elemento NestedElement (ElementoAnidado) adicionalmente define un campo que es un conjunto múltiple de elementos. <Type Name = "NestedElement" BaseType = "Base.Element" lsAbstract = "True"> <Property Name = "Extensions" Type = "Base.Element" Nullable = "false" MultiValued = "true'7> </Type> Las extensiones del elemento anidado son diferentes de las extensiones del elemento de las siguientes formas: Las extensiones del elemento anidado no son tipos de extensiones. No pertenecen a la jerarquía del tipo de extensión que se origina en el tipo Base. Extensión. Las extensiones del elemento anidado se almacenan junto con los otros campos del elemento y no se puede tener acceso a éstos globalmente, no se puede tener una consulta que recupere todas las instancias de un tipo de extensión determinado. Estas extensiones se almacenan de la misma manera que se almacenan otros elementos anidados (del elemento). Como otros conjuntos anidados, las extensiones NestedElement se almacenan en un UDT. Se puede tener acceso a éstas a través del campo Extensions del tipo del elemento anidado. Las interfaces de la colección que se usan para acceder a las propiedades de valores múltiples también se usan para acceder y reiterar un conjunto de extensiones del tipo. La siguiente tabla resume y compara las extensiones Item (Elemento) y las extensiones Nestedltem (Elemento Anidado).

TABLA II Extensiones Item versus extensiones NestedElement D. MOTOR DE LA BASE DE DATOS Como se mencionó en párrafos anteriores, el almacén de datos se implementa en un motor de una base de datos. En la presente modalidad, el motor de la base de datos comprende un motor de una base de datos de relación que implementa el lenguaje de consulta SQL, como el motor del servidor SQL de Microsoft, con extensiones relaciónales de objeto. Esta sección describe la correlación del modelo de datos que el almacén de datos implementa con el almacén relacional y proporciona información sobre la API lógica consumida por los clientes de la plataforma de almacenamiento, de conformidad con la presente modalidad. Sin embargo, se comprende que se puede emplear una correlación diferente si se emplea un motor de base de datos diferente. Es más, además de la implementación de) modelo de datos conceptual de la plataforma de almacenamiento en un motor de base de datos relacional, también se puede implementar en otros tipos de bases de datos, por ejemplo, orientados por objeto y bases de datos XML. Un sistema de bases de datos orientado por objeto (00) proporciona una persistencia y las transacciones para programar objetos de lenguaje (por ejemplo C + + , JAVA). La noción de la plataforma de almacenamiento de un "elemento" se correlaciona bien con un "objeto" en los sistemas orientados por objeto, aunque las colecciones incrustadas deberán ser añadidas a los objetos. Otros conceptos de los tipos de plataformas de almacenamiento, como los tipos de elemento anidado y de herencia, también correlacionan los sistemas del tipo orientado por objeto. Los sistemas orientados por objeto típicamente ya soportan la identidad del objeto; por lo tanto, se puede correlacionar la identidad del elemento con la identidad del objeto. Los comportamientos del elemento (operaciones) se correlaciona bien con los métodos del objeto. Sin embargo, los sistemas orientados por objeto típicamente no cuentan con capacidades de organización y tienen una mala capacidad de búsqueda. De igual manera, los sistemas orientados por objeto no proveen soporte para datos no estructurados y semiestructurados. Para soportar el modelo completo de datos de la plataforma de almacenamiento que se describe en la presente, los conceptos como relaciones, carpetas y extensiones no se añadirán al modelo de datos de objeto. Además, será necesario implementar mecanismos como promociones, sincronización, notificaciones y seguridad. De manera similar a los sistemas orientados por objeto, las bases de datos XML, basadas en XSD (definición del esquema XML), soportan un sistema de tipo basado en una sola herencia. El sistema de tipo elemento de la presente invención se puede correlacionar con el modelo de tipo XSD. Los XSD tampoco proporcionan soporte para los comportamientos. Los XSD para los elementos deberán aumentarse con los comportamientos del elemento. Las bases de datos XML lidian con documentos únicos XSD y no cuentan con buenas capacidades de organización y búsqueda amplia. Como con las bases de datos orientadas por objeto, para soportar el modelo de datos que se describe en la presente, es necesario incorporar otros conceptos como relaciones y carpetas en las bases de datos como XML; también es necesario implementar mecanismos como sincronización, notificaciones y seguridad. 1. Implementación del almacén de datos usando UDT En la presente modalidad, el motor de la base de datos relacional 314, el cual en una modalidad comprende el motor del servidor de SQL de Microsoft, soporta los tipos escalares integrados. Los tipos escalares integrados son "nativos" y "simples". Son nativos en el sentido de que el usuario no puede definir sus propios tipos y son simples porque no pueden encapsular una estructura compleja. Los tipos definidos por el usuario (denominados a partir de ahora: UDT) proporcionan un mecanismo para la capacidad de extensión del tipo anterior sobre y más allá del sistema tipo escalar nativo al habilitar a los usuarios para que extiendan el sistema de tipo al definir tipos estructurados y complejos. Una vez definidos por un usuario, un UDT se puede usar en cualquier momento en el sistema tipo que puede usar un tipo escalar integrado. De conformidad con un aspecto de la presente invención, los esquemas de la plataforma de almacenamiento se correlacionan con las clases de UDT en el almacén del motor de la base de datos. Los elementos del almacén de datos se correlacionan con las clases de UDT que se derivan del tipo Base. Item (Base. Elemento). Como los Elementos, fas Extensiones también se correlacionan las clases de UDT y usan la herencia. El tipo de extensión de raíz es Base. Extensión, desde la cual se derivan todos los tipos de extensiones. Un UDT es una clase CLR, tiene un estado (por ejemplo campos de datos) y comportamiento (es decir, rutinas). Los UDT se definen usando cualquiera de los lenguajes administrados-C#, VB,NET, etc. Los métodos de UDT y sus operadores se pueden invocar en T-SQL en comparación con una instancia de dicho tipo. Un UDT puede ser: el tipo de una columna en una fila, el tipo de un parámetro de una rutina en T-SQL, o el tipo de una variable en T-SQL. El ejemplo a continuación ¡lustra los elementos básicos de los UDT. Suponga que MapLib.dll tiene el montaje llamado apLib. En este montaje, hay una clase denominada Punto, bajo el espacio de nombre BaseTypes (Tipos Base): namespace BaseTypes { public class Point { //devuelve la distancia desde el punto especificado, public double Distance(Point p) { // devuelve la distancia entre el Punto p y este punto } // otras cosas en la clase } } El siguiente código T-SQL une la clase Punto con un UDT del servidor SQL denominado Point (Punto). El primer paso invoca a "CreateAssembly" (CrearEnsamblaje), lo que carga el ensamblaje MapLib en la base de datos. El segundo paso invoca a "Créate Type" (Crear Tipo) para crear el tipo definido por el usuario "Punto" y unirlo al tipo gestionado BaseTypes. Point (TiposdeBase. Punto): CREATE ASSEMBLY MapLib FROM 'Wmysrv\share\MapLib.di go CREATE TYPE Point EXTERNAL ÑAME 'BaseTypes. Point' go Una vez que se ha creado el UDT "Punto" se puede usar como una columna en una tabla y se puede invocar a los métodos en un T-SQL como se muestra a continuación: Créate table Cities( ame varchar(20), State varchar(20), Location Point) -- Retrieve the Distance of the cities -- from co-ordinates (32,23) Declare @p point(32, 23), @distance float Select Location: : Distance(@p) From Cities La correlación de los esquemas de la plataforma de almacenamiento con las clases de UDT es bastante sencillo en un nivel superior. En general, un esquema de la plataforma de almacenamiento está correlacionada con un espacio de nombre CLR. Un Tipo de plataforma de almacenamiento se correlaciona con una clase CLR. La herencia de la clase de CLR refleja la herencia del Tipo de plataforma de almacenamiento, y una Propiedad de la plataforma de almacenamiento se correlaciona con una propiedad de la clase CLR. La jerarquía que se ilustra en la figura 29 se usa como ejemplo en este documento. Muestra el tipo Base. Item (Base. Elemento) del que se derivan todos los tipos de elementos, junto con un conjunto de tipos de elementos derivados (por ejemplo, Contact. Person (Contacto. persona) y Contact.Employee (Contacto. Empleado) y señala la herencia con flechas. 2. Correlación de elementos Dada la conveniencia de que los Elementos puedan ser buscados de manera global y el soporte en la base de datos relacional de la presente modalidad para la herencia y la capacidad de sustitución de un tipo, una ¡mplementación posible para el almacenamiento de Elementos en el almacén de la base de datos debe almacenar todos los elementos en una sola tabla con una columna para el tipo Base. Item (Base. Elemento). Al usar la capacidad de sustitución de un tipo, se pueden almacenar los Elementos de todos los tipos y las búsquedas se pueden filtrar por tipo y subtipo de elemento usando el operador Yukon "es de (Tipo)". Sin embargo, debido a los asuntos relacionados con la sobrecarga asociada con dicho enfoque, en la presente modalidad, los elementos se dividen por tipo de nivel superior, dichos elementos de cada tipo "familia" se almacenan en una tabla separada. Bajo este esquema de división, se crea una tabla para cada tipo de elemento que se hereda directamente desde Base. Item (Base. elemento). Los tipos que se heredan después de esto se almacenan en la tabla de familia del tipo apropiado usando la capacidad de sustitución del tipo, como se describió anteriormente. Sólo el primer nivel de herencia del Base. Item se trata de manera especial. Para la jerarquía del Elemento ejemplar que se muestra en la figura 29, esto genera las siguientes tablas de la familia de tipo: créate table Contact.[Table! Person] ( _ltem Contact. Person not nuil, {Change tracklng information} ) créate table Doc.[Table!Document] ( _ltem Doc.Document not nuil, {Change tracking information} ) Se usa una tabla "sombra" para almacenar copias de las propiedades que pueden ser buscadas globalmente para todos los elementos. Esta tabla se puede mantener a través del método de actualización Update( ) de la API de la plataforma de almacenamiento, a través de la cual se hacen todos los cambios a los datos. A diferencia de las tablas de la familia de tipo, esta tabla de elemento global contiene sólo las propiedades escalares de nivel superior del elemento, no el objeto del elemento UDT completo. La estructura de la tabla del Elemento global se muestra a continuación: créate table Base . [Table! Item] ( ItemID uniqueidentifier not nuil constraint [PK_Clu_ltem!ltemlD] primary key clustered, TypeID uniqueidentifier not nuil, {Additional Properties of Base. Item}, {Change tracking information} ) La tabla de Elementos global permite la navegación hacia el objeto del Elemento almacenado en una tabla de familia de tipo mediante la exposición de un ItemID (identificador de elemento) y TypeID (¡dentificador de tipo). El ItemID (identificador del elemento) generalmente identifica de manera exclusiva el Elemento dentro del almacén de datos. El TypeID (¡dentificador de tipo) se puede correlacionar usando metadatos, que no se describen en la presente, con un nombre de tipo y el formulario que contiene al elemento. Debido a que el hallazgo de un elemento a través de su ¡dentificador del elemento puede ser una operación común, tanto en el contexto de la tabla del elemento global y de otra manera, una función para obtener un elemento Getltem( ) se provee para recuperar un objeto del elemento determinando un ItemID (¡dentificador de elemento) para este elemento. Esta función tiene la siguiente declaración: Base. Item Base.Getltem (uniqueidentifier ItemID) Para un cómodo acceso y para ocultar los detalles de la implementación en el grado de lo posible, todas las consultas de los elementos pueden hacerse en los formularios integrados en las tablas de elementos descritas anteriormente. Específicamente, los formularios se pueden crear para cada tipo de elemento para la tabla de familia del tipo adecuado. Esos formularios de tipo pueden seleccionar todos los elementos de un tipo asociado, incluyendo los subtipos. Por comodidad, además del objeto UDT, los formularios pueden exponer columnas para todos los campos de nivel superior de dicho tipo, incluyendo los campos heredados. Los formularios para la jerarquía de elementos que se muestran en la figura 29 son como se muestra: créate view Contact. Person as select _Jtem. Iteml D, {Properties of Base. Item}, {Properties of Contact. Person}, {Change tracking ¡nformation}, _ltem from Contact. [Table!Person] --Observe que el formulario Contact. Employee usa un predicado "where" (en donde) - para restringir el conjunto de Elementos encontrados a las instancias del formulario de creación Contact. Employee como select _ltem. Iteml D, {Properties of Base. Item}, {Properties of Contact. Person}, {Properties of Contact. Employee}, {Change tracking ¡nformation}, cast (_ltem as Contact. Employee) from Contact. [Table! Person] where _Item ¡s of (Contact. Employee) créate view Doc.Document as select _Item. Iteml D, {Properties of Base. Item}, {Properties of Doc.Document}, {Change tracking information}, _ltem from Doc. [Table! Document] --Observe que el formulario Doc. WordDocument usa un predicado "where" (en donde) - para limitar el conjunto de Elementos encontrados a las instancias del formulario de creación Doc. WordDocument como select _Item. Iteml D, {Properties of Base. Item}, {Properties of Doc.Document}, {Properties of Doc. WordDocument}, {Change tracking information}, cast (_ltem as Doc. WordDocument) from Doc.[Table!Document] where _Item is of (Doc. WordDocument) Para completar la información, un formulario también se puede crear sobre la tabla del Elemento global. Este formulario puede exponer las mismas columnas que la tabla: créate view Base. Item as select ItemID, TypeID, {Properties of Base. Item}, {Change tracking information} from Base. [Table! Item] 3. Correlación de extensiones Las extensiones son muy similares a los Elementos y tienen algunos de los mismos requerimientos. Como otro tipo de raíz que soporta la herencia, las extensiones están sujetas a muchas de estas mismas consideraciones e intercambios en el almacenamiento. Debido a esto, una correlación familiar de tipo similar se aplica a las Extensiones, en lugar de un solo enfoque de tabla. Desde luego, en otras modalidades, se puede usar un enfoque de tabla única. En la presente modalidad, se asocia una Extensión exactamente con un elemento a través del ¡dentificador del elemento y contiene un ¡dentificador de extensión que es exclusivo en el contexto del elemento. La tabla de Extensión tiene la siguiente definición: créate table Base.[Table!Extension] ( ItemID uniqueidentifier not nuil, ExtensionID uniqueidentifier not nuil, TypeID uniqueidentifier not nuil, {Properties of Base. Extensión}, {Change tracking information}, constralnt [PK_Clu_Extension!ltemlD!ExtensionlD] primary key clustered (ItemID ase, ExtensionID ase) Como con los elementos, se debe proveer una función para recuperar una extensión dada su identidad, lo que consiste en un par de identificador de elemento e identificador de extensión (ItemID y ExtensionID). Esta función tiene la siguiente declaración: Base. Extensión Base. GetExtension (uniqueidentifier ItemID, uniqueidentifier ExtensionID,) Se crea un formulario para cada tipo de extensión, similar a los formularios del tipo de elemento. Suponga una jerarquía de Extensión paralela a la jerarquía de Elemento del ejemplo, con los siguientes tipos: Base. Extensión, Contact.PersonExtension, Contact. EmployeeExtension. Se crean los siguientes formularios: créate view Base. Extensión as select ItemID, ExtensionID, TypeID, {Properties of Base. Extensión}, {Change tracking information} from Base.[Table!Extension] créate view Contact. [Extension!PersonExtension] as select _Extension. ItemID, _Extens¡on. ExtensionID, {Properties of Base. Extensión, {Properties of Contact.PersonExtension}, {Change tracking information}, _Extension from Base.[Table!PersonExtens¡on] créate view Contact.[Extension!Emplo- yeeExtension] as select _Extension.ltemlD, _Extens¡on. Extensión ID, {Properties of Base. Extensión}, {Properties of Contact. Person Extensión}, {Properties of Contact. EmployeeExtensi- on}, {Change tracking information}, cast (_Extension as Contact.EmployeeExtension) from Base. [Ta ble! Person Extensión] where _Extension is of (Contact.EmployeeExtension) 4. Correlación de elementos anidados Los elementos anidados son tipos que se pueden incrustar en los Elementos, Extensiones, Relaciones y otros Elementos Anidados para formar estructuras anidadas más profundamente. Como en Elementos y Extensiones, los Elementos Anidados se implementan como UDT, pero se almacenan dentro de Elementos y Extensiones. Por lo tanto, los Elementos Anidados no tienen una correlación de almacenamiento más allá de sus contenedores de Elemento y Extensión. En otras palabras, no hay tablas en el sistema que almacenen de manera directa las instancias de los tipos NestedElement, y no hay formularios dedicados específicamente a los elementos anidados. 5. Identidad del objeto Cada entidad en el modelo de datos, es decir, cada Elemento, cada Extensión y cada Relación, tiene un valor clave único. Un elemento se identifica de manera exclusiva por su propio identificador de elemento. Una Extensión se identifica de manera exclusiva a través de una clave compuesta de (identificador del elemento, identificador de la extensión). Una relación se identifica a través de una clave compuesta (identificador del elemento, identificador de la relación). Los valores de Itemld (Identificador del elemento), Extensionid (Identificador de la extensión) y Relationshipld (Identificado de la relación son valores GUID. 6. Denominación de objetos de SQL Todos los objetos creados en el almacén de datos se pueden almacenar en un nombre de esquema SQL derivado del nombre del esquema de la plataforma de almacenamiento. Por ejemplo, el esquema Base de la plataforma de almacenamiento (con frecuencia denominado "Base") puede producir tipos en el esquema "[System. Storage]" SQL, por ejemplo "[System. Storage]. Item. Los nombres generados reciben un prefijo a través de un calificador para eliminar los conflictos de denominación. Cuando es adecuado, se usa un signo de admiración (!) como un separador para cada parte lógica del nombre. La tabla a continuación señala los convencionalismos de denominación que se usan para los objetos en el almacén de datos. Cada elemento del esquema (Item, Extensión, Relationship y View), se enumera junto con los convencionalismos de denominación decorados que se usan para acceder a las instancias en el almacén de datos. TABLA III Objeto Decoración de nombre Descripción Ejemplo Formulario de Master!ltem Proporciona un [System. Storage] búsqueda del resumen de [ aster!ltem] elemento maestro elementos en el dominio del elemento actual Formulario de Itemtype Proporciona todos los [AcmeCorp.Doc] búsqueda del datos de propiedad [OfficeDoc] elemento del elemento y clasificado cualquier tipo de origen Formulario de Master!Extension Proporciona un [System.Storage] búsqueda de la resumen de todas las [ aster!Extension] extensión maestra extensiones en el dominio del elemento actual Formulario de Extension!extensionType Proporciona todos los [AcmeCorp.Doc] búsqueda de la datos de propiedad [Extensión IStickyNote] extensión para la extensión clasificada Formulario de la Master!Relatlon Proporciona un [System.Storage] relación maestra resumen de todas las [Master!Relation] relaciones en el dominio del elemento actual Formulario de Relation!relationName Proporciona todos los [AcmeCorp.Doc] relación datos asociados con [Relationship!Authors una relación FromDocument] determinada Formulario View!viewName Proporciona las [AcmeCorp.Doc] columnas/ tipos con View!DocumentTitles] base en la definición del formulario del esquema 7. Denominación de columnas Cuando se correlaciona cualquier modelo de objeto en un almacén, la posibilidad de confrontaciones de las denominaciones se producen debido a una información adicional almacenada junto con un objeto de la aplicación. Para evitar las confrontaciones de denominación, todas las columnas específicas sin tipo (columnas que no se correlacionan directamente con la Propiedad denominada en una declaración de tipo) recibe un prefijo con un carácter de guión bajo (_). En la modalidad que se presenta, los caracteres de guión bajo (_) están inhabilitados como el carácter de inicio de cualquier propiedad del identificador. Adicionalmente, para unificar la denominación entre CLR y el almacén de datos, todas las propiedades de los tipos de la plataforma de almacenamiento o del elemento de esquema (relación, etc.) deben tener un primer carácter en mayúscula. 8. Formularios de búsqueda Los formularios se proporcionan mediante la plataforma de almacenamiento para buscar el contenido almacenado. Se proporciona un formulario SQL para cada tipo de Elemento y Extensión. Adicionalmente, los formularios se proporcionan para soportar las relaciones y los formularios (como se define por el modelo de datos). Todos los formularios SQL y las tablas subyacentes en la plataforma de almacenamiento son de sólo lectura. Los datos se pueden almacenar o cambiar usando el método de actualización UpdateQ de la API de la plataforma de almacenamiento, como se describe con mayor detalle a continuación. Se puede tener acceso a cada formulario definido explícitamente en un esquema de la plataforma de almacenamiento (definida por el diseñador del esquema, y no se genera automáticamente por la plataforma de almacenamiento) a través del formulario SQL denominado [<schema-name>].[View!<view-name>]. Por ejemplo, se puede tener acceso al formulario denominado " VentadeLibros" en el esquema "PublicacionesAcme. libros" usando el nombre "[PublicacionesAcme. Libros]. [Formulario! VentadeLibros]". Debido a que el formato de resultados de un formulario se personaliza por cada formulario (definido por una consulta arbitraria proporcionada por la parte que define al formulario), las columnas se correlacionan directamente con base en la definición del formulario del esquema. Todos los formularios de búsqueda de SQL en el almacén de datos de la plataforma de almacenamiento usan los siguientes convencionalismos de orden para las columnas: 1. Columnas "clave" lógicas de los resultados del formulario como Itemld, Elementld, Reltionshipld, . . . 2. Información de los metadatos sobre el tipo de resultados como Typeld. 3. Columnas de seguimiento de cambios como CreateVersion, UpdateVersion , . . . 4. Columnas específicas del tipo (propiedades del tipo declarado). 5. Formularios específicos del tipo (formularios de familia) también contienen una columna de objeto que devuelve el objeto. Los miembros de cada tipo de familia se pueden buscar usando una serie de formularios de Elemento, contando con un formulario por tipo de Elemento en el almacén de datos. a) Elemento Cada formulario de búsqueda de Elementos contiene una fila para cada instancia de un Elemento del tipo específico o sus subtipos. Por ejemplo, el formulario para el Documento puede devolver instancias de Documento, DocumentoLegal y DocumentodeRevisión. Dado este ejemplo, los formularios de Elementos se pueden estimar como se muestra en la figura 28. (1) Formulario maestro de búsqueda de elementos Cada instancia de un almacén de datos de la plataforma de almacenamiento define un formulario especial del elemento denominado Formulario maestro de elementos. Este formulario proporciona información resumida de cada elemento que se encuentra en el almacén de datos. El formulario proporciona una columna por propiedad de tipo de elemento, una columna que describe el tipo de elemento y diversas columnas que se usan para proveer el seguimiento de los cambios además de información de sincronización. El formulario del elemento maestro se identifica en un almacén de datos usando el nombre "[System. Storage]. [Master!ltem]". TABLA IV (2) Formularios de búsqueda de elementos por tipo Cada tipo de elemento tiene un formulario de búsqueda. Aunque es similar al formulario del Elemento de raíz, este formulario también proporciona acceso al objeto Elemento a través de la columna "_ltem". Cada formulario de búsqueda de elemento por tipo se identifica en un almacén de datos que usa el nombre [schemaName].[itemTypeName]. Por ejemplo, [AcmeCorp.Doc]. [OfficeDoc]. TABLA V b) Extensiones del elemento También se tiene acceso a todas las extensiones del elemento en un almacén WinFS usando formularios de búsqueda. (1) Formulario maestro de búsqueda de extensiones Cada instancia de un almacén de datos define un formulario especial de Extensión denominado Formulario maestro de extensión. Este formulario proporciona información resumida de cada Extensión que se encuentra en el almacén de datos. El formulario tiene una columna por propiedad de tipo de Extensión, una columna que describe el tipo de extensión y diversas columnas que se usan para proporcionar el seguimiento de los cambios además de la información de sincronización. El formulario maestro de extensión se identifica en un almacén de datos usando el nombre "[System. Storage]. [Master! Extensión]". TABLA Vi Columna Tipo Descripción Itemld Identificador del elemento La identidad de la plataforma de almacenamiento del elemento con el que esta extensión está asociada. Extensionld Identificador de la extensión Identificador de esta instancia (GUID) de extensión _TypeId Identificador del tipo El identificador del tipo de extensión identifica el tipo exacto de la extensión y se puede usar para recuperar información en la extensión usando el catálogo de metadatos. <seguimiento de Información del seguimiento de cambios globa!es> cambios globales <propiedades de <específico de la propiedad> Una columna por cada extensión> propiedad del tipo de extensión (2) Formularios de búsqueda de extensiones por tipo Cada tipo de Extensión también tiene un formulario de búsqueda. Aunque es similar al formulario maestro de extensión, este formulario también proporciona acceso al objeto Elemento a través de la columna _Extension. Cada formulario de búsqueda de extensión por tipo se identifica en un almacén de datos que usa el nombre [schemaName] . [Extensión extension TypeName] . Por ejemplo, [AcmeCorp. Doc] . [Extensión !OfficeDocExt]. TABLA VII c) Elementos anidados los elementos anidados se almacenan dentro de las instancias elementos, extensiones o relaciones. De esta manera, se puede tener acceso a éstos al consultar el formulario de búsqueda adecuado Item para los elementos, Extensión para las extensiones o elationship para las relaciones. d) Relaciones Como se analizó anteriormente, las relaciones forman la unidad fundamental de enlace entre los elementos en un almacén de datos de la plataforma de almacenamiento. (1) Formulario maestro de búsqueda de relaciones Cada almacén de datos proporciona un formulario de relación maestra. Este formulario proporciona información sobre todas las instancias de relación que se encuentra en el almacén de datos. El formulario maestro de relaciones se identifica en un almacén de datos usando el nombre "[System.Storage].[M áster! Relationship]".

TABLA VIII (2) Formularios de búsqueda de instancias de relación Cada relación declarada también tiene un formulario de búsqueda que devuelve todas las instancias de la relación particular. Aunque es similar al formulario maestro de relaciones, este formulario también proporciona columnas denominadas para cada propiedad de los datos de la relación. Cada formulario de búsqueda de instancias de relación se identifica en un almacén de datos usando el nombre [sc/7emaAar?7e].[Relationship! realtioshipName]. Por ejemplo, [AcmeCorp.Doc].[Relationsh¡p !DocumentAuthor].

TABLA IX 9 Actualizaciones Todos los formularios en el almacén de datos de la plataforma de almacenamiento son de sólo lectura. Para crear una nueva instancia de un elemento de modelo de datos (elemento, extensión o relación), o para actualizar una instancia existente, se deben usar los métodos ProcessOperation (operación de procesos) o ProcessUpdategram (actualización de procesos) de la API de la plataforma de almacenamiento. El método de operación de procesos es un procedimiento almacenado único definido por el almacén de datos que consume una "operación" que detalla una acción que será realizada. El método de actualización de procesos es un procedimiento almacenado que desarrolla un conjunto ordenado de operaciones, conocido como "grama de actualización", que detalla de manera colectiva un conjunto de acciones que serán realizadas. El formato de la operación se puede extender y proporciona diversas operaciones sobre los elementos del esquema. Algunas operaciones comunes incluyen: 1. Operaciones del elemento: a. Createltem (crea un nuevo elemento dentro del contexto de una relación de incrustación o de propiedad). b. Updateltem (actualiza un elemento existente). 2. Operaciones de la relación: a. CreateRelationship (crea una instancia de una propiedad de referencia o de propiedad). b. UpdateRelationship (actualiza una instancia de relación). c. DeleteRelationship (borra una instancia de relación). 3. Operaciones de la extensión: a. CreateExtension (añade una extensión a un elemento existente). b. UpdateExtension (actualiza una extensión existente). c. DeleteExtension (borra una extensión). 10. Seguimiento de cambios y lápidas Los servicios de seguimiento de cambios y lápidas los proporciona el almacén de datos, como se analiza con mayor detalle a continuación. Esta sección proporciona un esquema de la información del seguimiento de cambios expuestos en un almacén de datos. a) Seguimiento de cambios Cada formulario de búsqueda proporcionado por el almacén de datos contiene columnas que se usan para proveer la información sobre el seguimiento de los cambios; las columnas son comunes entre todos los formularios de elemento, extensión y relación. Los formularios del esquema de la plataforma de almacenamiento, que se definen explícitamente a través de los diseñadores de esquemas, no proporcionan de manera automática información sobre el seguimiento de los cambios, dicha información se provee de manera indirecta a través de los formularios de búsqueda en donde se construye el mismo formulario. Para cada elemento dentro del almacén de datos, la información de seguimiento de cambios está disponible en dos lugares, el formulario "maestro" del elemento y el formulario del elemento "por tipo". Por ejemplo, la información de seguimiento de los cambios en el tipo de elemento AcmeCorp. Document está disponible en el formulario maestro del elemento "[System. Storage].[Master!ltem] y el formulario de búsqueda de elemento por tipo [AcmeCorp.Document]. [Document]. (1) Seguimiento de cambios en los formularios "maestro" de búsqueda La información del seguimiento de cambios en los formularios maestros de búsqueda proporciona información sobre las versiones de creación y actualización de un elemento, la información sobre el compañero sincronizado creado en el elemento, cuyo compañero sincronizado actualizó por última vez al elemento y los números de versión para cada compañero para creación y actualización. Los compañeros en las relaciones de sincronización (descritas a continuación) se identifican a través de una clave de compañero. Usando un objeto UDT único denominado _ChangeTrackinglnfo del tipo [System. Sorage. Store]. ChangeTrackingl nfo contiene toda esta información. El tipo se define en el esquema System. Storage. El campo _ChangeTrackinglnfo está disponible en todos los formularios de búsqueda global por elemento, Extensión y Relationship. La definición del tipo de ChangeTrackinglnfo es: <Type Name = " ChangeTrackinglnfo" BaseType = "Base.NestedElement"> <FieldProperty ame = "CreationLocalTS" Type = "SqlTypes.Sqllnt64" Nullable = "False" /> <F¡eldProperty Name = "CreatingPartnerKey" Type = "SqlTypes.Sqllnt32" Ñullable="False" /> <FieldProperty Name = "CreatingPartnerTS" Type = "SqlTypes.Sqllnt64" Nullable = "False" /> <FieldPropert Name = "LastUpdateLocalTS" Type = "SqlTypes.Sqllnt64" Nullable="False" /> <FieldProperty ame = "LastUpdatingPartnerKey" Type = "SqlTypes.Sqllnt32" Nullable = "False" /> <FieldProperty Name = "LastUpdatingPartnerTS" Type = "SqlTypes.Sqllnt64" Nullable="False" /> </Type> Estas propiedades contienen la siguiente información: TABLA X Columna Descripción _CreationLocalTS Etiqueta del momento en la máquina local lo creó _CreatingPartnerKey Clave del compañero que creó esta entidad. Si la entidad se creó localmente, ésta es la clave del compañero de la máquina local _CreatingPartnerTS Etiqueta del momento en que esta entidad se creó en el compañero correspondiente para __CreatingPartnerKey _LastUpdatelocalTS Etiqueta de tiempo local que corresponde a la hora de actualización en la máquina local. _LastUpdatingPartner Clave del compañero que actualizó esta entidad por última vez. Si la Key actualización última a la entidad se realizó localmente, ésta es la clave de compañero de la máquina local. _LastUpdatingPartner Etiqueta del tiempo del momento en que esta entidad se actualizó en TS el compañero que corresponde a _LastUpdtat¡ngPartnerKey (2) Seguimiento de cambios en formularios de búsqueda "por tipo" Además de proveer la misma información que el formulario de búsqueda global, cada formulario de búsqueda por tipo proporciona información adicional que registra el estado de sincronización de cada elemento sobre la topología de sincronización. TABLA XI Columna Tipo Descripción <seguimiento de Información del cambios globales> seguimiento de los cambios globales _ChangeUnltversions Conjunto múltiple de la Descripción de los números <versión de la unidad de de versión de las unidades cambio> de cambio dentro del elemento particular _ElementSync etadata Metadatos de Metadatos independientes sincronización del de la versión adicionales elemento sobre este elemento que sólo es de interés para el tiempo de ejecución de la sincronización _VersionSyncMetadata Metadatos de Metadatos específicos de sincronización de la la versión adicionales sobre versión esta versión que sólo es de interés para el tiempo de ejecución de la sincronización b) Lápidas El almacén de datos proporciona Información sobre las lápidas para los elementos, extensiones y relaciones. Los formularios de las lápidas proporcionan información sobre las entidades lapidadas y activas (elementos, extensiones y relaciones) en un lugar. Los formularios de lápidas de elementos y extensiones no proporcionan acceso al objeto correspondiente, aunque el formularlo de las lápidas de relaciones proporciona acceso al objeto de relación (el objeto de relación es NULO en caso de una relación lapidada). (1) Lápidas de elementos Las lápidas de elementos se recuperan del sistema a través del formulario [System. Storage]. [Tombstone!ltemj. TABLA XII Columna Tipo Descripción Itemld Identificador del elemento Identidad del elemento _TypelD Identificador del tipo Tipo del elemento <propiedades del Propiedades definidas para todos elemento> los elementos _Rootltemld Identificador del elemento Identificador del elemento para el primer elemento no incrustado que contiene este elemento _ChangeTrackinglnfo Instancia de CLR del tipo de Información de los cambios para información de seguimiento este elemento de cambios JsDeleted BIT Este es un indicador que es 0 para los elementos activos y 1 para los elementos lapidados _DeletionWallClock Tiempo y fecha del horario Es el horario y fecha del reloj del universal coordinado tiempo universal coordinado de conformidad con el socio que eliminó este elemento. Su valor es NULL (nulo) si el elemento está activo (2) Lápidas de extensiones Las lápidas de las extensiones se recuperan del sistema a través del formulario [System. Storage].[Tombstone!Extension]. La información sobre el seguimiento de los cambios a las extensiones es similar a la que se provee para los elementos con la adición de la propiedad Extensionld. TABLA XIII (3) Lápida de relaciones Las lápidas de las relaciones se recuperan del sistema a través del formulario [System. Storage].[Tombstone!Relationship]. La información sobre las lápidas de las relaciones es similar a la que se proveen para las extensiones. Sin embargo, se proporciona información adicional sobre la referencia del elemento, ItemRef, objetivo de la instancia de relación. Además, el bjeto de relación también se selecciona TABLA XIV (4) Limpieza de lápidas Para evitar el crecimiento ilimitado de la información de las lápidas, el almacén de datos proporciona una tarea de limpieza de lápidas. Esta tarea determina cuando se puede desechar la información de la lápida. La tarea calcula un límite en la versión de actualización/creación local y después trunca la información de lápidas desechando todas las versiones de anteriores de éstas. 11. Funciones y API de ayuda La correlación base también proporciona un número de funciones de ayuda. Estas funciones se proporcionan para ayudar a las operaciones comunes sobre el modelo de datos. a) Función [System. Storage].GetItem Devuelve un objeto de elemento determinado por un identificador del elemento. // Item Getltem (Itemld Itemld) b) Función [System. Sto ra ge].GetExtension // Devuelve un objeto de extensión determinado a un identificador de elemento y un identificador de extensión. // Extensión GetExtension (Itemld Itemld, Extensionld Extensionld) c) Función [System. StorageJ.GetRelationship // Devuelve un objeto de relación determinado a un identificador de elemento y un identificador de relación. // Relationship GetRelations ip (Itemld Itemld, Relationshipld R e I a t i o n s h ¡ p I d ) 12. etadatos Hay dos tipos de metadatos representados en el almacén: Metadatos de la instancia (del tipo de un elemento), etc. y metadatos de tipo. a) Metadatos de esquema Los metadatos de esquema se almacenan en el almacén de datos como instancias de los tipos de elemento del meta esquema. b) Metadatos de instancia Los metadatos de instancia se usan mediante una aplicación para consultar el tipo de un elemento y encuentra las instrucciones asociadas con un elemento. Dado el identificador para un elemento, una aplicación puede consultar el formulario global de elementos para devolver el tipo de un elemento y usa este valor para consultar el formulario Meta.Type para devolver información sobre el tipo declarado del elemento. Por ejemplo, //Devuelve metadatos de un objeto del Elemento para una instancia del elemento determinada // SELECT m._ltem AS metadatal nfoObj FROM [System. Storage]. [Item] ¡ INNER JOIN [Meta].[Type] m ON i._Typeld = m. Itemld WHERE i.ltemld = @ltemld E. SEGURIDAD Esta sección describe un modelo de seguridad para la plataforma de almacenamiento de la presente invención, de conformidad con una modalidad. 1. Descripción general De conformidad con la presente modalidad, la granularidad con la que la política de seguridad de la plataforma de almacenamiento se especifica y refuerza está al nivel de varias operaciones sobre un elemento en un almacén de datos determinado; no hay capacidad para asegurar las partes de un elemento por separado en un todo. El modelo de seguridad especifica el conjunto de elementos principales a los que se puede otorgar o denegar el acceso para realizar estas operaciones en un elemento a través de las listas de control de acceso (ACL). Cada ACL es una colección ordenada de entradas de control de acceso (ACE). La política de seguridad de un elemento se puede describir por completo a través de la política de control de acceso discrecional y la política de control de acceso al sistema. Cada una de éstas es un conjunto de ACL. El primer conjunto (DACL) describe el acceso discrecional que otorgó el propietario del elemento a los diversos elementos mientras que el segundo conjunto de ACL se denomina SACL (Listas de control de acceso al sistema) las cuales especifican la manera en que se realiza la auditoría del sistema cuando se manipula un objeto de ciertas maneras. Además de lo mencionado, cada elemento dentro del almacén de datos se asocia con un SID que corresponde al propietario del elemento (SID del propietario). El mecanismo principal para organizar los elementos en un almacén de datos de la plataforma de almacenamiento es el de la jerarquía de contención. La jerarquía de contención se realiza usando relaciones de propiedad entre los elementos. La relación de propiedad entre dos elementos A y B que se expresa como "A contiene a B" permite que el elemento A influya en la vida útil del elemento B. En general, un elemento dentro del almacén de datos no puede existir hasta que exista una relación de propiedad de otro elemento hacia éste. La relación de propiedad, además de controlar el tiempo de vida útil del elemento, proporciona los mecanismos necesarios para propagar la política de seguridad para un elemento. La política de seguridad que se especifica para cada elemento consiste en dos partes, una parte que se especifica de manera explícita para ese elemento y una parte que se hereda del origen del elemento en el almacén de datos. La política de seguridad que se define explícitamente para cualquier elemento consta de dos partes, una parte que rige el acceso al elemento bajo ciertas consideraciones y una parte que influye la política de seguridad heredada por todos los descendientes en la jerarquía de contención. La política de seguridad heredada por un descendiente es una función de la política definida explícitamente y la política heredada.

Debido que ia política de seguridad se propaga a través de relaciones de propiedad y también se puede anular en un elemento, es necesario especificar la manera en que se determina la política de seguridad efectiva para un elemento. En esta modalidad, un elemento en la jerarquía de contención del almacén de datos hereda una ACL junto con todos los trayectos de la raíz del almacén al elemento. Dentro de la ACL heredada para un trayecto determinado, el orden de varias ACE en la ACL determina la política de seguridad final que se refuerza. Se usa la siguiente nota para describir el orden de las ACE en una ACL. El orden de las ACE en una ACL que hereda un elemento se determina mediante las dos reglas que se señalan a continuación. La primera regla estratifica las ACE heredadas de los varios elementos de un trayecto hacia el elemento I de la raíz de la jerarquía de contención. La ACE que se hereda de un contenedor más cercano tiene prioridad sobre las entradas heredadas de un contenedor distante. De manera intuitiva, esto permite que un administrador cuente con la capacidad de anular las ACE heredadas desde lejos en la jerarquía de contención. La regla es como se indica a continuación: Para todas las ACL L heredadas en el elemento I Para todos los elementos 11, 12 Para todas las ACE A1 y A2 en L, 11 es un antecesor de 12 y 12 es un antecesor de 13 y A1 es una ACE heredada de 11 y A2 es una ACE heredada de 12 Implica A2 antecede a A1 en L La Segunda regla ordena las ACE que niegan el acceso a un elemento delante de las ACE que otorgan acceso a un elemento. Para todas las ACL L heredadas en el elemento I Para todos los elementos 11 Para todas las ACE A1 y A2 en L, 11 es un antecesor de 12 y A1 es una ACCESS_DENIED_ACE heredado de 11 y A2 es una ACCESS_GRANTED_ACE heredada de 11 Implica A1 antecede a A2 en L En el caso de una jerarquía de contención que es un árbol, existe exactamente un trayecto de la raíz del árbol hacia el elemento y el elemento tiene exactamente una ACL heredada. Bajo estas circunstancias, la ACL heredada por un elemento corresponde a la ACL heredada por un archivo (elemento) en el modelo de seguridad existente de Windows en términos de un orden relativo de las ACE dentro de éstos. Sin embargo, la jerarquía de contención en el almacén de datos es una gráfica acíclica dirigida (DAG) debido a que se permiten varias relaciones de pertenencia a los elementos. Bajo estas condiciones, existen varios trayectos hacia un elemento desde la raíz de la jerarquía de contención. Debido a que un elemento hereda una ACL junto con todos los trayectos de cada elemento, se asocia con una colección de ACL a diferencia de uno solo. Observe que esto es diferente del modelo del sistema de archivos tradicional, en donde exactamente una ACL se asocia con un archivo o carpeta. Existen dos aspectos que deben ser elaborados cuando la jerarquía de contención es una DAG a diferencia de un árbol. Se necesita una descripción sobre la efectividad de la política de seguridad para un elemento y se calcula cuando hereda más de una ACL desde su origen, y la manera cómo se organizan y representan tiene una relación directa en la administración del modelo de seguridad para un almacén de datos de la plataforma de almacenamiento. El siguiente algoritmo evalúa los derechos de acceso para un elemento principal determinado para un elemento determinado. A través de este documento, se usa la siguiente nota para describir las ACL asociadas a un elemento. lnher¡ted_ACLs(ltemld) — el conjunto de ACL heredadas por un elemento cuya identidad de elemento es el ItemID de su origen en el almacén. Explicit_ACL(ltemld) — la ACL que se define explícitamente para el elemento cuya identidad es Itemid. NTSTATUS ACLAccessCheck( PSID pOwnerSid, PDACL pDael, DWORD DesiredAccess, HANDLE ClientToken, PPRIVILEGE_SET pPrivilegeSet, DWORD *pGrantedAccess) La rutina anterior devuelve un valor para STATUS_S UCCESS si el acceso deseado no se negó de manera explícita, y pGrantedAccess determina cuál de los derechos que desea el usuario fueron otorgados mediante la ACL especificada. Si fue negado explícitamente cualquiera de los accesos solicitados, la rutina devuelve un valor de STATUS_ACCESS_DENIED.

NTSTATUS WinFSItemAccessCheck( WINFSJTE ID Itemld, DWORD DesiredAccess, HANDLE ClientToken, PPRIVILEGE SET pPrivilegeSet) { NTSTATUS Status; PDACL pExplicitACL = NULL; PDACL plnheritedACLs = NULL; DWORD NumberOflnheritedACLs = 0; pExplicitACL = GetExplicitACLForltem(ltemld); GetlnheritedACLsForltem(ltemld,&plnheritedACLs,&Num berOflnheritedACLs) Status = ACLAccessCheck( pOwnerSid , pExplicitACL, DesiredAccess, ClientToken, pPrivilegeSet, &GrantedAccess); if (Status != STATUS_SUCCESS) return Status; if (DesiredAccess = = GrantedAccess) return STATUS_SUCCESS; for ( i = 0; (¡ < NumberOflnheritedACLs && Status = = STATUS_SUCCESS); i + + ) { GrantedAccessForACL = 0; Status = ACLAccessCheck( pOwnerSid, pExplicitACL, DesiredAccess, ClientToken, pPrivilegeSet, &G ra nted Access ForACL); if (Status = = STATUS_SUCCESS) { GrantedAccess |= GrantedAccessForACL; } } If ((Status = = STATUS_SUCCESS) && (GrantedAccess != DesiredAccess)) { Status = STATUS ACCESS DENIED; } return Status; } La esfera de influencia de la política de seguridad definida para cualquier elemento cubre todos los descendientes del elemento en la jerarquía de contención que se define en el almacén de datos. Para todos los elementos en donde se define una política explícita, en efecto se define una política. Se obtiene las ACL efectivas heredadas por todos los descendientes tomando cada una de las ACL heredadas por el elemento y añadiendo las ACE heredadas en la ACL explícita en el inicio de la ACL. A esto se denomina el conjunto de ACL heredables asociadas con el elemento . Cuando está ausente una especificación explícita de la seguridad en la jerarquía de contención que tiene raíz en un elemento de carpeta, la especificación de seguridad de la carpeta aplica a todos los descendientes de ese elemento en la jerarquía de contención. De esta manera, todos los elementos a los que se proporciona una especificación de la política de seguridad explícita, definen una región de elementos protegidos de manera idéntica, y las ACL efectivas para todos los elementos en la región son el conjunto de las ACL heredables para ese elemento. Esto define completamente las regiones en el caso de una jerarquía de contención que es un árbol. Si cada región estuviera asociada a un número, entonces sería suficiente incluir únicamente la región a la que pertenece el elemento junto con el elemento. Sin embargo, para las jerarquías de contención que son DAG, los puntos en la jerarquía de contención en donde cambia la política de seguridad efectiva se determina a través de dos tipos de elementos. Los primeros son elementos para los que se especifica una ACL. Comúnmente, estos son los puntos en la jerarquía de contención en donde el administrador tiene especificada de manera explícita una ACL. Los segundos son los elementos que tienen más de un origen, y este origen tienen diferentes políticas de seguridad asociadas a los mismos. Comúnmente, éstos son los elementos que son los puntos confluentes de la política de seguridad especificada para el volumen e indican el principio de una nueva política de seguridad. Con esta definición, todos los elementos en el almacén de datos se encuentran en una de dos categorías -las que son la raíz de una región de seguridad protegida de manera idéntica y las que no. Los elementos que no definen regiones de seguridad perteneces exactamente a una región de seguridad. Como en el caso de los árboles, la seguridad efectiva de un elemento se puede especificar mediante la especificación de la región a la que pertenece el elemento junto con el elemento. Esto lleva a un modelo sencillo para administrar la seguridad de un almacén de datos de la plataforma de almacenamiento que se basa en las diversas regiones protegidas de manera idéntica en el almacén. 2. Descripción detallada del modelo de seguridad Esta sección proporciona detalles sobre cómo se aseguran los elementos al describir los derechos individuales en un Descriptor de seguridad y sus ACL contenidas que afectan varias operaciones. a) Estructura del descriptor de seguridad Antes de describir los detalles del modelo de seguridad, se hace un análisis básico de los descriptores de seguridad que será útil. Un descriptor de seguridad contiene la información de seguridad asociada a un objeto que se puede asegurar. Un descriptor de seguridad consiste en una estructura SECU RITY_DESCRI PTOR y su información de seguridad asociada. Un descriptor de seguridad puede incluir la siguiente información de seguridad: 1. Un SID para el propietario y el grupo primario de un objeto. 2. Una DACL que especifica los derechos de acceso otorgados o negados a usuarios o grupos particulares. 3. Una SACL que especifica los tipos de intentos de acceso que generar registros de auditoría para el objeto. 4. Un conjunto de bits de control que califican el significado de un descriptor de seguridad o sus miembros individuales. Preferiblemente, no es posible que las aplicaciones manipulen de manera directa el contenido de un descriptor de seguridad. Hay funciones para establecer y recuperar la information de seguridad en un descriptor de seguridad de un objeto. Además, hay funciones para crear e inicializar un descriptor de seguridad para un objeto nuevo. Una lista de control de acceso discrecional (DACL) identifica a los usuarios que cuentan con permiso para acceder o no al objeto que se puede asegurar. Cuando un proceso intenta acceder a un objeto que se puede asegurar, el sistema verifica que las ACE de la DACL del objeto para determinar si otorga el acceso a éste. Si el objeto no tiene una DACL, el sistema otorga acceso completo a todos. Si la DACL del objeto no tiene ACE, el sistema rechaza todos los intentos de acceder al objeto debido a que la DACL no permite ningún derecho de acceso. El sistema verifica las ACE en secuencia hasta que encuentra una o más ACE para permitir todos los derechos de acceso solicitados o hasta que alguno de los derechos de acceso solicitados sean rechazados. Una lista de control de acceso al sistema (SACL) habilita a los administradores a que registren los intentos para acceder a un objeto asegurado. Cada ACE especifica los tipos de intentos de acceso a través de un miembro especificado que ocasiona que el sistema genere un registro en la bitácora de eventos de seguridad. Una ACE en una SACL puede generar registros de auditorias cuando falla un intento de acceso, cuando se logra, o en ambas ocasiones. Una SACL también puede generar una alarma cuando un usuario sin autorización intenta obtener acceso a un objeto.

Todos los tipos de ACE contienen la siguiente información de control de acceso: 1. Un identificador de seguridad (SID) que identifica al usuario al que aplica la ACE. 2. Una mascara de acceso que especifica los derechos de acceso controlados por la ACE. 3. Un indicador que indica el tipo de ACE. 4. Un conjunto de indicadores de bits que determina si los contenedores u objetos secundarios pueden heredar la ACE del objeto primario al que está anexa la ACL. La tabla que se muestra a continuación enumera los tipos de ACE árbol soportados por todos los objetos que se pueden asegurar. TABLA XV Tipo Descripción Access-denied ACE Se usa en una DACL para rechazar los derechos de acceso a un usuario. Access-allowed ACE Se usa en una DACL para permitir los derechos de acceso a un usuario. System-audit ACE Se usa en una SACL para generar un registro de auditoria cuando el usuario intenta ejercer los derechos de acceso especificados. (1) Formato de máscara de acceso Todos los objetos que se pueden asegurar disponen sus derechos de acceso usando el formato de enmascaramiento de acceso que se muestra en la figura 26. En este formato, los 16 bits de orden inferior son para los derechos de acceso específico por elemento, los siguientes 7 bits son para los derechos de acceso estándar, lo que aplica a la mayoría de los tipos de objetos y los 4 bits de orden superior se usan para especificar derechos de acceso genérico que cada tipo de objeto puede correlacionar con un conjunto de derechos específicos por objeto y estándar. El bit ACCESS_SYSTEM_SECURITY corresponde al derecho de acceder a la SACL del objeto. (2) Derechos de acceso genérico Los derechos genéricos se especifican en los 4 bits de orden superior dentro del enmascaramiento. Cada tipo de objeto que se puede asegurar correlaciona estos bits con un conjunto de sus derechos de acceso específico por objeto y estándar. Por ejemplo, un objeto de archivo correlaciona el bit GENERIC_READ con los derechos de acceso estándar READ_CONTROL y SYNCH RON IZE y con los derechos de acceso específico por objeto Fl LE_READ_D ATA, FILE_READ_EA, y FILE_READ_ATTRIBUTES. Otros tipos de objetos correlacionan el bit GENERIC_READ con cualquier conjunto de derechos de acceso que sea apropiado para ese tipo de objeto. Se puede usar los derechos de acceso genérico para especificar el tipo de acceso que se necesita al abrir y manejar un objeto. Comúnmente esto es más simple que especificar todos los derechos específicos y estándar correspondientes. La tabla que se muestra a continuación muestra las constantes definidas para los derechos de acceso genérico. TABLA XVI (3) Derechos de acceso estándar Cada tipo de objetos que se pueden asegurar tiene un conjunto de derechos de acceso que corresponde a las operaciones específicas a ese tipo de objeto. Además de estos derechos de acceso específico por objeto, existe un conjunto de derechos de acceso estándar que corresponde a las operaciones comunes de la mayoría de los tipos de los objetos que se pueden asegurar. La tabla que se muestra a continuación muestra las constantes definidas para los derechos de acceso estándar.

TABLA XVII b) Derechos específicos del elemento En la estructura de enmascaramiento de acceso de la figura 26, los derechos específicos del elemento se colocan en la sección de derechos específicos del objeto (16-bits de orden inferior). Debido a que en la presente modalidad, la plataforma de almacenamiento expone dos conjuntos de API para administrar la seguridad, Win32 y la API de la plataforma de almacenamiento, los derechos específicos del objeto en el sistema de archivos se debe considerar para motivar el diseño de los derechos específicos del objeto en la plataforma de almacenamiento. (1) Derechos específicos del objeto de Archivo y Directorio Tome en consideración la siguiente tabla: TABLA XVIII Haciendo referencia a la tabla anterior, observe que los sistemas de archivos hacen una diferencia fundamental entre archivos y directorios, los cual es la razón por la que los derechos de los archivos y los directorios se traslapan en los mismos bits. Los sistemas de archivos definen derechos muy granulares, lo que permite que las aplicaciones controles la conducta sobre estos objetos. Por ejemplo, permiten que las aplicaciones hagan una diferencia entre los Atributos (FILE_READ_/WRITE_ATTRIBUTES), Atributos extendidos y flujos de datos asociados con el archivo. Un objetivo del modelo de seguridad de la plataforma de almacenamiento de la presente invención es simplificar el modelo de asignación de derechos de manera que las aplicaciones que funcionan en los elementos del almacén de datos (Contactos, CorreoElectrónico, etc.) generalmente no necesitan hacer una diferencia entre los atributos, atributos extendidos y flujos de datos, por ejemplo. Sin embargo, para los archivos y las carpetas, los derechos granulares de Win32 se conservan y la semántica de acceso a través de la plataforma de almacenamiento se definen de manera que se puede proveer compatibilidad con las aplicaciones de Win32. Esta correlación se analiza con cada uno de los derechos del elemento que se especifican a continuación. Los siguientes derechos del elemento se especifican con sus operaciones admisibles asociadas. También se proporcionan los derechos de Win32 equivalentes que respaldan a cada uno de estos derechos de elementos. (2) Lectura del elemento WinFS (WinFSItemRead) Estos derechos permiten el acceso de lectura a todos los elementos dentro del elemento, incluyendo los elementos que están enlazados al elemento a través de las relaciones incrustadas. También permite la enumeración de los elementos enlazados a su elemento a través de relaciones de pertenencia (también conocido como listado de directorio). Esto incluye los nombres de los elementos enlazados a través de las relaciones de referencia. Este derecho se correlaciona con: Archivo: (FILE_READ_DATA | SYNCHRONIZE) Carpeta: (Fl LE_LI ST_DI RECTORY | SYNCHRONIZE) La semántica es que una aplicación de seguridad puede establecer WinFSItemReadData (Datos de lectura del elemento de WinFS) y especificar el enmascaramiento de derechos como una combinación de derechos del archivo especificados en párrafos anteriores. (3) Atributos de lectura de los elementos WinFS (WinFSItemReadAttributes) Estos derechos otorgan acceso de lectura a los atributos básicos del elemento, como en los sistemas de archivos se distinguen entre los atributos básicos de archivo y los flujos de datos. Preferiblemente, estos atributos básicos son aquellos que se encuentran en el elemento base del que se derivan todos los elementos. Este derecho se correlaciona con: Archivo: (FILE_READ_ATTRIBUTES) Carpeta: (FILE_READ_ATTRIBUTES) (4) Atributos de escritura de los elementos WinFS (WinFSItemWriteAttributes)) Estos derechos otorgan acceso de escritura a los atributos básicos del elemento, como en los sistemas de archivos se distingue entre los atributos básicos de archivo y los flujos de datos. Preferiblemente, estos atributos básicos se encuentran en el elemento base del que se derivan todos los elementos. Este derecho se correlaciona con: Archivo: (Fl LE_WRlTE_ATTRI BUTES) Carpeta: (FILE_WRITE_ATTRI BUTES) (5) Escritura de elementos WinFS(WinFSItemWrite) Este derecho habilita la capacidad de escribir en todos los elementos de un elemento, incluyendo a los elementos enlazados a través de las relaciones incrustadas. Este derecho también permite la capacidad de añadir o eliminar relaciones incrustadas en otros elementos. Este derecho se correlaciona con: Archivo: (Fl LE_WRITE_DATA) Carpeta: (FILE_ADD_FILE) En el almacén de datos de la plataforma de almacenamiento, no hay diferencia entre los elementos y las carpetas, ya que los elementos también pueden tener relaciones de pertenencia con otros elementos en el almacén de datos. Por lo tanto, si tiene derechos FILE_ADD_SUBDI RECTOR Y (o Fl LE_APPE N D_DATA) , puede hacer que un elemento sea el origen de las Relaciones con otros elementos. (6) Agregar enlace al elemento WinFS (WinFSAddUnk) Este derecho habilita la capacidad de agregar relaciones de pertenencia a los elementos del almacén. Debe observarse que debido a que el modelo de seguridad para las relaciones de pertenencia cambia la seguridad de un elemento y los cambios pueden eludir WRITE_DAC si se obtienen de un lugar superior en la jerarquía, WRITE_DAC se requiere en el elemento de destino para poder crear una relación con éste. Este derecho se correlaciona con: Archivo: (FILE_APPEND_DATA) Carpeta: (FILE_ADD_SUB DI RECTO RY) (7) Eliminar enlace del elemento WinFS (WinFSDeleteLink) Este derecho habilita la capacidad de borrar una pertenencia con un elemento, incluso si el derecho de borrar ese elemento no se haya otorgado al elemento principal. Este es consistente con el modelo del sistema de archivos y lo ayuda a hacer evacuaciones. Este derecho se correlaciona con: Archivo: (FILE_DELETE_CHILD)-Note que los sistemas de archivos no cuentan con un equivalente de este derecho, pero tenemos el conocimiento de los elementos que tienen relaciones de pertenencia con otros, y por lo tanto transportan este derecho para elementos diferentes de carpetas también. Carpeta: (Fl LE_DELETE_FI LE) (8) Derechos para eliminar un elemento Un elemento se borra si la última relación de pertenencia del elemento desaparece. No hay un conocimiento explícito para borrar un elemento. Existe una operación para depurar que elimina todas las relaciones de pertenencia de un elemento, pero es una facilidad de nivel superior y no un sistema primitivo. Un elemento especificado que usa un trayecto puede desunirse si una de dos condiciones se satisfacen: (1) el elemento de origen junto con el trayecto otorga acceso de escritura al sujeto, o (2) los derechos estándar del elemento otorgan el derecho de borrar, DELETE. Cuando se elimina la última relación, el elemento desaparece del sistema. Cualquier elemento especificado que usa un identif icador de elemento se puede desunir si los derechos estándar del mismo elemento otorgan el derecho de borrar, DELETE. (9) Derechos para copiar un elemento Se puede copiar un elemento desde una carpeta origen a una carpeta de destino si el objeto tiene otorgado WinFSltemRead (Lectura del elemento de WinFS) en el elemento y WinFSItemWrite (Escritura del elemento en WinFS) en la carpeta de destino. (10) Derechos para mover un elemento Mover un archivo en el sistema de archivos requiere el derecho de borrar en el archivo de origen y FILE_ADD_FILE en el directorio de destino, ya que conserva la ACL en el destino. Sin embargo, un indicador se puede especificar en la invocación MoveFileEx (MOVEFILE_COPY_ALLOWED) que permite que una aplicación especifique que en el caso de un movimiento de volumen de cruce, se puede tolerar la semántica de copiar archivo, CopyFile. Hay 4 opciones potenciales con respecto a lo que sucede con el descriptor de seguridad al hacer un movimiento: 1. Transportar la ACL completa con la semántica de movimiento dentro del volumen predeterminado en el archivo. 2. Transportar !a ACL completa con el archivo y marcar la ACL como protegida. 3. Transportar solo las ACE explícitas a través y volver a heredar en el destino. 4. No transportar nada y heredar en el destino, la semántica de mover dentro de un volumen predeterminado, igual que copiar un archivo. En el modelo de seguridad que se presenta, si una aplicación especifica el indicador M OVEF I LE_COPY_ALLOWED (se permite mover la copia del archivo), la cuarta opción se realiza en los casos dentro y fuera del volumen. Si no se especifica este indicador, la Segunda opción se realiza, a menos que el destino se encuentre en la misma región de seguridad (es decir, la misma herencia de los valores semánticos). Un movimiento en el nivel de la plataforma de almacenamiento ¡mplementa la cuarta opción también y requiere READ_DATA (lectura de datos) en el origen, así como una acción de copiar. (11) Derechos para visualizar la política de seguridad en un elemento Se puede visualizar la seguridad de un elemento si el elemento otorga el derecho estándar READ_CONTROL (control de lectura) al objeto. (12) Derechos para cambiar la política de seguridad en un elemento Se puede cambiar la seguridad de un elemento si el elemento otorga el derecho estándar WRITE_DAC al objeto. Sin embargo, debido a que el almacén de datos proporciona una herencia implícita, esto tiene implicaciones en la manera de cambiar la seguridad en las jerarquías. La regla es que si la raíz de la jerarquía otorga WRITE_DAC, entonces, la política de seguridad cambia en toda la jerarquía, sin importar si los elementos específicos dentro de la jerarquía (o DAG) no otorgan WRITE_DAC al objeto. (13) Derechos que no tienen un equivalente directo En la presente modalidad, FILE_EXECUTE (FILE_TRAVERSE para los directorios) no tienen un equivalente directo en la plataforma de almacenamiento. El modelo mantiene esto para la compatibilidad con Win32, pero no tiene acceso a las decisiones tomadas para los elementos con base en estos derechos. Como para FILE_READ/WRITE_EA, debido a que los elementos del almacén de datos no conocen los atributos extendidos, no se proporciona la semántica para este bit. Sin embargo, el bit continua para la compatibilidad con Win32. 3. Implementación Todos los elementos que definen regiones protegidas de manera idéntica tienen una entrada asociada con éstas en una tabla de seguridad. La tabla de seguridad se define a continuación: TABLA XIX La entrada de identidad del elemento es la identidad del elemento de la raíz de una región de seguridad protegida de manera idéntica. La entrada de trayecto de orden del elemento es el trayecto de orden asociado con la raíz de la región de seguridad protegida de manera idéntica. La entrada de ACL del elemento explícita es la ACL explícita definida para la raíz de la región de seguridad protegida de manera idéntica. En algunos casos esto puede tener un valor NULL, nulo, por ejemplo, cuando una región de seguridad nueva se define debido a que el elemento tiene varios orígenes que pertenecen a diferentes regiones. La entrada de las ACL del trayecto es el conjunto de ACL heredadas por el elemento, y la entrada de las ACL de la región es el conjunto de ACL definidas para la región de seguridad protegida de manera idéntica asociada con el elemento. El cálculo de la seguridad efectiva para un elemento en un almacén determinado impulsa esta tabla. Para determinar la política de seguridad asociada con un elemento, se obtiene la región de seguridad asociada con el elemento y la ACL asociada con esa región se recuperan. Como la política de seguridad asociada con un elemento cambia, ya sea al añadir de manera directa ACL explícitas o de manera indirecta al añadir relaciones de pertenencia que generan la formación de nuevas regiones de seguridad, la tabla de seguridad se mantiene actualizada para asegurar que el algoritmo anterior para determinar la seguridad efectiva de un elemento sea válido. Los diversos cambios al almacén y los algoritmos que lo acompañan para mantener la tabla de seguridad son como se indica a continuación: a) Creación de un nuevo elemento en un contenedor Cuando recién se crea un elemento en un contenedor, hereda todas las ACL asociadas con el contenedor. Debido a que el elemento recién creado tiene exactamente un origen pertenece a la misma región que su origen. Así, no hay necesidad de crear una nueva entrada en la tabla de seguridad. b) Adición de una ACL explícita en un elemento Cuando se añade una ACL a un elemento, se define una nueva región de seguridad para todos los descendientes en la jerarquía de contención que pertenecen a la misma región de seguridad que el mismo elemento determinado. Para todos los elementos que pertenecen a otras regiones de seguridad pero que son descendientes del elemento determinado en la jerarquía de contención, la región de seguridad permanece sin cambios, pero la ACL efectiva asociada con la región cambia para reflejar la adición de una ACL nueva. La introducción de esta nueva región de seguridad puede activar más definiciones de regiones para los elementos que tienen varias relaciones de propiedad con ancestros que eluden la región de seguridad anterior y la región de seguridad recién definida. Para todos esos elementos es necesario definir una nueva región de seguridad y repetir el procedimiento. Las figuras 27(a), (b) y (c) ilustran una región de seguridad protegida de manera idéntica forjada de una región de seguridad existente al introducir una nueva ACL explícita. Esto se indica con el nodo marcado con 2. Sin embargo, la introducción de esta nueva región ocasiona la creación de una nueva región 3, debido a un elemento que tiene múltiples relaciones de propiedad. La secuencia de actualizaciones a las tablas de seguridad que se muestra a continuación refleja la factorización de las regiones de seguridad protegidas de manera idéntica. c) Adición de una relación de propiedad a un elemento Cuando una relación de propiedad se añade a un elemento genera una de tres posibilidades. Si el objetivo de la relación de propiedad, es decir, el elemento bajo consideración es la raíz de una región de seguridad, la ACL efectiva asociada con la región cambia y no se requieren más modificaciones a la tabla de seguridad. Si la región de seguridad del origen de la nueva relación de propiedad es idéntica a la región de seguridad del origen del elemento existente, no es necesario hacer cambios. Sin embargo, si el elemento ahora tiene un origen que pertenece a diferentes regiones de seguridad, entonces se forma una nueva región de seguridad con el elemento determinado como la raíz de la región de seguridad. Este cambio se propaga a todos los elementos de la jerarquía de contención al modificar la región de seguridad asociada con el elemento. Todos los elementos que pertenecen a la misma región de seguridad que el elemento en consideración y sus descendentes en la jerarquía de contención deben ser cambiados. Una vez que se hace un cambio, todos los elementos que tienen varias relaciones de pertenencia deben ser examinaos para determinar si es necesario hacer más cambios. Es posible que se requieran más cambios si alguno de estos documentos tiene su origen en diferentes regiones de seguridad . d) Eliminación de una relación de propiedad de un elemento Cuando una relación de pertenencia se elimina de un elemento, es posible que se colapse una región de seguridad con su región de origen si se satisfacen algunas condiciones. De manera más precisa, esto se puede lograr bajo las siguientes condiciones: (1) si la remoción de la relación de pertenencia ocasiona un elemento que tiene un origen y no se especifica una ACL explícita para ese elemento; (2) si la remoción de la relación de pertenencia ocasiona un elemento cuyo origen se encuentra en la misma región de seguridad y no se define una ACL explícita para ese elemento. Bajo estas circunstancias, la región de seguridad puede marcarse para que sea igual que la de origen. Es necesario aplicar esta marca a todos los elementos cuya región de seguridad corresponde a la región colapsada. e) Eliminación de una ACL explícita de un elemento Cuando se borra una ACL explícita de un elemento, es posible que se colapse la región de seguridad de la raíz en ese elemento con la de su origen. De manera más precisa, esto se puede realizar si la remoción de la ACL explícita ocasiona un elemento cuyo origen dentro de la jerarquía de contención pertenece a la misma región de seguridad. Bajo estas circunstancias, la región de seguridad se puede marcar para que sea la misma que el origen y el cambio se aplique a todos los elementos cuya región de seguridad corresponde a la región colapsada. f) Modificación de una ACL asociada con un elemento En esta situación no se requiere hacer nuevas adiciones a la tabla de seguridad. La ACL efectiva asociada con la región se actualiza y el nuevo cambio de la ACL se propaga a las regiones de seguridad que están afectadas por la misma. F. SEGUIMIENTO DE CAMBIOS Y NOTIFICACIONES De conformidad con otro aspecto de la presente invención, la plataforma de almacenamiento proporciona una capacidad de notificaciones que permite que las aplicaciones rastreen los cambios de los datos. Esta funcionalidad principalmente se creó para las aplicaciones que mantienen un estado no permanente o ejecutan una lógica comercial en los eventos que hacen cambios en los datos. Las aplicaciones registran las notificaciones en los elementos, extensiones de elementos y relaciones de elementos. Las notificaciones se entregan de manera asincrona después de realizar los cambios de los datos. Las aplicaciones pueden filtrar las notificaciones por elemento, extensión y tipo de relación así como por tipo de operación. De conformidad con una modalidad, la API 322 de la plataforma de almacenamiento proporciona dos tipos de interfaces para las notificaciones. En primer lugar, las aplicaciones registran los eventos de cambios de datos simples activados por los cambios hechos a los elementos, las extensiones de los elementos y las relaciones de los elementos. En segundo lugar, las aplicaciones crean objetos "observadores" para supervisar conjuntos de elementos, extensiones de elementos y las relaciones entre los elementos. El estado de un objeto observador se puede guardar y volver a crear después de la falla de un sistema o después de que el sistema salga de línea durante un periodo largo. Una sola notificación puede reflejar diversas actualizaciones. 1. Eventos de cambio en el almacenamiento Esta sección proporciona algunos ejemplos sobre la manera en que se usan las interfaces de notificación proporcionadas por la API 322 de la plataforma de almacenamiento. a) Eventos Los Elementos, Extensiones de los elementos y Relaciones exponen eventos de cambio a los datos, los cuales son usados por las aplicaciones para registrar las notificaciones de los cambios en los datos. El siguiente ejemplo de codificación muestra la definición de los manejadores de eventos ItemModified (Elemento modificado) e ItemRemoved (Elemento retirado) en la clase de Elemento base.

// Events public event Item odif iedEventHandler Item ItemModified; public event ItemRemovedEventHandler Item ItemRemoved: Todas las modificaciones transportan datos suficientes para recuperar el elemento cambiado del almacén de datos. El siguiente ejemplo de codificación muestra la manera de registrar eventos en un Elemento, Extensión de elemento o Relación de elemento: myltem. ItemModified += new ItemModifiedEventHandler(this.onltemUpdate); myltem. ItemRemoved += new ltemRemovedEventHandler(th¡s.onltemDelete); En esta modalidad, la plataforma de almacenamiento garantiza que las aplicaciones recibirán las notificaciones si el elemento respectivo se ha modificado o eliminado desde la última notificación entregada o en caso de un nuevo registro desde la última búsqueda del almacén de datos. b) Vigilantes En la presente modalidad, la plataforma de almacenamiento define las clases de observadores para supervisar los objetos asociados con una (1) carpeta o jerarquía de carpetas, (2) un contexto de elementos o (3) un elemento específico. Para cada una de las tres categorías, la plataforma de almacenamiento proporciona clases específicas de observadores que supervisan a los elementos asociados, extensiones del elemento o relaciones del elemento, por ejemplo, la plataforma de almacenamiento proporciona las clases respectivas de FolderltemWatcher (Observador de elementos de las carpetas), FolderRelationshipWatcher (Observador de relaciones de las carpetas) y FolderExtension Watcher (Observador de extensiones de carpetas). Cuando se crea un observador, una aplicación puede solicitar notificaciones para los elementos que existen previamente, es decir, elementos, extensiones o relaciones. Esta opción es principalmente para aplicaciones que mantienen una memoria intermedia privada para el elemento. Si no lo solicita, las aplicaciones reciben notificaciones sobre todas las actualizaciones que se producen después de la creación del objeto observador. Junto con la entrega de notificaciones, la plataforma de almacenamiento proporciona un objeto "WatcherState" (Estado observador). Este WatcherState se puede hacer en serie y guardarse en el disco. El estado observador se puede usar posteriormente para volver a crear el observador respectivo después de una falla o al volver a conectar después de salir de línea. El recién creado observador vuelve a generar notificaciones no reconocidas. Las aplicaciones indican la entrega de una notificación al invocar el método de exclusión "Exelude" en el estado observador respectivo que proporciona una referencia a una notificación.

La plataforma de almacenamiento entrega copias separadas de estado del observador a cada manejador de eventos. Los estados del observador recibidos en invocaciones posteriores del mismo manejador de eventos suponen la entrega de todas las notificaciones recibidas con anterioridad. A manera de ejemplo, el siguiente ejemplo de codificación muestra la definición del observador de un elemento de carpeta, FolderltemWatcher. public class FolderltemWatcher : Watcher { // Constructores public FolderltemWatcher Constructor (Folder folder); public FolderltemWatcher Constructor (Folder folder, Type ¡temType); public FolderltemWatcher Constructor2( Item Con- text context, Itemld folderld); public FolderltemWatcher Construct o r3 (Folder folder, Type itemType, FolderltemWatcherOptions options); public FolderltemWatcher Construct o r4( Item Context context, Itemld folderld, Type itemType); public FolderltemWatcher Construct or5(l- temContext context, Itemld folderld, Type itemType, FolderltemWatcherOptions options); // Properties public Itemld FolderltemWatcher Folderld fget;) public Type FolderltemWatcher ItemType {get;} public FolderltemWatcherOptions FolderltemWatcher Options get;) // Events public event ItemChangedEventHandler FolderltemWatcher ItemChanqed; } El siguiente ejemplo de codificación muestra la manera de crear un objeto observador de carpetas para supervisar el contenido de una carpeta. El observador genera notificaciones, es decir, eventos, cuando se agregan nuevos elementos de música o se actualiza los elementos de música existents, o bien se eliminan. Los observadores de carpetas supervisan una carpeta particular o todas las carpetas dentro de una jerarquía de carpetas. my FolderltemWatcher = new FolderltemWatcher(myFolder, typeof(Music)); myFolderltemWatcher.ltemChanged + = newltemChangedEventHandl er(this.onltemChanged); 2. Mecanismo para el seguimiento de cambios y generación de notificaciones La plataforma de almacenamiento proporciona un mecanismo simple y eficiente para dar seguimiento a los cambios en los datos y generar notificaciones. Un cliente recupera notificaciones en la misma conexión que se usa para recuperar datos. Esto simplifica enormemente las comprobaciones de seguridad, elimina la latencia y restricciones en las configuraciones posibles de red. Las notificaciones se recuperan al emitir afirmaciones seleccionadas. Para evitar la votación, los clientes pueden usar una característica para esperar "waitfor" que proporciona el motor de la base de datos 314. La figura 13 muestra el concepto básico de notificación de la plataforma de almacenamiento. Esta consulta de espera se puede ejecutar de manera sincronía, en cuyo caso el hilo de innovación se bloquea hasta que estén disponibles los resultados, o de manera asincrona, en cuyo caso el hilo no se bloquea y los resultados se devuelven en un hilo separado, siempre que esté disponible. Una combinación de esta función de espera "waitfor" y otra de selección "select" es atractiva para supervisar los cambios a los datos que se ajustan en un margen particular de datos, mientras se pueden supervisar los cambios al establecer un candado de notificación en el margen respectivo de datos. Esto aplica a varios escenarios de la plataforma de almacenamiento común. Los cambios a los elementos individuales se pueden supervisar de manera eficiente al establecer candados de notificación en el margen de datos respectivo. Los cambios a las carpetas y árboles de carpetas se pueden supervisar al establecer candados de notificaciones en los márgenes de trayecto. Los cambios a los tipos y subtipos se pueden supervisar al establecer candados de notificaciones en los márgenes de tipos. En general, existen tres fases diferentes asociadas con las notificaciones de procesamiento: (1) cambio a los datos o detección uniforme, (2) correlación de suscripción y (3) entrega de notificaciones. Excluyendo la entrega de notificaciones síncrona, es decir, la entrega de notificaciones como parte de la transacción que realiza el cambio de datos, la plataforma de almacenamiento puede implementar dos formas de entrega de notificaciones: 1) Detección inmediata de eventos: Se realiza la correlación de detección de eventos y la suscripción como parte de la transacción de actualización. Las notificaciones se insertan en una tabla supervisada por el suscriptor y 2) Detección diferida de eventos: La correlación de la detección de eventos y la suscripción se realiza después de haber realizado la transacción de actualización.

Posteriormente, el suscriptor real o un intermediario detecta eventos y genera las notificaciones. La detección inmediata de eventos requiere que se ejecute una codificación adicional como parte de las operaciones de actualización. Esto permite la captura de todos los eventos de interés incluyendo los eventos que indican un cambio de estado relativo. La detección diferida de eventos elimina la necesidad de agregar una codificación adicional para actualizar las operaciones. La detección de eventos se realiza a través del último suscriptor. La detección diferida de eventos pone en lotes, naturalmente, la detección de eventos y la entrega de eventos y se ajusta bien con la infraestructura de ejecución de consultas del motor 314 de la base de datos (por ejemplo, el servidor SQL).

La detección diferida de eventos se basa en un registro o traza dejada por las operaciones de actualización. La plataforma de almacenamiento mantiene un conjunto de relojes marcadores lógicos junto con las lápidas para los elementos de datos eliminados. Cuando se explora el almacén de datos en búsqueda de cambios, los clientes proporcionan un reloj marcador que define una marca de agua baja para detectar los cambios y un conjunto de relojes marcadores para evitar la duplicidad de notificaciones. Las aplicaciones pueden recibir notificaciones de todos los cambios que se produjeron después de la hora indicada por la marca de agua baja. Aplicaciones más sofisticadas con acceso a formularios de núcleo pueden optimizar y reducir adicionalmente el número de afirmaciones de SQL necesarias para supervisar un conjunto de elementos potencialmente grande al crear un parámetro privado y duplicar las tablas de filtros. Las aplicaciones que tienen necesidades especiales como las que deben soportar formularios enriquecidos pueden usar la estructura de seguimiento de cambios disponible para supervisar cambios y regenerar sus copias dinámicas privadas. Por la tanto, en una modalidad es preferible que la plataforma de almacenamiento implemente un enfoque de detección de eventos diferidos, como se describe con detalle en párrafos posteriores. a) Seguimiento de cambios Todas las definiciones de elementos, extensiones y relaciones del elemento transportan un identificador único. El seguimiento de cambios mantiene un conjunto de relojes marcadores lógicos para registrar . las horas de creación, actualización y eliminación de todos los elementos de datos. Las entradas de las lápidas se usan para representar los elementos de los datos eliminados. Las aplicaciones usan la información para supervisar de manera eficiente si un elemento, extensión de elemento o relación de elemento particular se ha añadido, actualizado o eliminado recientemente desde la última vez que la aplicación accedió al almacén de datos. El ejemplo a continuación ilustra este mecanismo. créate table [item-extension-relationship-table-templ- ate] ( identifier uniqueidentifier not nuil default newid( ) created bigint, not nuil, -- @ @ dbts when created updated bigint, not nuil, -- @ @ dbts when last updated Todos los elementos, extensiones de elementos y laciones eliminados se registran en una tabla de lápidas correspondiente. A continuación se muestra una plantilla: créate table [item-extension-relationship-tombstone table-template] ( identifier uniqueidentifier not nuil, deleted bigint not nuil, -- @ @ dbts when deleted, created bigint not nuil, -- @ @ dbts when created upated bigint not nuil, -- @ @ dbts when last updated ) Por razones de eficacia, la plataforma de almacenamiento mantiene un conjunto de tablas globales para los elementos, extensiones de los elementos, relaciones y nombres de trayecto. Esas tablas de búsqueda global las pueden usar las aplicaciones para supervisar de manera eficiente los márgenes de los datos y recuperar los relojes marcadores asociados así como la información de los tipos. b) Gestión del reloj marcador Los relojes lógicos son "locales" para un almacén de la base de datos, es decir, volumen de la plataforma de almacenamiento. Los relojes marcadores son monotónicos con valores que incrementan en 64-bit. la retención de un solo reloj marcador con frecuencia es suficiente para detectar si se ha producido un cambio en los datos después de la última conexión a un volumen de la plataforma de almacenamiento. Sin embargo, en escenarios más reales, deben mantenerse algunos relojes marcadores más para comprobar las duplicidades. La razón se explica posteriormente. Las tablas relaciónales son abstracciones lógicas integradas en la parte superior de un conjunto de estructuras de datos físicos, es decir, Árboles B, pilas, etcétera. La asignación de un reloj marcador a un registro recién creado o actualizado no es una acción que se realice de manera automática. La inserción de ese registro en las estructuras de datos subyacentes puede suceder en diferentes momentos, de esta manera las aplicaciones pueden ver los registros fuera de servicio. La figura 14 muestra dos transacciones, ambas insertan un nuevo registro en el mismo Árbol B. Debido a que la transacción T3 inserta su registro antes de que se programe la inserción de la transacción T2, una exploración de la aplicación del Árbol B puede ver los registros insertos por la transacción T3 antes de los que inserta T2. Así, el lector puede asumir de manera incorrecta que ha observado todos los registros creados hasta la vez "10". Para resolver esta situación, el motor de la base de datos 314 proporciona una función que devuelve una marca de agua baja con la que se comprometen todas las actualizaciones y se insertan en las estructuras de datos subyacentes respectivas. En el ejemplo anterior, la marca de agua inferior devuelta será "5," suponiendo que el lector inició antes de que se comprometiera la transacción T2. La marca de agua baja que proporciona el motor 314 de la base de datos permite que las aplicaciones determinen de manera eficiente los elementos que debe ignorar cuando explore la base de datos o un margen de datos para los cambios de los datos. En general, se supone que las transacciones ACID tienen una corta duración, de esta manera, se espera que las marcas de agua bajas estén muy cerca del reloj marcador que se suministró más recientemente. En presencia de transacciones de larga duración, las aplicaciones deben mantener relojes marcadores individuales para detectar y desechar duplicados. c) Detección de cambios en los datos -Detección de eventos Cuando se consulta al almacén de datos, las aplicaciones obtienen una marca de agua baja. Posteriormente, las aplicaciones usan la marca de agua para explorar el almacén de datos en búsqueda de entradas cuyo reloj marcador de creación, actualización o eliminación sea mayor que la marca de agua baja devuelta. La figura 15 ilustra este proceso.

Para evitar la duplicidad de notificaciones, las aplicaciones recuerdan los relojes marcadores que son mayores que una marca de agua baja devuelta y las usan para filtrar los duplicados. Las aplicaciones crean tablas temporales locales de sesión para manejar de manera eficiente un conjunto grande de relojes marcadores duplicados. Antes de emitir una información seleccionada, una aplicación inserta todos los relojes marcadores duplicados que se devolvieron previamente y elimina los anteriores a la marca de agua devuelta por última vez, como se ilustra a continuación. delete from $duplicates where ts < @ oíd LowWaterMark; inserí into $duplicates(ts) values(...)>··.( ··); waitfor( select *, getl_owWaterMark( ) as newLowWaterMark from [globalütems] where updated >= @oldLowWaterMark and updated not in (select * from $duplicates)) G. SINCRONIZACIÓN De conformidad con otro aspecto de la presente invención, la plataforma de almacenamiento proporciona un servicio de sincronización 330 que (i) permite que múltiples instancias de la plataforma de almacenamiento (cada una con su propio almacén de datos 302) sincronice partes de su contenido de conformidad con un conjunto flexible de reglas, y (ii) proporciona una infraestructura para terceras partes para sincronizar el almacén de datos de la plataforma de almacenamiento de la presente invención con otras fuentes de datos que implementan protocolos propietarios. La sincronización de plataforma de almacenamiento a plataforma de almacenamiento se produce entre un grupo de réplicas participantes. Por ejemplo, con referencia a la figura 3, puede ser deseable proveer la sincronización entre el almacén de datos 302 de la plataforma de almacenamiento 300 con otro almacén de datos 338 remoto bajo el control de otra instancia de la plataforma de almacenamiento, que tal vez se ejecuta en un sistema de cómputo diferente. La membresía total de este grupo no necesariamente se conoce en ninguna réplica determinada en algún momento. Las réplicas diferentes pueden hacer cambios de manera independiente es decir, de manera concurrente. El proceso de sincronización se define como hacer del conocimiento de los cambios hechos por otras réplicas a todas las réplicas. Esta capacidad de sincronización es inherentemente de varios maestros. La capacidad de sincronización de la presente invención permite réplicas para: • Determinar los cambios que conoce otra réplica; · Solicitar información sobre los cambios que esta réplica no conoce; • Transportar información sobre los cambios que la otra réplica no conoce; • Determinar cuando dos cambios están en conflicto entre sí; • Aplicar cambios localmente; • Transportar resoluciones de conflictos a otras réplicas para asegurar la convergencia; y • Resolver los conflictos con base en las políticas especificadas para las resoluciones de los conflictos. 1. Sincronización de plataforma de almacenamiento - plataforma de almacenamiento La aplicación primaria del servicio de sincronización 330 de la plataforma de almacenamiento de la presente invención es sincronizar múltiples instancias de la plataforma de almacenamiento (cada una con su propio almacén de datos). El servicio de sincronización funciona en el nivel de los esquemas de la plataforma de almacenamiento (en lugar de tablas subyacentes del motor de la base de datos 314). De esta manera, por ejemplo, "enfoques" se usa para definir los conjuntos de sincronización como se analiza a continuación. El servicio de sincronización funciona bajo el principio de "cambios netos". En lugar de registrar y enviar operaciones individuales (como con la réplica transaccional), el servicio de sincronización envía el resultado final de las operaciones, de esta manera consolidando con frecuencia los resultados de las operaciones múltiples en un cambio único resultante. El servicio de sincronización no respeta los límites de transacción en general. En otras palabras, si se hacen dos cambios en un almacén de datos de la plataforma de almacenamiento en una sola transacción, no existe una garantía de que estos cambios se apliquen a todas las réplicas de manera automática, una puede aparecer sin la otra. La excepción a este principio es que si dos cambios se hacen en el mismo elemento en la misma transacción, entonces se garantiza que estos cambios se enviarán y aplicarán a otras réplicas de manera automática. De esta manera, los elementos son las unidades de consistencia del servicio de sincronización. a) Aplicaciones de control de sincronización (Sync) Cualquier aplicación se puede conectar al servicio de sincronización e iniciar una operación de sincronización. Tal aplicación proporciona todos los parámetros necesarios para realizar la sincronización (véase el perfil Sync a continuación). Tales aplicaciones se denominan en la presente como aplicaciones de control de sincronización (SCA).

Cuando se sincronizan dos instancias en una plataforma de almacenamiento, se inicia la sincronización en un lado mediante las SCA. Dichas SCA informan al servicio de sincronización local que se debe sincronizar con el compañero remoto. Del otro lado, el servicio de sincronización recibe una alerta a través de un mensaje enviado por el servicio de sincronización desde la máquina de origen. Responde con base a la información de configuración persistente (véase correlaciones a continuación) presente en la máquina de destino. El servicio de sincronización se puede ejecutar programado o como respuesta a diversos eventos. En estos casos, el servicio de sincronización que implementa la programación se convierte en la SCA. Para habilitar la sincronización, es necesario realizar dos pasos. Primero, el diseñador de esquemas debe anotar el esquema de la plataforma de almacenamiento con la semántica de sincronización adecuada (designar las unidades de cambio como se describe a continuación). En segundo lugar, la sincronización debe considerarse de manera adecuada en todas las máquinas que tienen una instancia de la plataforma de almacenamiento que participan en la sincronización (como se describe a continuación). b) Anotación de esquemas Un concepto fundamental de los servicios de sincronización es el de una unidad de cambio. Una unidad de cambio es la pieza más pequeña del esquema que se rastrea de manera individual a través de la plataforma de almacenamiento. Para cada una de las unidades de cambio, el servicio de sincronización puede estar disponible para determinar si cambió o no cambió desde la última sincronización. La designación de unidades de cambio en el esquema sirve a múltiples propósitos. Primero, determina qué cantidad de información contiene el servicio de sincronización en el cable. Cuando se hace un cambio dentro de una unidad de cambio, la unidad de cambio completa se envía a las otras réplicas, ya que el servicio de sincronización no conoce qué parte de la unidad de cambio fue cambiada. En segundo lugar, determina la granularidad de la detección del conflicto. Cuando se hacen dos cambios concurrentes (estos términos se definen con detalle en secciones posteriores) a la misma unidad de cambio, el servicio de sincronización genera un conflicto, por otro lado, si los cambios concurrentes se hacen en diferentes unidades de cambio, entonces no se generan conflictos y los cambios se fusionan de manera automática. En tercer lugar, afecta en gran medida la cantidad de metadatos mantenidos en el sistema. Muchos de los metadatos en el servicio de sincronización se mantienen por unidad de cambio; de esta manera al hacer unidades de cambio más pequeñas se incrementa la sobrecarga de sincronización. La definición de las unidades de cambio requiere la búsqueda de los cambios correctos. Por esta razón, el servicio de sincronización permite que los diseñadores de esquema participen en el proceso. En una modalidad, el servicio de sincronización no soporta las unidades de cambio que son más grandes que un elemento. Sin embargo, soporta la capacidad de los diseñadores de esquema para especificar las unidades de cambio más pequeñas que un elemento, a saber, atributos múltiples de agrupamiento de un elemento en una unidad de cambio separada. En esa modalidad, esto se logra usando la siguiente sintaxis: <Type Name = "Appointment" MajorVersion = "1 " MinorVersion = "0" ExtendsType = "Base.ltem" Extends Version = " 1 "> <Field Name = "MeetingStatus" Type = "the storage platformTypes. un iqueidentifier Nullable = "False"/> <F¡eld Name = "OrganizerName" Type = "the storage platformTypes. nvarchar(512- )" Nullable = "False"/> <Field Name = "OrganizerEmail" Type = "the storage platformTypes.nvarchar(512)" Type ajorVersion = "1" MultiValued = "True'7> <ChangeUnit Name = "CU_Status"> <Field Name=" eetingStatus"/> </ChangeUnit> <ChangeUnit Name = "CU_0rganizer'7> <Field Name="OrganizerName" /> <Field Name="OrganizerEmail" /> </ChangeUnit> </Type> c) Configuración de sincronización Un grupo de compañeros de la plataforma de almacenamiento que desean mantener ciertas partes de sus datos en sincronía se denomina en la presente como comunidad de sincronización. Aunque los miembros de la comunidad desean mantenerse sincronizados, no necesariamente representan los datos de la misma exacta manera; en otras palabras, los compañeros de sincronización pueden transformar los datos que sincronizan. En una situación de cliente a cliente, no es práctico que los clientes mantengan las correlaciones de transformación para todos sus compañeros. En su lugar, el servicio de sincronización realiza un enfoque de definición de "carpetas de comunidad". Una carpeta de comunidad es una abstracción que representa una "carpeta compartida" con la que todos los miembros de la comunidad se sincronizan. Esta afirmación se ilustra a manera de ejemplo. Si Juan desea mantener las carpetas de "Mis documentos" de sus diversas computadoras en sincronización, Juan define una carpeta de comunidad denominada, digamos, documentos de Juan. Entonces, en todas las computadoras, Juan configura una correlación entre la carpeta hipotética documentos de Juan y la carpeta local de "Mis documentos". De aquí en adelante, cuando la computadora de Juan haga una sincronización con las demás, se comunicarán en términos de documentos en los documentos de Juan, en lugar de sus elementos locales. De esta manera, todas las computadoras de Juan se entienden sin tener que saber quienes son las otras, la carpeta de comunidad se convierte en la lengua franca de la comunidad de sincronización. La configuración del servicio de sincronización consiste en tres pasos: (1) definir correlaciones entre las carpetas locales y las carpetas de comunidad; (2) definir perfiles de sincronización que determinan lo que se sincroniza (por ejemplo, qué se debe sincronizar con qué y qué subconjuntos deben enviarse y cuáles recibirse); y (3) definir los programas en los que deben ejecutarse los perfiles de sincronización diferentes, o ejecutarlos de manera manual. (1) Correlaciones de las carpetas de comunidad Las correlaciones de la carpeta de comunidad se almacenan como archivos de configuración XML en máquinas individuales. Cada correlación tiene el siguiente esquema: /correlaciones/carpeta de comunidad Este elemento denomina la carpeta de comunidad con la que se correlaciona. El nombre sigue las reglas de sintaxis de las carpetas. /correlaciones/carpeta local Este elemento denomina la carpeta local en la que se transforma con la correlación. El nombre sigue las reglas de sintaxis de las carpetas. La carpeta ya debe existir para que la correlación sea válida. Los elementos dentro de esta carpeta se consideran para la sincronización para esta correlación. /correlaciones / transformaciones Este elemento define la manera de transformar elementos de la carpeta de comunidad a la carpeta local y de regreso. Si está ausente o vacía, no se realizan transformaciones. En particular, esto significa que no se correlacionan los ID. Esta configuración se usa principalmente para crear una memoria intermedia de una carpeta. /correlaciones / transformaciones / ID de correlación Este elemento solicita que los identificadores locales que se generen recientemente se asignen a todos los elementos correlacionados desde la carpeta de la comunidad, en lugar de volver a usar identificadores de la comunidad. El tiempo de ejecución de la sincronización mantiene las correlaciones de los identificadores para convertir los elementos de ida y de regreso. /correlaciones / transformaciones / raíz local Este elemento solicita que todos los elementos de raíz dentro de la carpeta de comunidad tengan elementos secundarios a partir de la raíz especificada. /Correlaciones / ejecutar cómo Este elemento controla bajo qué solicitudes de autoridad para esta correlación se procesan. Si está ausente, se asume que es un remitente. /Correlaciones / ejecutar cómo /remitente La presencia de este elemento indica que el remitente de mensajes para esta correlación debe ser imitada y las solicitudes se deben procesar bajo sus referencias. (2) Perfiles Un perfil de sincronización es un conjunto total de parámetros necesarios para iniciar la sincronización. Este se provee mediante por una SCA para que el tiempo de ejecución de la sincronización inicie la sincronización. Los perfiles de sincronización para la sincronización de la "plataforma de almacenamiento a plataforma de almacenamiento contienen la siguiente información: • Carpeta local, para servir como el origen y el destino para los cambios; • Nombre de la carpeta remota con la que se hará la sincronización, esta carpeta se debe publicar desde compañeros remotos a manera de correlación como se definió anteriormente; • Dirección, el servicio de sincronización soporta sólo envíos, sólo recepciones y sincronización de envíos y recepciones; · Filtro local, selecciona la información local que se envía al compañero remoto. Expresado como una consulta de la plataforma de almacenamiento sobre la carpeta local; • Filtro remoto, selecciona la información remota que se recupera desde el compañero remoto, expresado como una consulta de la plataforma de almacenamiento sobre la carpeta de comunidad; • Transformaciones, define cómo transformar los elementos hacia y desde el formato local; • Seguridad local, especifica si los cambios recuperados desde el punto de extremo remoto se aplican bajo el permiso del punto de extremo remoto (imitado) o el usuario que inicia localmente la sincronización; y • Política de resolución de conflictos, especifica si los conflictos se deben rechazar, ingresar o resolver automáticamente, en el último caso, especifica los conflictos a resolver para usar, así como los parámetros de configuración para éstos. El servicio de sincronización proporciona una clase de CLR en el tiempo de ejecución que permite la construcción simple de perfiles de sincronización. Los perfiles también pueden recibir una enumeración en serie hacia y desde los archivos XML para un almacenamiento fácil (con frecuencia junto a programaciones). Sin embargo, no hay un lugar estándar en la plataforma de almacenamiento en donde se almacenen todos los perfiles; se reciben los SCA para construir un perfil en el punto sin hacerlo persistente. Observe que no hay necesidad de tener una correlación local para iniciar la sincronización. Toda la información de sincronización se puede especificar en el perfil. Sin embargo, la correlación se requiere para responder a las solicitudes de sincronización iniciadas por el lado remoto. (3) Programaciones En una modalidad, el servicio de sincronización no proporciona su propia infraestructura de programación. En su lugar, se apoya en otros componentes para realizar esta tarea, el programador de Windows disponible con el sistema operativo Windows de Microsoft. El servicio de sincronización incluye una utilería de línea de comando que actúa como una SCA y activa la sincronización con base en un perfil de sincronización guardado en un archivo XML. Esta utilería facilita configurar el programador de Windows para ejecutar la sincronización ya sea con horario o como respuesta a los eventos como la entrada o salida del sistema de un usuario. d) Manejo de conflictos El manejo de conflictos en el servicio de sincronización se de divide en tres etapas: (1) detección del conflicto, lo que sucede al momento de aplicar el cambio, este paso determina si un cambio se puede aplicar de manera segura; (2) resolución y registro automático del conflicto, durante este paso, el cual se lleva a cabo de manera inmediata después de detectar el conflicto, se consulta a los elementos de resolución automática de conflictos para determinar si el conflicto se puede resolver, si no es así el conflicto se puede registrar opcionalmente; y (3) inspección y resolución del conflicto, este paso se desarrolla si algún conflicto se ha registrado y sucede fuera del contexto de la sección de sincronización, en este momento, los conflictos registrados se pueden resolver y eliminar del registro. (1) Detección de conflictos En la modalidad que se presenta, el servicio de sincronización detecta dos tipos de conflictos: basados en el conocimiento y basados en las restricciones. (a) Conflictos basados en el conocim iento Un conflicto basado en el conocimiento se produce cuando dos réplicas hacen cambios independientes a la misma unidad de cambio. Se invoca a dos cambios independientes si se hacen sin el conocimiento uno de otro, en otras palabras, el segundo no conoce la versión del primero y viceversa. El servicio de sincronización detecta automáticamente todos los conflictos con base en el conocimiento de las réplicas, como se describió anteriormente. Algunas veces es útil concebir los conflictos como bifurcaciones en el historial de versiones de una unidad de o cambio. Si no se producen conflictos durante la vida útil de una unidad de cambio, su historial de versión es una cadena simple, cada cambio que se introduce después del anterior. En el caso de un conflicto con base en el conocimiento, ocurren dos cambios en paralelo, ocasionando que la cadena se divida y se convierta en un árbol de versiones. (b) Conflictos basados en las restricciones Existen casos en donde los cambios independientes violan una restricción de integridad cuando se aplican en conjunto. Por ejemplo, dos réplicas que crean un archivo con el mismo nombre en el mismo directorio puede ocasionar que se produzca un conflicto tal. Un conflicto basado en las restricciones involucra dos cambios independientes (justo como el que se basa en el conocimiento), pero no afecta la misma unidad de cambio. En su lugar, afecta a diferentes unidades de cambio, pero con una restricción existente entre ellos. El servicio de sincronización detecta las violaciones de restricciones en el momento de la aplicación del cambio y emite de manera automática los conflictos basados en las restricciones. La resolución de los conflictos basados en restricciones usualmente requiere un código personalizado que modifique los cambios de una manera que no viole la restricción; el servicio de sincronización no provee un mecanismo de objetivo general para realizarlo. (2) Procesamiento de conflictos Cuando se detecta un conflicto, el servicio de sincronización puede realizar alguna de estas tres acciones (seleccionadas por el iniciador de sincronización en el Perfil de sincronización): (1) rechazar el cambio, volver a enviarlo nuevamente al remitente; (2) registrar un conflicto de una bitácora de conflictos; o (3) resolver el conflicto de manera automática. Si se rechaza el cambio, el servicio de sincronización actúa como si el cambio no hubiera llegado a la réplica. Se envía de regreso una negativa de conocimiento al originador. Esta política de resolución es útil principalmente en réplicas sin encabezado (por ejemplo servidores de archivo) en donde los conflictos de registro no son factibles. En su lugar, dichas réplicas fuerzan a las otras para lidiar con los conflictos rechazándolas. Los iniciadores de la sincronización configuran la resolución de conflictos en sus perfiles de sincronización. El servicio de sincronización da soporte a la combinación de múltiples elementos de resolución de conflictos en un solo perfil de las siguientes maneras, primero, al especificar una lista de elementos de resolución de conflictos que se probarán uno tras otro, hasta que uno de ellos lo logre; y segundo, al asociar a los elementos de resolución de conflictos con los tipos de conflicto, por ejemplo, al dirigir conflictos basados en el conocimiento de actualización a actualización hacia un elemento de resolución, pero todos los otros conflictos hacia la bitácora. (a) Resolución automática de conflictos El servicio de sincronización proporciona un número de elementos de resolución de conflictos predeterminados. Esta lista incluye: • Recuperaciones locales: no toma en cuenta los cambios entrantes si está en conflicto con los datos almacenados localmente; • Recuperaciones remotas: no toma en cuenta los datos locales si está en conflicto con los cambios entrantes; • Recuperaciones del último escritor: toma las recuperaciones locales o las recuperaciones remotas por unidad de cambio con base en el reloj marcador del cambio (observe que el servicio de sincronización en general no se basa en valores de reloj; este elemento de resolución de conflictos es la única excepción a esta regla); • Determinista: selecciona un ganador de una manera que se garantiza será la misma en todas las réplicas, más no significativa de otra manera, una modalidad de los servicios de sincronización usa comparaciones lexicográficas de los ID de compañero para implementar esta funcionalidad. Además, los ISV puede implementar e instalar sus propios elementos de resolución de conflictos. Los elementos de resolución de conflictos personalizados pueden aceptar parámetros de configuración; dichos parámetros se pueden especificar mediante la SCA de la sección de resolución de conflictos del perfil de sincronización. Cuando un elemento de resolución de conflictos maneja un conflicto, devuelve la lista de operaciones que se deben realizar (en lugar del cambio en conflicto) de regreso hacia el tiempo de ejecución. El servicio de sincronización entonces aplica estas operaciones, habiendo ajustado adecuadamente el reconocimiento remoto para disminuir lo que el manejador de conflictos consideró. Es posible que mientras se aplica la resolución se detecte otro conflicto. En tal caso, se debe resolver el nuevo conflicto antes de reiniciar el procesamiento original. Cuando se piensa en conflictos como ramificaciones en el historial de la versión de un elemento, las resoluciones de conflicto se pueden visualizar como uniones, que combinan dos ramas para formar un solo punto. De esta manera, las resoluciones de conflicto convierten los historiales de versiones en DAG. (b) Registro de conflictos Un tipo muy particular de un elemento de resolución de conflictos es el registrador de conflictos. El servicio de sincronización registra los conflictos como elementos de tipo ConflictRecord. Estos registros se relacionan con los elementos que están en conflicto (a menos que los elementos mismos se hayan eliminado). Cada registro de conflicto contiene: el cambio entrante que ocasionó el conflicto; el tipo del conflicto: actualización-actualización, actualización-eliminación, eliminación-actualización, inserción-inserción, o restricción; y la versión del cambio entrante y el conocimiento de la réplica que lo envía. Los conflictos registrados están disponibles para su inspección y resolución como se describe a continuación. (c) Inspección y resolución de conflictos El servicio de sincronización proporciona una API para que las aplicaciones examinen el registro de conflictos y sugieran resoluciones para los conflictos. La API permite que la aplicación enumere todos los conflictos, o los conflictos relacionados con un elemento determinado. También permite que dichas aplicaciones resuelvan conflictos registrados en una de tres formas: (1) recuperaciones remotas, aceptar el cambio registrado y sobrescribir el cambio local en conflicto; (2) recuperaciones locales, ignorar las partes en conflicto del cambio registrado; y (3) sugerir un cambio nuevo, en donde la aplicación propone una fusión que, en su opinión, resuelve el conflicto. Una vez que los conflictos se resuelven a través de una aplicación, el servicio de sincronización los retira del registro. (d) Convergencia de réplicas y propagación de resoluciones de conflictos En situaciones complejas de sincronización, el mismo conflicto se puede detectar en múltiples réplicas. Si esto sucede, diversas cosas pueden pasar: (1) el conflicto se puede resolver en una réplica, y la resolución se puede enviar a la otra; (2) el conflicto se resuelve en ambas réplicas de manera automática; o (3) el conflicto se resuelve en ambas réplicas manualmente (a través de la inspección del conflicto de la API). Para asegurar la convergencia, el servicio de sincronización envía las resoluciones de conflictos a otras réplicas. Cuando un cambio que resuelve un conflicto llega a la réplica, el servicio de sincronización encuentra automáticamente cualesquiera registros de conflictos en el registro que se resolvieron a través de esta actualización y las elimina. En este sentido, una resolución de conflictos en una réplica se vincula en todas las otras réplicas. Si se eligen diferentes soluciones a través de las réplicas diferentes para el mismo conflicto, el servicio de sincronización aplica el principio de resolución de conflictos por vinculación y elige una de las dos resoluciones para ejecutarla automáticamente. Ésta se elige de manera determinista que garantiza que produce el mismo resultado siempre (una modalidad usa comparaciones lexicográficas del ¡dentificador de réplica). Si diferentes réplicas sugieren "nuevos cambios" diferentes para el mismo conflicto, el servicio de sincronización trata este nuevo conflicto como un conflicto especial y usa el registrador de conflictos para evitar que se propague a otras réplicas. Dicha situación se presenta comúnmente con una resolución de conflictos manual. 2. Sincronización de almacenes de datos diferentes a la plataforma de almacenamiento De conformidad con otro aspecto de la plataforma de almacenamiento de la presente invención, la plataforma de almacenamiento proporciona una arquitectura para que los ISV implementen adaptadores de sincronización que permitan que la plataforma de almacenamiento sincronice los sistemas legados como Microsoft Exchage, AD, Hotmail, etc. Los adaptadores de sincronización se benefician de diversos servicios de sincronización proporcionados por el servicio de sincronización como se describe a continuación. A pesar del nombre, los adaptadores de sincronización no necesitan implementarse como unidades enchufables en algunas arquitecturas de plataforma de almacenamiento. Si se desea, un "adaptador de sincronización" simplemente puede ser cualquier aplicación que usa las ¡nterfaces del tiempo de ejecución del servicio de sincronización para obtener los servicios como la enumeración de cambios y la aplicación de éstos. Para simplificar la configuración y ejecución de la sincronización en un extremo final determinado, los escritores del adaptador de sincronización son alentados para que expongan la interfase del adaptador de sincronización estándar, la cual ejecuta la sincronización dado el perfil de sincronización como se describió anteriormente. El perfil proporciona información de configuración al adaptador, algunos de los adaptadores pasan al tiempo de ejecución de sincronización para controlar los servicios del tiempo de ejecución (por ejemplo, la carpeta a sincronizar). a) Servicios de Sincronización El servicio de sincronización proporciona un número de servicios de sincronización a los escritores del adaptador. Para el resto de esta sección, es conveniente referirse a la máquina en la que la plataforma de almacenamiento realiza la sincronización como el "cliente" y el extremo final de la plataforma que no es de almacenamiento del extremo final al que el adaptador se refiere como el "servidor". (1) Enumeración de cambios Con base en los datos del seguimiento de cambios mantenido por el servicio de sincronización, la enumeración de cambios permite que los adaptadores de sincronización enumeren fácilmente los cambios que se han producido en una carpeta del almacén de datos desde la última vez que se intentó realizar una sincronización con este compañero. Los cambios se enumeran con base en el concepto de "ancla", una estructura opaca que representa información sobre la última sincronización. El ancla toma la forma de Conocimiento de la plataforma de almacenamiento, como se describió en las secciones anteriores. Los adaptadores de sincronización que utilizan los servicios de numeración de cambios caen en dos amplias categorías: los que usan "anclas almacenadas" y los que usan "anclas provistas". La diferencia se basa en el lugar dónde se almacena la información sobre la última sincronización, en el cliente o en el servidor. Con frecuencia es más fácil que los adaptadores almacenen esta información en el cliente, el extremo posterior con frecuencia no es capaz de almacenar de manera conveniente esta información. Por otro lado, si múltiples clientes se sincronizan con el mismo extremo posterior, el almacenamiento de esta información en el cliente no es eficiente y en algunos casos es incorrecto, provoca que un cliente desconozca los cambios que el otro cliente ha presionado hacia el servidor. Si un adaptador desea usar un ancla almacenada en el servidor, el adaptador debe proveerla nuevamente a la plataforma de almacenamiento al momento de la enumeración del cambio. Para que la plataforma de almacenamiento mantenga el ancla (ya sea para un almacenamiento local o remoto), la plataforma de almacenamiento debe conocer los cambios que se aplicaron de manera satisfactoria al servidor. Estos y sólo estos cambios se pueden incluir en el ancla. Durante la enumeración de los cambios, los adaptadores de sincronización usan una interfase de confirmación para reportar los cambios que se aplicaron de manera satisfactoria. AI final de la sincronización, los adaptadores que usan las anclas provistas deben leer la nueva ancla (que incorpora todos los cambios aplicados satisfactoriamente) y enviarla al extremo posterior. Con frecuencia, los adaptadores deben almacenar datos específicos de los adaptadores junto con los elementos que insertan en el almacén de datos de la plataforma de almacenamiento. Ejemplos comunes de dichos datos son identificadores remotos y versiones remotas (relojes marcadores). El servicio de sincronización proporciona un mecanismo para almacenar estos datos y la enumeración de cambios provee un mecanismo para recibir estos datos adicionales junto con los cambios que se devuelven. Esto elimina la necesidad de que los adaptadores vuelvan a consultar la base de datos en la mayoría de los casos. (2) Aplicación de cambios La aplicación de cambios permite que los adaptadores de sincronización apliquen los cambios recibidos desde su extremo posterior hacia la plataforma de almacenamiento local. Se espera que los adaptadores transformen los cambios al esquema de plataforma de almacenamiento. La función primaria de la aplicación de los cambios es detectar automáticamente conflictos. Como en el caso de la sincronización de plataforma de almacenamiento a plataforma de almacenamiento, se define un conflicto como dos cambios traslapantes que se hacen sin que uno sepa del otro. Cuando los adaptadores usan la aplicación de cambios, deben especificar el ancla con respecto a la que se realizó la detección del conflicto. La aplicación de cambios genera un conflicto si se detecta un cambio local traslapante que no está cubierto por el conocimiento del adaptador. Similar a la enumeración de cambios, los adaptadores pueden usar anclas almacenadas o provistas. La aplicación de cambio soporta un almacenamiento eficiente de los metadatos específicos del adaptador. El adaptador puede anexar dichos datos a los cambios aplicados y se pueden almacenar a través del servicio de sincronización. Los datos pueden devolverse en la siguiente enumeración de cambios. (3) Resolución de conflictos Los mecanismos de resolución de conflictos descritos anteriormente (opciones de resolución automática y conexión al sistema) están disponibles para los adaptadores de sincronización también. Los adaptadores de sincronización pueden especificar la política para la resolución de conflictos al aplicar los cambios. Si especifica, los conflictos pueden pasar hacia el elemento de resolución de conflictos especificado y resolverse (si es posible). Los conflictos también se pueden registrar. Es posible que el adaptador detecte un conflicto cuando intenta aplicar un cambio local al extremo posterior. En cuyo caso, el adaptador puede aún pasar el conflicto a un tiempo de ejecución de sincronización que será resuelto de conformidad con la política. Además, los adaptadores de sincronización pueden solicitar que los conflictos detectados por el servicio de sincronización se envíen nuevamente a éstos para su procesamiento. Esto es particularmente cómodo en los casos donde el extremo posterior puede almacenar o resolver los conflictos. (b) Implementación del adaptador Aunque algunos "adaptadores" son simplemente aplicaciones que utilizan interfaces de tiempo de ejecución, los adaptadores se intensifican para que implementen las interfaces del adaptador estándar. Estas interfaces permiten que las aplicaciones de control de sincronización realicen lo siguiente: soliciten que el adaptador realice la sincronización de conformidad con un perfil de sincronización determinado; cancele la sincronización en curso y reciban los reportes del progreso (porcentaje completo) en una sincronización en curso. 3. Seguridad El servicio de sincronización se basa en la introducción de tan poco como sea posible en el modelo de seguridad implementado por la plataforma de almacenamiento. En lugar de definir nuevos derechos para la sincronización se usan los derechos ya existentes. Específicamente, • Cualquiera que pueda leer un elemento en el almacén de datos puede enumerar los cambios para dicho elemento ; • Cualquiera que pueda escribir en un elemento del almacén de datos puede aplicar los cambios a dicho elemento; y · Cualquiera que pueda extender un elemento en el almacén de datos puede asociar los metadatos de sincronización con dicho elemento. El servicio de sincronización no mantiene información de autoría segura. Cuando el usuario U hace un cambio en la réplica A y se transfiere a la réplica B, el hecho de que el cambio se haya realizado originalmente en A (o lo hay realizado U) se pierde. Si B transfiere este cambio a la réplica C, esto se realiza bajo la autoridad de B, no la de A. Esto conduce a la siguiente limitante: si no se confía en la réplica para que haga sus propios cambios en un elemento, no puede transferir los cambios hechos por otros. Cuando se inicia el servicio de sincronización, se realiza a través de una aplicación de control de sincronización. El servicio de sincronización imita la identidad de SCA y realiza todas las operaciones (tanto local como remota) bajo esa identidad. Para ilustrarlo, observe que el usuario U no puede hacer que el servicio de sincronización local recupere los cambios de una plataforma de almacenamiento remota para los elementos a los que el usuario U no tiene acceso de lectura. 4. Capacidad de gestión El monitoreo de una comunidad distribuida de réplicas es un problema complejo. El servicio de sincronización puede usar un algoritmo de "barrido" para recolectar y distribuir información sobre el estado de las réplicas. Las propiedades del algoritmo de barrido aseguran que la información de todas las réplicas configuradas se recolectan al final y que se detectan las réplicas con falla (que no responden). Esta información de monitoreo en toda la comunidad está disponible en todas las réplicas. Las herramientas de supervisión se pueden ejecutar en una réplica elegida de manera arbitraria para examinar esta información de supervisión y tomar las decisiones administrativas. Cualesquiera cambios de configuración deben hacerse directamente en las réplicas afectadas. H. INTEROPERABILIDAD CON EL SISTEMA DE ARCHIVOS TRADICIONAL Como se mencionó anteriormente, la plataforma de almacenamiento de la presente invención tiene la intención, al menos en algunas modalidades, de representar una parte integral del sistema de cómputo de interfases de componentes físicos de computación/programas y sistemas de programación. Por ejemplo, la plataforma de almacenamiento de la presente invención puede representarse como una parte integral de un sistema operativo, por ejemplo la familia Windows de Microsoft de los sistemas operativos. En esta capacidad, la API de la plataforma de almacenamiento se convierte en una parte de las API del sistema operativo a través de la cual los programas de aplicación interactúan con el sistema operativo. De esta manera, la plataforma de almacenamiento se convierte en los medios a través de los cuales los programas de la aplicación almacenan la información en el sistema operativo y el modelo de datos basado en elementos de la plataforma de almacenamiento, de esta manera, reemplaza el sistema de archivos tradicional de tal sistema operativo. Por ejemplo, como se representa en la familia Windows de Microsoft de sistemas operativos, la plataforma de almacenamiento puede reemplazar el sistema de archivos NTFS implementado en ese sistema operativo. Actualmente, los programas de aplicación acceden a los servicios del sistema de archivos NTFS a través de las API de Win32 expuestas por la familia de Windows de sistemas operativos. Sin embargo, reconocer que el reemplazo por completo del sistema de archivos NTFS con la plataforma de almacenamiento de la presente invención requeriría la recodificación de los programas de aplicación basados en Win32 y que dicha recodificación puede no ser deseada, sería benéfico para la plataforma de almacenamiento de la presente invención proveer alguna interoperabilidad con los sistemas de archivos existentes, por ejemplo NTFS. Por consiguiente, en una modalidad de la presente invención, la plataforma de almacenamiento habilita programas de aplicación que se basan en el modelo de programación Win32 para acceder al contenido tanto del almacén de datos de la plataforma de almacenamiento como al sistema de archivos tradicional NTFS. En este extremo, la plataforma de almacenamiento utiliza un convencionalismo de denominación que es un superconjunto de los convencionalismos de denominación de Win32 para facilitar una interoperabilidad sencilla. Adicionalmente, la plataforma de almacenamiento da soporte al acceso de archivos y directorios almacenados en un volumen de una plataforma de almacenamiento a través de la API de Win32. 1. Modelo de interoperabilidad De conformidad con este aspecto de la presente invención y de conformidad con la modalidad ejemplar que se analizó en párrafos anteriores, la plataforma de almacenamiento implementa un espacio de nombre en donde se pueden organizar elementos que son archivos y que no son archivos. Con este modelo se logran las siguientes ventajas: 1. Las carpetas en el almacén de datos pueden contener elementos que son archivos y que no son archivos, de esta manera presente un solo espacio de nombre para los datos esquematizados y para los archivos. Adicionalmente, también proporciona una seguridad uniforme que comparte un modelo de administración para todos los datos del usuario. 2. Ya que se puede tener acceso a elementos que son archivos y a los que no son archivos usando las API de la plataforma de almacenamiento y no se imponen reglas especiales para los archivos en este enfoque, presenta un modelo de programación más limpio de trabajo para los desabolladores de aplicaciones. 3. Todas las operaciones de nombre de espacio pasan a través de la plataforma de almacenamiento y por lo tanto se manejan de manera síncrona. Es importante señalar que la promoción de propiedad profunda (fuera del contenido del archivo) aún se produce de manera asincrona, pero las operaciones síncronas proporcionan un entorno mucho más predecible para los usuarios y las aplicaciones. Como consecuencia de este modelo, en la presente modalidad, es posible que las capacidades de búsqueda no se proporcionan sobre fuentes de datos que no migran al almacén de datos la plataforma de almacenamiento. Esto incluye los medios extraíbles, servidores remotos y archivos en el disco local. Se proporciona un adaptador síncrono que manifiesta los elementos proxy (atajos + metadatos promovidos) en la plataforma de almacenamiento para los elementos que se encuentran en sistemas de archivos externos. Los elementos proxy no intentan imitar a los archivos, ya sea en términos de la jerarquía de espacio de nombre de la fuente de datos o en términos de seguridad. La simetría lograda en el espacio de nombre y en el modelo de programación entre el contenido en los archivos y en elementos diferentes a archivos proporciona un trayecto mejor para que las aplicaciones migren el contenido de los sistemas de archivos a elementos más estructurados en almacén de datos de la plataforma de almacenamiento con el paso del tiempo. Al proporcionar un tipo de elemento de archivo nativo en el almacén de datos de la plataforma de almacenamiento, los programas de las aplicaciones pueden transferir los datos del archivo a otra plataforma de almacenamiento mientras aún pueden manipular estos datos a través de Win32. Finalmente, los programas de aplicación puede migrar a la API de la plataforma de almacenamiento completamente y estructurar sus datos en términos de elementos de la plataforma de almacenamiento en lugar de sólo archivos. 2 Características del almacén de datos Para proporcionar el nivel deseado de interoperabilidad, en una modalidad, las siguientes características del almacén de datos de la plataforma de almacenamiento se implementan. a) No es de volumen El almacén de datos de la plataforma de almacenamiento no se expone como un volumen del sistema de archivos separado. La plataforma de almacenamiento impulsa el FLUJO DE ARCHIVOS que están alojados directamente en el NTFS. De esta manera, no hay un cambio en el formato del disco, y así se elude la necesidad de exponer la plataforma de almacenamiento como un nuevo sistema de archivos en el nivel de volumen. En su lugar, un almacén de datos (espacio de nombre) se construye correspondiente a un volumen de NTFS. La base de datos y el FLUJO DE ARCHIVOS que respaldan esta porción del espacio de nombre se ubican en el volumen NTFS con el que se asocia el almacén de datos de la plataforma de almacenamiento. También se proporciona un almacén de datos que corresponde al volumen del sistema, b) Estructura del almacén La estructura del almacén se ilustra de mejor manera con un ejemplo. Considere, a manera de ejemplo, que el árbol del directorio del volumen del sistema de una máquina denominada HomeMachine, como se ilustra en la figura 16. De conformidad con la característica de interoperabilidad del sistema de archivos de la presente invención, lo que corresponde a la unidad c:\ drive, hay un almacén de datos de la plataforma de almacenamiento expuesto a las API de W¡n32 a través de la parte UNC, denominada, por ejemplo, "WinFSOnC". Esto hace que el almacén de datos asociado sea accesible a través del siguiente nombre de UNC: \\HomeMachine\WinFSOnC. En esta modalidad los archivos y/o carpetas deben migrar del NTFS hacia la plataforma de almacenamiento de manera explícita. De esta manera, si un usuario desea mover la carpeta MisDocumentos al almacén de datos de la plataforma de almacenamiento para aprovechar todas las características de búsqueda/categorización extra que ofrece la plataforma de almacenamiento , la jerarquía se verá como se muestra en la figura 17. Es importante observar que estas carpetas ya se movieron en este ejemplo. Otro punto importante que se debe observar es que el espacio de nombre cambia en la plataforma de almacenamiento, los flujos reales se vuelven a nombrar como FLUJOS DE ARCHIVO con los punteros apropiados enganchados dentro de la plataforma de almacenamiento c) No han migrado todos los archivos Los archivos que corresponden a los datos del usuario o que necesitan la búsqueda/categorización que proporciona la plataforma de almacenamiento son candidatos para la migración al almacén de datos de la plataforma de almacenamiento. Preferiblemente, para evitar los problemas de compatibilidad de los programas de la aplicación con la plataforma de almacenamiento, el conjunto de archivos que migran a la plataforma de almacenamiento de la presente invención, en el contexto del sistema operativo Windows de Microsft, se limitan a los archivos que se encuentran en la carpeta Mis Documentos, Favoritos del explorador de Internet (IE), Historial del explorador de Internet y los archivos Desktop.ini en el directorio Documents and Settings. Preferiblemente, no se permite la migración de los archivos de sistema de Windows. d) Acceso de espacio de nombre NTFS para los archivos de la plataforma de almacenamiento En la modalidad que se describe en este documento, es deseable que no se tenga acceso a los archivos migrados hacia la plataforma de almacenamiento a través del espacio de nombre NTFS aun que los flujos de archivos reales estén almacenados en el NTFS. De esta manera se evitan las complicadas consideraciones de bloque y seguridad que se presentan con una implementación de hilos múltiples. e) Letras esperadas para el espacio de nombre/unidades El acceso a los archivos y carpetas en la plataforma de almacenamiento lo proporciona un nombre UNC en la forma \\<nombre de la máquina >\<compartir nombre de Winfs>. Para la clase de aplicaciones que necesitan letras de unidad para su operación, una letra de unidad puede correlacionarse con este nombre de UNC. I. API DE LA PLATAFORMA DE ALMACENAMIENTO Como se mencionó en párrafos anteriores, la plataforma de almacenamiento comprende una API que habilita los programas de aplicación para acceder a las funcionalidades y capacidades de la plataforma de almacenamiento analizada anteriormente y para acceder a los elementos almacenados en el almacén de datos. Esta sección describe una modalidad de una API de la plataforma de almacenamiento de la plataforma de almacenamiento de la presente invención. La figura 19 ilustra la arquitectura básica de la API de la plataforma de almacenamiento, de conformidad con la presente invención; La API de la plataforma de almacenamiento utiliza SQLCIient 1900 para comunicarse con el almacén de datos local 302 y también puede usar el SQLCIient 1900 para comunicarse con los almacenes de datos remotos (por ejemplo, el almacén de datos 340). El almacén local 302 también se puede comunicar con el almacén de datos remoto 340 usando un DQP (procesador de consulta distribuida) o a través del servicio de sincronización de la plataforma de almacenamiento ("Sync") descrito anteriormente. La API 322 de la plataforma de almacenamiento también actúa como la API puente para las notificaciones del almacén de datos, pasa las suscripciones de la aplicación al motor de notificación 332 y enruta las notificaciones hacia la aplicación (por ejemplo, aplicación 350a, 350b ó 350c), como también se describió anteriormente. En una modalidad, la API 322 de la plataforma de almacenamiento también define una arquitectura limitada de "proveedor" de manera que puede acceder datos en Microsoft Exchange y AD. 1. Descripción general El mecanismo de acceso de datos de la presente modalidad de la API de la plataforma de almacenamiento de la presente invención se dirige a cuatro áreas: consulta, navegación, acciones, eventos. Consulta En una modalidad, el almacén de datos de la plataforma de almacenamiento se ímplementa en un motor de la base de datos relacional 314; como resultado, todo el poder de expresión del lenguaje SQL es inherente en la plataforma de almacenamiento. Los objetos de consulta de nivel superior proporcionan un modelo simplificado para hacer consultas al almacén, pero no encapsulan todo el poder de expresión del almacén. Navegación El modelo de datos de la plataforma de almacenamiento construye un sistema de tipo extensible en las abstracciones de la base de datos subyacente. Para el desarrollados los datos de la plataforma de almacenamiento son una red de elementos. La API de la plataforma de almacenamiento habilita la navegación de un elemento a otro a través del filtrado, relaciones, carpetas, etc. Éste es un nivel superior de abstracción que las consultas SQL base; al mismo tiempo, permite capacidades de filtrado y navegación enriquecidas para usar con los patrones de codificación de CLR ya conocidos. Acciones La API de la plataforma de almacenamiento expone acciones comunes en todos los elementos, Crear, Eliminar, Actualizar, éstas se exponen como métodos sobre los objetos. Además, las acciones específicas del dominio como Enviar correo, Comprobar movimientos libres, etc. también están disponibles como métodos. La estructura de la API usa patrones bien definidos que los ISV pueden usar para agregar valor al definir acciones adicionales. Eventos Los datos en la plataforma de almacenamiento son dinámicos. Para permitir que las aplicaciones reaccionen cuando los datos en el almacén cambian, la API expone capacidades de generación de eventos, suscripción y notificación enriquecidas para el desarrollados 2. Denominación y alcances Es útil distinguir entre el espacio de nombre y la denominación. El término espacio de nombre, como se usa comúnmente, se refiere al conjunto de todos los nombres disponibles dentro de algunas partes del sistema. El sistema puede ser un esquema XML, un programa, la red, el conjunto de todos los sitios ftp (y su contenido), etcétera. La asignación de nombres o denominación es el proceso o algoritmos que se usa para asignar nombres exclusivos para todas las entidades de interés dentro de un espacio de nombre. De esta manera, la denominación es interesante debido a que es deseable referirse a una unidad determinada sin equivocaciones dentro de un espacio de nombre. De esta manera, el término "espacio de nombre," como se usa en la presente se refiere al conjunto de todos los nombres disponibles en todas las instancias de la plataforma de almacenamiento en el universo. Los elementos son las entidades denominadas en el espacio de nombre de la plataforma de almacenamiento. El convencionalismo para la asignación de nombres de UNC se usa para asegurar la exclusividad de los nombres de los elementos. Cada elemento en todos los almacenes de datos de la plataforma de almacenamiento en el universo puede ser tratado por un nombre UNC. El nivel superior de la organización en el espacio de nombre de la plataforma de almacenamiento es un servicio, que simplemente es una instancia de la plataforma de almacenamiento. El siguiente nivel de organización es un volumen. Un volumen es el contenedor autónomo de elementos más grande. Cada instancia de la plataforma de almacenamiento contiene uno o más volúmenes. Dentro de un volumen hay elementos. Los elementos son átomos de datos dentro de la plataforma de almacenamiento. Los datos en el mundo real están casi siempre organizados de conformidad con algunos sistemas que tienen sentido en uri dominio determinado. La idea de dividir el universo de nuestros datos en grupos denominados es subyacente a todos los esquemas de organización de datos. Como se analizó anteriormente, esta ¡dea se trabaja en la plataforma de almacenamiento a través del concepto de una carpeta. Una carpeta es un tipo especial de elemento, hay 2 tipos de carpetas: Carpetas de contención y carpetas virtuales. Haciendo referencia a la figura 18, una carpeta de contención es un elemento que contiene Relaciones de pertenencia con otros elementos y que es el equivalente al concepto común de una carpeta en un sistema de archivos. Cada elemento está "contenido" dentro de al menos una carpeta de contención. Una carpeta virtual es una manera más dinámica de organizar una colección de elementos; simplemente es un nombre dado a un conjunto de elementos, el conjunto se enumera explícitamente o se especifica a través de una consulta. La carpeta virtual es un elemento y se puede concebir como la representación de un conjunto de relaciones (que no son de pertenencia) con un conjunto de elementos. En algunas ocasiones existe la necesidad de modelar una idea más estrecha de contención; por ejemplo, un documento de Word en un mensaje de correo electrónico, en un sentido, está unido más estrechamente a su contenedor que, por ejemplo, un archivo contenido dentro de una carpeta. Esta idea se expresa mediante el concepto de elementos incrustados. Un elemento incrustado tiene un tipo especial de relación, que hace referencia a otro elemento; el elemento al que hace referencia puede estar unido o de otra manera manipulado sólo dentro del contexto del elemento que lo contiene. Por último, la plataforma de almacenamiento proporciona la idea de categorías como una manera de clasificar los Elementos y sus elementos. Cada elemento dentro de la plataforma de almacenamiento puede tener una o más categorías asociadas. En esencia, una categoría es simplemente un nombre que está etiquetado en el elemento. Este nombre se puede usar para las búsquedas. El modelo de datos de la plataforma de almacenamiento permite la definición de una jerarquía de categorías, de esta manera habilita una clasificación de datos similar a un árbol. Un nombre inequívoco para un elemento es la tercia: (<NombredeServicio, <ldentificadordeVolumen>, <ldent¡ficadordeEIemento>). Algunos elementos (específicamente, Carpetas y Carpetas virtuales) son colecciones de otros elementos. Esto trae consigo una manera alternativa para identificar los elementos: (<NombredeServicio, <ldentificadordeVolumen>, <TrayectodeElemento>).

[0965] Los nombres de la plataforma de almacenamiento incluyen la idea de un contexto de servicio: un contexto de servicio es un nombre que correlaciona un par (<NombredeVolumen>, <trayecto>). Identifica un elemento o un conjunto de elementos, por ejemplo, una carpeta, una carpeta virtual, etc. Con el concepto de contextos de servicio, el nombre UNC para cualquier elemento en el espacio de nombre de la plataforma se convierte en: \<Nombredeservicio>\<Contextodeservicio>\<Trayectod eelemento> Los usuarios pueden crear y eliminar contextos de servicio. De igual manera, el directorio raíz de cada volumen tiene un contexto predefinido: volumen-nombre$. Un contexto de un elemento analiza una consulta (por ejemplo, una operación de búsqueda) limitando los resultados devueltos por los elementos que están activos dentro de un trayecto específico. 3. Componentes de la API de la plataforma de almacenamiento La figura 20 representa esquemáticamente los diversos componentes de la API de la plataforma de almacenamiento, de conformidad con la modalidad que se describe de la presente invención; La API de la plataforma de almacenamiento consiste en los siguientes componentes: (1) clases de datos 2002, que representan el elemento de la plataforma de almacenamiento y los tipos de elementos, (2) estructuras de tiempo de ejecución 2004, que gestiona la persistencia del objeto y proporciona clases de soporte 2006; y (3) herramientas 2008, que se usan para generar clases de CLR desde los esquemas de la plataforma de almacenamiento. De conformidad con un aspecto de la presente invención, en el momento del diseño, el autor del esquema presenta un documento del esquema 2010 y una codificación para los métodos de dominio 2012 al conjunto de las herramientas 2008 del momento de diseño de la API de la plataforma de almacenamiento. Estas herramientas generan las clases de datos 2002 del lado del cliente y el esquema del almacén 2014 y las definiciones de la clase del almacén 2016 para dicho esquema. "Dominio" se refiere a un esquema particular; por ejemplo, hablamos de los métodos de dominio para las clases dentro del esquema de Contactos, etc. Esta clase de datos 2002 las usa el desarrollador de la aplicación en el tiempo de ejecución, en vivo con las clases 2006 de la estructura del tiempo de ejecución de la API de la plataforma de almacenamiento, para manipular los datos de la plataforma de almacenamiento. Con el objetivo de ilustrar varios aspectos de la API de )a plataforma de almacenamiento de la presente invención, se presentan ejemplos con base en un esquema ejemplar de Contactos. Una representación gráfica de este esquema ejemplar se ilustra en las figuras 21A y 21B. 4. Clases de datos De conformidad con un aspecto de la presente invención, cada elemento, extensión de elemento y tipo de elemento, así como cada relación, en el almacén de datos de la plataforma de almacenamiento tiene una clase correspondiente en la API de la plataforma de almacenamiento. A groso modo, los campos del tipo se correlacionan con los campos de la clase. Cada elemento, extensión del elemento dentro de la plataforma de almacenamiento está disponible como un objeto de la clase correspondiente en la API de la plataforma de almacenamiento. El desarrollador puede hacer una consulta para crear, modificar o eliminar estos objetos. La plataforma de almacenamiento comprende un conjunto inicial de esquemas. Cada esquema define un conjunto de elemento y tipo de elemento, y un conjunto de relaciones. A continuación se presenta una modalidad de un algoritmo para generar clases de datos a partir de estas entidades de esquemas: Para cada esquema S: Para cada elemento, I, en S se genera una clase denominada System. Storage.S.I. Esta clase tiene los siguientes miembros: • Constructores sobrecargados, incluyendo constructores que permiten que se especifique una carpeta inicial de un elemento nuevo y un nombre.

• Una propiedad para cada campo en I. Si el campo tiene valores múltiples, la propiedad será una colección del tipo de elemento correspondiente. • Un método estático sobrecargado que encuentra varios elementos que corresponden al filtro (por ejemplo, un método denominado "FindAM" (Buscar todo)). • Un método estático sobrecargado que encuentra un solo elemento que corresponde a un filtro (por ejemplo, un método denominado "FindOne" (Encontrar uno)). · Un método estático que encuentra un elemento por su id (por ejemplo, un método denominado "FindBylD" (Buscar por ID)). • Un método estático que encuentra un elemento por su nombre con relación a un contexto de elemento (por ejemplo, un método denominado "FindBylD" (Buscar por nombre)). • Un método que gurda los cambios que se hacen al elemento (por ejemplo, un método denominado "Update" (Actualizar)). · La estática sobrecargada crea métodos que crean nuevas instancias del elemento. Estos métodos permiten que la carpeta inicial del elemento se especifique de varias maneras. Para cada elemento, E, en S se genera una clase denominada System . Storage. S . E . Esta clase tiene los siguientes miembros: • Una propiedad para cada campo en E. Si el campo tiene valores múltiples, la propiedad será una colección de los tipos de elemento correspondientes. Para cada elemento, E, en S se genera una clase denominada System. Storage.S.ECollection. Esta clase sigue los lineamientos de la estructura general NET para las clases de colección clasificadas sólidamente. Para los tipos de elementos basados en relaciones, esta clase también incluye los siguientes miembros: • Un método sobrecargado que encuentra múltiples objetos de elementos que corresponden a un filtro que incluye de manera implícita el elemento en el cual aparece la colección en el papel de origen. Las sobrecargas incluyen algunos que permiten el filtrado con base en el subtipo del elemento (por ejemplo, un método denominado "FindAIITargetltems" (Buscar en todos los elementos objetivo)). • Un método sobrecargado que encuentra un solo objeto de elemento que corresponde a un filtro que incluye de manera implícita el elemento en el cual aparece la colección en el papel de origen. Las sobrecargas incluyen algunos que permiten el filtrado con base en el subtipo del elemento (por ejemplo, un método denominado "FindOneTargetltem" (Buscar un elemento objetivo)).

• Un método sobrecargado que encuentra objetos del tipo de elemento anidado que corresponden a un filtro que incluye de manera implícita el elemento en el cual aparece la colección en el papel de origen (por ejemplo, un método denominado "FindAIIRelationships" (Buscar todas las relaciones)). • Un método sobrecargado que encuentra objetos del tipo de elemento anidado que corresponden a un filtro que incluye de manera implícita el elemento en el cual aparece la colección en el papel de origen (por ejemplo, un método denominado "FindAIIRelationshipsForTarget" (Buscar todas las relaciones para el objetivo)). • Un método sobrecargado que encuentra un solo objeto del tipo de elemento anidado que corresponde a un filtro que incluye de manera implícita el elemento en el cual aparece la colección en el papel de origen (por ejemplo, un método denominado "FindOneRelationship" (Buscar una relación)). • Un método sobrecargado que encuentra un solo objeto del tipo de elemento anidado que corresponde a un filtro que incluye de manera implícita el elemento en el cual aparece la colección en el papel de origen (por ejemplo, un método denominado "FindOneRelationshipForTarget" (Buscar una relación para el objetivo)). Para la relación, R, en S se genera una clase denominada System. Storage.S.R. Esta clase tiene una o dos subclases, que dependen de si uno o ambos papeles de relación especifican un campo para el punto final. Las clases también se generan de esta manera para cada extensión del elemento que se ha creado. Las clases de datos existen en el espacio de nombre System. Storage. <schemaName>, en donde <schemaName> es el nombre del esquema correspondiente, por ejemplo, Contactos, Archivos, etcétera. Por ejemplo, todas las clases que corresponden al esquema Contactos se encuentran en el espacio de nombre System. Storage. Contacts. A manera de ejemplo, haciendo referencia a las figuras 21A y 21B, el esquema de contactos produce las siguientes clases, contenidas en el espacio de nombre System. Storage. Contact: • Items (elementos): Item (elemento), Folder (carpeta), WelIKnownFolder (carpeta ya conocida), LocalMachineDataFoIder (carpeta de datos de la máquina local), UserDataFolder (carpeta de datos del usuario), Principal, Service (servicio), GroupService (servicio de grupo), PersonService (servicio de persona), PresenceService (servicio de presencia), ContactService (servicio de contacto), ADService (servicio de AD), Person (persona), User (usuario), Group (grupo), Organization (organización), HouseHold (doméstico).

• Elements (elementos): NestedElementBase (base de elemento anidado), NestedElement (elemento anidado), IdentityKey (clave de identidad), SecuritylD (identidad de seguridad), EAddress (dirección electrónica), ContactEAddress (dirección de contacto), TelehoneNumber (número de teléfono), SMTPEAddress (direción electrónica de SMTP), I nstantMessagingAddress (dirección de mensajería instantánea), Témplate (plantilla), Profile (perfil), FullName (nombre completo), FamilyEvent (evento familiar), BasicPresence (presencia básica), WindowsPresence (presencia de ventanas), Relationship (relación), TemplateRelationship (relación de plantilla), LocationRelationship (relación de ubicación), FamilyEventLocationRelationship (relación de ubicación de evento de familia), HouseHoldLocationRelationship (relación de ubicación doméstica), RoleOccupancy (ocupación de rol), EmployeeData (datos de empleado), GroupMemberShip (membresía de grupo), OrganizationLocationRelationship (relación de ubicación de organización), HouseHoldMemberData (datos de miembro doméstico), FamilyData (datos de familia), SpouseData (datos del cónyuge), ChildData (datos de los hijos). A manera de ejemplo, la estructura detallada del tipo Person (persona), como se define en el esquema Contacts (contactos), se muestra en XML a continuación: <Type Name = "Person" MajorVersion = "1 " MinorVersion ExtendsType = " Core. Principal" ExtendsVersion = "1' <Field Name = "Birthdate" Type = "the storage platformTypes.datetime" Nullable = "true" TypeMajorVersion = "1 "/> <Field Name = "Gender" Type = "Base.CategoryRef Nullable = "true" MultiValued = "false TypeMajorVersion < Field Name = "PersonaINames" Type = "Contact.FulIName" Nullable = "true" MultiValued = "true" TypeMajorVersion = " 1 "/> <Field Name = "PersonalEAddresses Typ e = "Core.EAddress Nullable="true" MultiValued = "true TypeMajorVersion = " 1 "/> <Field Name = " PersonalPostalAddresses Type = "Core.PostalAddress Nullable = "true MultiValued = "true" TypeMajorVersion = "1 "/> <FieId Name = "PersonalPicture" Type = "t e storage platformTypes. i m age" Nullable = "true" TypeMajorVersion = "1 "/> <Field Name = "Notes" Type = "Core. ichText" Nullable = "true" Muit¡VaIued = "true" TypeMajorVersion = "1 "/> <Field Name = "Profess¡on" Type = "Base.CategoryRef" Nullable = "true" MultiValued = "true" Type ajorVersion = "1 "/> <FieId Name = "DataSource" Type="Base. IdentityKey" Nullable="true" Mult¡Valued = "true" TypeMajorVers¡on = "1 "/> <FieId Name = "Exp¡rationDate" Type = "the storage platformTypes.datetime" Nullable="true" TypeMajorVersion = "1 "/> <F¡eld Name = "HasAIIAddressBookData" Type = "the storage platformTypes. bit" ullable="true" TypeMajorVers¡on = "1 "/> <Field Name = "EmployeeOf" Type = "Contact. EmployeeData" Nullable = "true" Mult¡Valued = "true" TypeMajorVersion = "1"/> </Type> Este tipo genera la siguiente clase (sólo se muestra los miembros públicos): partial public class Person : System. Storage. Core. Principal, System. Windows. Data. IdataUnit { public System. Data. SqlTypes.SqIDateTi me Birthdate { get; set; } public System. Storage. Base. CategoryRef Gender { get; set: } public System. Storage. Contact. Ful INameCollect ion PersonalNames { get; } public Sy stem. Storage. Co re. EaddressCoIlect ion PersonalEAddresses { get; } public System. Storage. Core. Pos ta lAdd re ssCollect ion Personal Postal Addresses { get; } public System. Data. SqlTypes.SqIBinary PersonalPicture { get; set; } public System. Storage. Core. RichTextColIect ion Notes { get; } public System. Storage. Base. CategoryRefCollect ion Profession { get; } public System. Storage. Base. IdentityKeyCollection DataSource { get; } public System. Data. SqlTypes.SqIDateTi me Expiration Date { get; set; } public S stem.Data.SqlTypes.SqlBoolean HasAllAddressBookData { get; set; } public System. Storage. Contact.Em pío ye eDataCollect ion EmpIoyeeOf { get; } public Person( ); public Person( System. Storage. Base. Folder folder, string ñame ); public static new System. Storage. FindResult F i n d Al I ( System. Storage. ItemStore store ); public static new System. Storage. FindResult FindAI l( System. Storage. ItemStore store, string filter ); public static new Person FindOne( System. Storage. ItemStore store, string filter ); public new event System. Windows. Data. Pro pe rtyChangedEventHandler PropertyChangedHandler; public static new Person FindBylD( System. Storage. ItemStore store, long item_key ); } Como un ejemplo más, la estructura detallada del tipo Telephone Number (número telefónico), como se define en el esquema Contacts (contactos), se muestra en XML a continuación : <Type Name = "TelephoneNumber" ExtendsType = "Core.EAddress" ajorVersion = "1 " MinorVersion = "0" ExtendsVersion = "1 "> <Field Name = "CountryCode" Type = "the storage platformTypes.nvarchar(50)" Nullable = "true" MultiValued = "faIse" TypeMajorVersion = "1"/> <F¡eld Name = "AreaCode" Type = "the storage platformTypes.nvarchar(256)" Nullable = "true" Type ajorVersion = "1"/> <Field Name = "Number" Type = "the storage platformTypes.nvarchar(256)" Nullable = "true" T peMajorVersion = "1 "/> <Field Name="Extension" Type = "the storage platformTypes.nvarchar(256)" Nullable = "true" TypeMajorVers¡on = "1"/> <Fíeld Name = "PIN" Type = "the storage platformTypes. nvarchar(50)" ullable = "true" TypeMajorVersion = "1"/> </Type> Este tipo genera la siguiente clase (sólo se muestra los miembros públicos): partial public class TelephoneNumber : System .Storage. Core. EAddress System. Windows. Da ta. IdataUnit { public System. Data. SqlTypes.SqiString CountryCode { get; set; } public System. Data. SqlTypes.SqiString AreaCode { get; set; } public System. Data. SqlTypes.SqiString Number { get; set; } public System. Data. SqlTypes.SqiString Exten { get; set; } public System. Data. SqlTypes.SqiString PIN { get; set; } public TelephoneNumber( ); public new event System. Windows. Data. PropertyChangedEventHandler PropertyChangedHandler; } La jerarquía de las clases que se obtienen de un esquema directamente refleja los tipos de jerarquía de los tipos en ese esquema. A manera de ejemplo, considere que los tipos de elementos definidos en el esquema Contacts (contactos) (véase las figuras 21A y 21B). La jerarquía de clases que corresponde a lo mencionado en la API de la plataforma de almacenamiento será como se indica a continuación: Object DataClass ElementBase RootltemBase Item Principal Group Household Organization Person User Service PresenceService ContactService ADService RootNesíedBase ... (Element classes) Otro esquema más, el esquema que permite representar todos los medios de audio/vídeo en el sistema (archivos de audio rasterizados, CD de audio, DVD, vídeos caseros, etc.), habilita a los usuarios/aplicaciones para almacenar, organizar, buscar y manipular diferentes tipos de medios de audio/vídeo. El esquema de documentos de los medios base son lo suficientemente genéricos para representar a cualquier medio, y las extensiones para este esquema base están diseñados para manejar las propiedades específicas del dominio por separado para los medios de audio y vídeo. Este esquema, además de otros, se pronostica que operará de manera directa o indirecta bajo el esquema núcleo. 5. Estructura del tiempo de ejecución El modelo de programación de la API de la plataforma de almacenamiento básico es de persistencia del objeto. Los programas de aplicación (o "aplicaciones") ejecutan una búsqueda en un almacén y recuperan objetos que representan los datos . en el almacén. Las aplicaciones modifican los objetos recuperados o crean objetos nuevos, después hacen que sus cambios sean propagados en el almacén. Este proceso lo gestiona un objeto de ItemContext (Contexto de objeto). Las búsquedas se ejecutan usando un objeto ItemSearcher (Buscador de elemento) y se tiene acceso a los resultados de la búsqueda a través de un objeto FindResult (Resultado de la búsqueda). a) Clases de estructuras del tiempo de ejecución De conformidad con otro aspecto novedoso de la API de la plataforma de almacenamiento, la estructura del tiempo de ejecución ¡mplementa un número de clases que soportan la operación de las clases de datos. Estas clases de estructura definen un conjunto común de conductas para las clases de datos y, junto con las clases de datos, proporcionan el modelo de programación básico para la API de la plataforma de almacenamiento. Las clases de la estructura del tiempo de ejecución pertenecen al espacio de nombre System . Storage (Sistema. Almacén). En esta modalidad, las clases de estructura comprenden las siguientes clases principales: ItemContext (Contexto de elemento), ItemSearcher (Buscador de elemento) y FindResult (Resultados de la búsqueda). Se pueden proporcionar otras clases menores, como enumeración de valores y delegados. (1) Contexto del elemento (ItemContext) Un objeto ItemContext (i) representa un conjunto de dominios de un elemento que desea buscar un programa de aplicaciones, (¡i) mantiene la información del estado para cada objeto que representa el estado de los datos como se recuperan de la plataforma de almacenamiento, y (iii) gestiona las transacciones usadas cuando interactúa con la plataforma de almacenamiento y cualquier sistema de archivos con el cual puede ¡nteractuar. Como un motor de persistencia de objeto, ItemContext proporciona los siguientes servicios: 1. Deserializa los datos que lee en el almacén en objetos. 2. Mantiene la identidad del objeto (el mismo objeto se usa para representar un elemento determinado, sin importar cuántas veces ese elemento se incluye en el resultado de las consultados). 3. Rastrea el estado del objeto. ItemContext también realiza diversos servicios exclusivos en la plataforma de almacenamiento: 1. Genera y ejecuta las operaciones de actualización de la plataforma de almacenamiento necesarias para continuar con los cambios. 2. Crea conexiones con varios almacenes de datos como sea necesario para habilitar una navegación uniforme de las relaciones de referencia y para permitir que los objetos recuperados de una búsqueda en varios dominios se modifique y guarde. 3. Asegura que los elementos con archivo de copia de seguridad se actualicen apropiadamente cuando los objetos que representan al objeto se guardan. 4. Gestiona las transacciones entre las múltiples conexiones de la plataforma de almacenamiento y, cuando se actualizan los datos almacenados en los elementos con copia de seguridad y las propiedades del flujo de archivos, el sistema de archivos negociado. 5. Realiza las acciones de creación, copiado, desplazamiento y eliminación que toman en cuenta la semántica de la relación de la plataforma, elementos con archivo con copia de respaldo y las propiedades del tipo de flujo. El Apéndice A proporciona una lista de códigos fuente de las clases de ItemContext, de conformidad con una modalidad del mismo. (2) Buscador de elementos (ItemSearcher) La clase ItemSearcher da soporte a búsquedas simples, las cuales devuelven objetos de elementos completos, flujos de objetos de elementos, o flujos de valores proyectados de elementos. ItemSearcher encapsula la funcionalidad núcleo que es común para todos estos: el concepto de un tipo objeto y filtros de parámetros que se aplican á ese tipo de objetivo. El ItemSearcher también permite que los buscadores se compilen previamente, o se preparen, como una optimización cuando se ejecutará la misma búsqueda para varios tipos. El Apéndice B proporciona una lista de códigos fuente de la clase ItemSearcher y de diversas clases relacionadas de manera cercana, de conformidad con una modalidad de la misma. (a) Tipo de objetivo La búsqueda por tipo de objetivo se establece cuando se construye un ItemSearcher (Buscador de elementos). El tipo de objetivo es un tipo CLR que se correlaciona en un grado al que se puede consultar a través del almacén de datos. Específicamente, es un tipo CLR que se correlaciona con los tipos de elemento, relación y extensión de elemento así como con formularios esquematizados. Cuando se recupera un buscador usando el método ItemContext.GetSearcher (ContextodeElemento.ObetenerBuscador), el tipo de objetivo del buscador se especifica como un parámetro. Cuando se invoca un método estático GetSearcher (ObtenerBuscador) en un tipo elemento, relación o extensión de elemento (por ejemplo, Person. GetSearcher (Persona. ObtenerBuscador), el tipo del objetivo es el tipo de elemento, relación, o extensión de elemento. Las expresiones de búsqueda que se proporcionan en un ItemSearcher (BuscadordeElementos), por ejemplo, el filtro de búsqueda y a través de las opciones de búsqueda o definiciones de proyección) siempre son relativas al tipo de objetivo de búsqueda. Estas expresiones pueden especificar propiedades del tipo de objetivo (incluyendo las propiedades de los elementos anidados) y pueden especificar uniones con extensiones de elemento y relación como se describió en este documento. El tipo de objetivo de búsqueda se hace disponible a través de una propiedad de sólo lectura (por ejemplo, una propiedad ItemSearcher.Type (BuscadordeElementos.Tipo)). (b) Filtros La clase ItemSearcher (Buscador de elemento) contiene una propiedad para especificar filtros (por ejemplo, una propiedad denominada "Filtros" como una colección de objetos Search Expression (Expresión de búsqueda) que define el filtro usado en la búsqueda. Todos los filtros de la colección se combinan usando una lógica y un operador cuando se ejecuta la búsqueda. El filtro puede contener referencias de parámetros. Los valores de los parámetros se especifican a través de la propiedad Parameters (parámetros). (c) Preparación de búsquedas En las situaciones donde se ejecutará la misma búsqueda de manera repetida, posiblemente con sólo cambios de parámetros, se puede obtener alguna mejora en el rendimiento al hacer una compilación previa, o al preparar la búsqueda. Esto se logra con un conjunto de método preparados en ItemSearcher, por ejemplo, un método para preparar una búsqueda que devuelve uno o más elementos, tal vez denominada "PrepareFind" (Preparar búsqueda), y un método para preparar una búsqueda que devuelve una proyección, denominada tal vez "PrepareProject" (Preparar proyecto)). Por ejemplo: ItemSearcher searcher = ...; PreparedFind pf = searcher. PrepareFind( ); result = pf.FindAII( ); result = pf.FindAII( ); (d) Opciones de búsqueda Existen diversas opciones que se pueden aplicar a una búsqueda simple. Éstas se pueden especificar, por ejemplo, en un objeto FindOptions (Buscar opciones) y pasar a los métodos de búsqueda. Por ejemplo: ItemSearcher searcher=Person.GetSearcher(context); FindOptions options = new FindOptions( ); options.MaxResults = 0; options. So rtOptions.Add(" Personal Na mes. Su mame", SortOrder.Ascending); FindResult result=searcher.FindAII(opt¡ons); Para que sea más cómodo, también pueden pasar opciones de clasificaciones directamente a los métodos de búsqueda: ItemSearcher searcher = Person.GetSearcher( context ); FindResult result = searcher. FlndAII( new SortOption( "PersonalNames.Surname", SortOrder.Ascending ) ); La opción DelayLoad (demorar la carga) determina si los valores de las propiedades se cargan cuando los resultados de búsqueda se recuperan o si la carga se demora hasta que se hace una referencia a éstos. La opción MaxResuIts (resultados máximos) determina el número máximo de resultados que se devuelven. Éste es equivalente a la especificación de TOP en una consulta de SQL. Se usa con mayor frecuencia en conjunto con la clasificación. Una secuencia de objetos SortOption (Clasificar las opciones), por ejemplo, al usar una propiedad FindOptions.SortOptions (BuscarOpciones.ClasificarOpciones). Los resultados de búsqueda se clasifican como especifica el primer objeto SortOption (Clasificar la opción), después como lo especificó el segundo objeto SortOption, etc. SortOption especifica una expresión de búsqueda que indica la propiedad que se usará para la clasificación. La expresión especifica uno de los siguientes: 1. Una propiedad escalar en el tipo de objetivo de búsqueda; 2. Una propiedad escalar en un elemento anidado al que se puede llegar desde el tipo de objetivo de búsqueda al cruzar propiedades con valor único; o 3. El resultado de una función de agregación con un argumento válido (por ejemplo, el máximo aplicado a una propiedad escalar en un elemento anidado que se puede alcanzar desde el tipo de objetivo de búsqueda al cruzar una propiedad de valores múltiples o una relación). Por ejemplo, suponga que el tipo de objetivo de búsqueda es System. Storage.Contact.Person (Sistema. Almacén. Contacto. Persona): 1. "Birthdate" — válido, fecha de cumpleaños es una propiedad escalar del tipo Person (persona); 2. "PersonalNames.Surname" — No válido, PersonalNames (nombres personales) es una propiedad de valores múltiples y no se usa ninguna función de agregación; 3. "Count(PersonalNames)"--Válido, el conteo de los nombres personales. 4. "Case(Contact.MemberOfHousehold). Household. Hous eholdEAddresses.StartDate" - No válido, usa propiedades de relación y de valores múltiples sin una función de agregación. 5. "Max(Cast(Contact. emberOf Household). Household. HouseholdEAddresses.Star tDate)"--Válido, fecha de inicio de la dirección electrónica más reciente. (3) Flujo de resultados del elemento ("FindResult") El ItemSearcher (Buscador de elementos), por ejemplo, a través del método FindAII (Buscar todo), devuelve un objeto que se puede usar para acceder a los objetos que devuelve la búsqueda (por ejemplo, un objeto "FindResult" (Buscar resultados)). El Apéndice C proporciona una lista de códigos fuente de la clase FindResult y de diversas clases relacionadas de manera cercana, de conformidad con una modalidad de la misma. Hay dos diferentes métodos para obtener resultados de un objeto FindResult (Buscar resultados): al usar el patrón de lectura definido por lObjectReader (y lAsyncObjectReader) además de usar el patrón enumerador como se define por lEnumerable y lEnumerator. El patrón del enumerador es estándar en la CLR y soporta constructos de lenguaje como C# para cada uno. Por ejemplo: ItemSearcher searcher = Person.GetSearcher( context ); searcher.Filters.Add( "PersonalNames.Surname = 'Smith'" ); FindResult result = searcher. FindAII( ); foreach( Person person in result ) El patrón de lectura está soportado debido a que permite que se procesen los resultados de manera más eficiente al eliminar una copia de los datos en algunos casos. Por ejemplo: ItemSearcher searcher = Person. GetSearcher( context ); searcher.Filters.Add( "PersonalNames.SurName = 'Smith'" ); FindResult result = searcher. FindAII( ); while( result. Read( ) ) { Person person = (Person)result.Current; ... } Además, el patrón de lectura soporta la operación asincrona: ItemSearcher searcher = Person. GetSearcher( context ); searcher. Filters.Add( "PersonalNames.SurName = 'Smith'" ); FindResult result = searcher. F¡ndAII( ); lAysncResult asyncResult = result. BeginRead( new AsyncCallback( MyCallback ) ); void MyCallback( lAsyncResult asyncResult ) { if( result. EndRead( asyncResult ) ) { Person person = (Person)result.Current; } } En la modalidad que se presenta se debe cerrar FindResuIt cuando ya no se necesite. Esto se puede hacer al invocar el método para cerrar, Cióse, usando un lenguaje de constructos como C# que usan una afirmación. Por ejemplo: ItemSearcher searcher = Person.GetSearcher( context ); searcher.FiIters.Add( "PersonalNames.SurName = 'Smith'"); using( FindResuIt result = searcher. F i n d Al I ( ) ) { while( result. Read( ) ) { Person person = (Person)result.Current; } } b) Estructura del tiempo de ejecución en operación La figura 22 ilustra la estructura del tiempo de ejecución en operación. La estructura del tiempo de ejecución opera como se indica a continuación: 1. Una aplicación 350a, 350b ó 350c se une a un elemento en la plataforma de almacenamiento; 2. La estructura 2004 crea un objeto ItemContext 2202 que corresponde al elemento unido y lo regresa a la aplicación; 3. La aplicación presenta una búsqueda en este ItemContext para obtener una colección de elementos; la colección devuelta conceptualmente es una gráfica objeto 2204 (debido a las relaciones); 4. La aplicación cambia, elimina e inserta datos; 5. La aplicación guarda los cambios al invocar el método de actualización Update(). c) Patrones de programación común Esta sección proporciona una variedad de ejemplos sobre la manera en las clases de la estructura de la API de la plataforma de almacenamiento se pueden usar para manipular los elementos en el almacén de datos. (1) Abertura y cierre de los objetos de contexto del elemento (ItemContext) Una aplicación obtiene el objeto ItemContext y lo usa para interactuar con el almacén de datos, por ejemplo, al invocar un método estático ItemContext. Open (ContextodeElemento.Abrir) y proporcionar el trayecto o los trayectos que identifican los dominios del elemento que se asocian con el ItemContext. Los dominios del elemento analizan las búsquedas realizadas usando ItemContext de manera que sólo el elemento del dominio y los elementos contenidos en ese elemento se someterán a la búsqueda. Los ejemplos son como se indica a continuación: Abrir un ItemContext (Contexto de elemento) con la parte de la plataforma de almacenamiento del almacén predeterminado ItemContext ¡c=ltemContext.Open( ); Abrir un ItemContext con una parte de la plataforma de almacenamiento determinada ItemContext ic=ltemContext.Open(@"\\myserver1\DefaultStore"); Abrir un ItemContext con un elemento debajo de una parte de la plataforma de almacenamiento ItemContext i c= ItemContext. O pe n(@"\\myserver1 \ WinFSSpecs\api\m6"); Abrir un ItemContext con varios dominios del elemento ItemContext ic=ltemContext.Open(@ "Wmyserver \My Documents", @"Wjane1 \My Documents", @"Wjane2\My Documents"; Cuando un ItemContext ya no se necesita, debe estar cerrado. Cerrar de manera explícita un ItemContext ItemContext ic = ItemContext. Open( ); ic.Close( ); Cerrar usando una afirmación con un ItemContext using( ItemContext ic = ItemContext. Open( ) ) { } (2) Búsqueda de objetos De conformidad con otra aspecto de la presente invención, la API de la plataforma de almacenamiento proporciona un modelo de consulta simplificado que permite que los programadores de la aplicación formulen consultas con base en varias propiedades de los elementos del almacén de datos, en una manera que aisla al programador de la aplicación de los detalles del lenguaje de consulta del motor de la base de datos subyacente. Las aplicaciones pueden ejecutar una búsqueda en los dominios especificados cuando se abrió el ItemContext usando un objeto ItemSearcher devuelto por el método ItemContext.GetSearcher (ContextodeElemento.ObtenerBuscador). Se accede a los resultados de la búsqueda usando un objeto FindResult (Buscar resultados). Suponga las siguientes declaraciones para los ejemplos que se proporcionan a continuación: ItemContext ic = ... ; ItemSearcher searcher = nuil; FindResult result = nuil; Item ítem = nuil; Relationship relationship = nuil; ItemExtension ¡temExtension = nuil; El patrón de búsqueda básica se involucra usando un objeto ItemSearcher (Buscador de elementos) recuperado de un ItemContext (Contexto de elemento) al invocar el método GetSearcher (Obtener buscador). Buscar todos los elementos de un tipo determinado searcher = ¡c. GetSearcher( typeof( Person ) ) result = searcher. FindAII( ); foreach( Person p in result ) ...; Buscar elementos de un tipo determinado que satisface un filtro searcher = ic.GetSearcher( typeof( Person ) ); searcher. Filters.Add( "PersonalNames. Súmame = 'Smith'" ); result = searcher. FindAII( ); foreach( Person p in result ) ...; Usar un parámetro en una cadena de filtro searcher = ic.GetSearcher( typeof( Person ) ); searcher. Filters.Add( "Birthdate < @ Date" ); searcher. Parameters["Date"] = someDate; result = searcher. F i n d AI I ( ); foreach( Person p in result ) ...; Buscar relaciones de un tipo determinado que satisface un filtro searcher = ¡c.GetSearcher( typeof( EmployeeEmployer ) ); searcher. Filters.Add( "StartDate <= @ Date AND (EndDate >= @ Date OR isnull(EndDate))" ); searcher. Parameters["Date"] = someDate; result = searcher. F i n d Al I ( ); Foreach( EmployeeEmployer ee ¡n result ) ...; Buscar elementos con relaciones de un tipo determinado que satisface un filtro searcher = ic.GetSearcher( typeof( Folder ) ); searcher. Filters.Add( "MemberRelationships.Name like "A ); // See [ApiRel] result = searcher. F i n d Al I ( ); Foreach( Folder f in result ) ...; Buscar extensiones de elementos de un tipo determinado que satisface un filtro searcher = ic.GetSearcher( typeof( ShellExtension ) ); searcher. Filters.Add( "Keywords. Valué = 'Foo'" ); result = searcher. FindAII( ); foreach( ShellExtension se in result ) ...; Buscar elementos con extensiones de elementos de un tipo determinado que satisface un filtro searcher = ic.GetSearcher( typeof( Person ) ); searcher.Filters.Add( "Extensions.Cast(@Type).Keywords. Valué = 'Foo'" ); // See [ApiExt] searcher. Parameters["Type"] = typeof( ShellExtension ); result = searcher. FindAII( ); foreach( Person p in result ) ...; (a) Opciones de búsqueda Se puede especificar varias opciones al ejecutar una búsqueda, incluyendo la clasificación, demora de la carga, y limitar el número de resultados. Clasificar resultados de la búsqueda searcher = ic.GetSearcher( typeof( Person ) ); searcher. Filters.Add( "PersonalNames.Surname = •Smith'" ); SearchOptions options = new SearchOptions( ); options.SortOptions.Add( new SortOption( "Birthdate", SortOrder.Ascending ) ); result = searcher. FindAll( options ); foreach( Person p in result ) // Está disponible un atajo: searcher = ic.GetSearcher( typeof( Person ) ); searcher. Filters. Add( "PersonalNames.Surname = 'Smith'" ); result = searcher. FindAII( new SortOption( "Birthdate", SortOrder. Ascending ) ); foreach( Person p in result ) ...; Limitar conteo de resultados searcher = ic.GetSearcher( typeof( Person ) ); searcher. Filters. Add( "PersonalNames.Surname = 'Smith'" ); SearchOptions options = new SearchOptions( ); options. Max esults = 10; result = searcher. FindAII( options ); foreach( Person p in result ) (b) Encontrar uno (FindOne) y Encontrar sólo (FindOnly) En algunas ocasiones la recuperación de sólo el primer resultado es útil, especialmente si se especifican criterios de clasificación. Además, se espera que algunas búsquedas devuelvan sólo un objeto y no se espera que no devuelvan objetos. Buscar un objeto searcher = ic.GetSearcher( typeof( Person ) ); searcher. Filters. Add( "PersonalNames.Surname = 'Smith'" ); Person p = searcher. FindOne( new SortOption( "Birthdate" SortOrder. Ascending ) ) as Person; if(p != nuil) Buscar un sólo objeto que se espera que exista siempre searcher = ic.GetSearcher( typeof( Person ) ); searcher. FiIters.Add( "PersonalNames[Surname = 'Smith' AND Givenname 'John']" ); try { Person p = searcher. F¡ndOnly( ); } catch( Exception e ) { } (c) Buscar métodos abreviados en el contexto del elemento (ItemContext) También existen algunos métodos en el ItemContext (Contexto de elementos) que facilitan la ejecución de búsquedas simples. Buscar usando el atajo ItemContext.FindAII (ContextodeElemento.BuscarTodos) result = ic. FindAll ( typeof( Person ), "PersonalNames.Surname = 'Smith'" ); foreach( Person p in result ) Buscar usando el atajo ItemContext. FindOne (ContextodeElemento.BuscarUno) Person p = ¡c.FindOne( typeof( Person ), "PersonalNames.Surname = 'Smith'" ) as Person; (d) Buscar por ID o por trayecto Además, los elementos, relaciones y extensiones de elementos se pueden recuperar si se proporciona sus identificadores (ID). Los elementos también se pueden recuperar por su trayecto. Obtener elementos, relaciones v extensiones de elementos por sus identificadores (id) ítem = ic.FindltemByld( iid ); relationship = ic.FindRelationshipByld( iid, rid ); itemExtension = ic.FindltemExtensionByld( ¡id, eid ); Obtener elementos por su trayecto // Sólo dominio único item = ic.FindltemByPath( @"temp\foo.txt" ); // Dominio múltiple o único result= ic.F¡ndAllltemsByPath( @"temp\foo.txt" ); foreach( Item I in result ) (e) Patrón para obtener un buscador (GetSearcher) Hay muchos lugares en la API de la plataforma de almacenamiento, en donde es deseable proporcionar un método de ayuda que ejecute una búsqueda en el contexto de otro objeto o con parámetros específicos. Este patrón GetSearcher habilita dichos escenarios. Existen mucos métodos GetSearcher en la API. Cada uno devuelve un buscador de elementos configurado previamente para realizar una búsqueda determinada. Por ejemplo: searcher = itemContext.GetSearcher( ); searcher = Person.GetSearcher( ); searcher = EmployeeEmployer.GetSearcherGivenEmployer( organization ); searcher = person.GetSearcherForReports( ); Puede agregar filtros adicionales antes de ejecutar la búsqueda: searcher = person.GetSearcherForReports( ); searcher. FiIters.Add( "PersonalNames. Súmame = 'Smith'" ); Puede seleccionar cómo desea los resultados: FindResult findResult = searcher. FindAII( ); Person person = searcher. FindOne( ); (3) Actualización del almacén Una vez que el objeto se ha recuperado a través de una búsqueda se puede modificar a través de la aplicación según sea necesario. Es posible que sea necesario crear nuevos objetos y asociarlos con los objetos existentes. Una vez que la aplicación ha realizado los cambios que forman al grupo lógico, la aplicación invoca al método ItemContext. Update (ContextodeElemento. Actualizar) para que continúe con los cambios en el almacén. De conformidad con otro aspecto de la API de la plataforma del almacenamiento de la presente invención, la API también recolecta los cambios que se hicieron a un artículo a través de un programa de aplicación y después los organiza en las actualizaciones correctas requeridas por el motor de la base de datos (o cualquier tipo de motor de almacenamiento) en donde se implementa el almacén de datos. Esto permite que los programadores de la aplicación hagan cambios en un artículo dentro de la memoria, mientras dejan la complejidad de las actualizaciones del almacén de datos a la API. Guardar cambios a un sólo elemento Person p = ic.FindltemByld( pid ) as Person; p.DisplayName = "foo"; p.TelephoneNumbers. Add( new TelephoneNumber( "425-555-1234" ) ); ic.Update( ); Guardar cambios a varios elementos Household h1 = ic.FindltemByld( h i d 1 ) as Household; Household h2 = ic. FindltemByld( hid2 ) as Household; Person p = ic.FindltemByld( pid ) as Person; h1.MemberRelationships.Remove( p ); h2.MemberRelationships.Add( p ); ic.Update( ); Crear un elemento nuevo Folder f = ic.FindltemByld( fid ) as Folder; Person p = new Person( ); p. DisplayName = "foo"; f.Relationships.Add( new FolderMember( p, "foo" ) ); ¡c.Update( ); // O usando un atajo... Folder f = ic.FindltemByld( fid ) as Folder; Person p = new Person( ); p. DisplayName = "foo"; f.MemberRelationships.Add( p, "foo" ); ic.Update( ); Eliminar relaciones (v posiblemente el elemento objetivo) searcher = ic.GetSearcher( typeof( FolderMember ) .); searcher. FiIters.Add( "Sourceltemld = @fid" ); searcher. Filters.Add( "Targetltemld = @pid" ); searcher. Parameters.Add( "fid", fid ); searcher.Parameters.Add( "pid", pid ); foreach( FolderMember fm in searcher. FindAII( ) ) fm.MarkForDeIete( ); ic.Update( ); // O usando un atajo... Folder f = ¡c.FindltemById( fid ) as Folder; f.MemberRelationships.Remove( pid ); ic.Update( ); Agregar una extensión de elemento Item ítem = ¡c. FindltemByld( iid ); MyExtension me = new MyExtens¡on( ); me.Foo = "bar"; item.Extensions.Add( me ); ic.Update( ); Eliminar extensiones de elementos searcher = ic.GetSearcher( typeof( MyExtension ) ); searcher.Filters.Add( "ltemld = @üd" ); searcher. Parameters. Add ( "iid", iid ); foreach( MyExtension me in searcher. FindAll( ) ) me.MarkForDelete( ); ic. Update( ); // O usando un atajo... Item i = ic.FindltemByld( iid ); i.Extensions.Remove( typeof( MyExtension ) ); ic.Update( ); 6. Seguridad Haciendo referencia a la Sección II. E anterior (Seguridad), en la presente modalidad de la API de la plataforma de almacenamiento, hay cinco métodos disponibles en el contexto del elemento para recuperar y modificar la política de seguridad asociada con un elemento en el almacén. Éstos son: 1. GetltemSecurity (Obtener seguridad del elemento); 2. SetltemSecurity (Establecer seguridad del elemento); 3. GetPathSecurity (Obtener seguridad en el trayecto); 4. SetPathSecurity (Establecer seguridad en el trayecto); y 5. GetEffectiveltemSecurity (Obtener seguridad efectiva en el elemento). Los métodos GetltemSecurity y SetltemSecurity proporcionan un mecanismo para recuperar y modificar la ACL explícita asociada con el elemento. Esta ACL es independiente de los trayectos que existen en el elemento y estarán en ejecución independientemente de las relaciones de pertenencia que tenga este elemento como el objetivo. Esto habilita a los administradores para que entiendan la seguridad del elemento independiente de los trayectos que existen para el elemento si así lo desean. Los métodos GetPathSecurity y SetPathSecurity proporcionan el mecanismo para recuperar y modificar la ACL que existe en un elemento debido a una relación de pertenencia de otra carpeta. Esta ACL está compuesta de las ACL de varios antecesores del elemento junto con el trayecto en consideración junto con la ACL explícita si se proporcionó alguna para ese trayecto. La diferencia entre esta ACL y la ACL del caso anterior es que esta ACL sigue en ejecución sólo mientras existe la relación de pertenencia mientras que la ACL explícita del elemento es independiente de cualquier relación de propiedad de un elemento. Las ACL que se pueden establecer en un elemento con los métodos SetltemSecurity y SetPathSecurity se restringen a las ACE heredables y específicas de objeto. No pueden contener ninguna ACE marcada como heredada. El método GetEffectiveltemSecurity recupera las ACL basadas en diversos trayectos, así como la ACL explícita en el elemento. Esto refleja la política de autorización que está en efecto en el elemento determinado. 7. Soporte de relaciones Como se analizó con anterioridad, el modelo de datos de la plataforma de almacenamiento define "relaciones" que permiten que los elementos se relacionen entre sí. Cuando se generan las clases de datos para un esquema, las siguientes clases se producen para cada tipo de relación: 1. Una clase que representa la misma relación. Esta clase se deriva de la clase Relationship y contiene miembros específicos del tipo de relación. 2. Una clase de colección "virtual" con clasificación sólida. Esta clase se deriva de VirtualRelationshipCollection y permite que la instancia de relación se creen y se eliminen. Esta sección describe el soporte para las relaciones en la API de la plataforma de almacenamiento. a) Tipos de relación Base La plataforma de almacenamiento proporciona un número de tipos en el espacio de nombre System .Storage que forman el fundamento de la API de la relación. Éstos son: 1. Relationship (Relación) - el tipo base de todas las clases de relación. 2. VirtualRelationshipCollection (Colección de relaciones virtuales) - el tipo base para todas las colecciones de relación. 3. Item Reference (Referencia de elemento), ItemldReference (Referencia de ID del elemento), ItemPathReference (Referencia de trayecto del elemento) -Representa los tipos de referencia del elemento; la relación entre estos tipos se ilustra en la figura 11. (1) Clase de relación (Relationship) A continuación se muestra la clase base de las clases de relaciones. public abstract class Relationship : StoreObject { // Crear con valores predeterminados. protected Relationship( ItemIDReference ta rgetltem Referen ce); // Informa la relación que se ha agregado a una colección de relaciones. El objeto // interrogará la colección para determinar el elemento fuente, contexto de elementos, etc. internal AddedToColIection( VirtualRelationshipCollection collection ); // La id de la relación. public Relationshipld Relationshipld { get; } // La id del elemento fuente. public Itemld Sourceltemld { get; } // Obtener el elemento fuente. public Item Sourceltem { get; } // Referencia para el elemento objetivo. public ItemIdReference Targetltem Reference { get; } // Obtener el elemento objetivo (invoca TargetltemReference.Getltem( )). public Item Targetltem { get; } // Determina si ItemContext ya cuenta con una conexión a un dominio del elemento objetivo (invoca //Ta rgetltem Referen ce. IsDomainConnected). public bool IsTargetDomainConnected { get; } // El nombre del elemento objetivo en el espacio de nombre. El nombre debe ser único en todas las // relaciones de pertenencia del elemento fuente, public OptionalValue<string> ame {get; set;} // Determina si esta es una relación de pertenencia o de referencia. public OptionalValue<booI> IsOwned {get; set;} } (2) Clase Referencia del elemento (ItemReference) A continuación se muestra la clase base de los tipos de referencia de los elementos. public abstract class ItemReference : NestedElement { // Crear con valores predeterminados, protected ltemReference( ); // Devuelve el elemento al que se hace referencia, public virtual Item Getltem( ); // Determina si una conexión al dominio del elemento al que se hace referencia ya se ha establecido, public virtual bool lsDomainConnected( ); } Los objetos ItemReference (Referencia del elemento) pueden identificar elementos que existen en un almacén diferente al almacén donde reside la referencia del elemento. Cada tipo derivado especifica la manera en que se construye y usa una referencia a un almacén remoto. Las implementaciones de Getltem y IsDomainConnected en las clases derivadas usan el soporte de múltiples dominios de ItemContext para cargar elementos del dominio necesario y para determinar si una conexión al dominio ya se estableció. (3) Clase de referencia de ID del elemento (ItemldReference) A continuación se presenta la clase ItemldReference — una referencia del elemento que usa una id de elemento para identificar el elemento objetivo. public class ItemldReference : ItemReference { // Construye una nueva ItemldReference con los valores predeterminados. public ltemldReference( ); // Construye una nueva ItemldReference para el elemento especificado. El dominio asociado al // Elemento se usa como el ubicador. public Iteml d Reference( Item ¡tem ); // Construye una nueva ItemldReference con un ubicador nulo y el id de elemento objetivo determinado, public ltemldReference( Itemld itemld ); II Construye una nueva ItemldReference con el ubicador determinado y los valores del id del elemento. public ltemldReference( string locator, Itemld itemld ); // El id del elemento fuente, public Itemld Itemld {get; set;} // Un trayecto que identifica el elemento de WinFS que contiene el elemento objetivo en su dominio. If nuil, // el dominio que contiene el elemento no se conoce. public Optional Value<string> Locator {get; set;} // Determina si una conexión al dominio del elemento al que se hace referencia ya se ha establecido. public override bool lsDomainConnected( ), // Recupera el elemento al que se hace referencia. public override Item Getltem( ); } Las clases Getltem y IsDomainConnected usan el soporte de múltiples dominios de ItemContext para cargar elementos del dominio necesario y para determinar si una conexión al dominio ya se estableció. Esta característica aún no se implementa. (4) Clase de referencia del trayecto del elemento (Item PathRef erence) La clase ItemPathReference es una referencia de elemento que usa un trayecto para identificar el elemento objetivo. El código para la clase es como se indica a continuación: public class ItemPathReference : ItemReference { // Construye una referencia del trayecto del elemento con valores predeterminados, public ltemPathReference( ); // Construye una referencia de trayecto del elemento sin ubicador y el trayecto determinado. public ltemPathReference( string path ); // Construye una referencia de trayecto del elemento con ubicador y el trayecto determinado. public ltemPathReference( string locator, string path ); // Un trayecto que identifica el elemento de WinFS que contiene el elemento objetivo en su dominio. public Optional Vaíue<string> Locator {get; set;} // El trayecto del elemento objetivo con relación al dominio del elemento especificado por el ubicador. public string Path {get; set;} // Determina si una conexión al dominio del elemento al que se hace referencia ya se ha establecido. public override bool lsDomainConnected( ); // Recupera el elemento al que se hace referencia. public override Item Getltem( ); } Las clases Getltem y IsDomainConnected usan el soporte de múltiples dominios de ItemContext para cargar elementos del dominio necesario y para determinar si una conexión al dominio ya se estableció. (5) Estructura de la id de relación (Reiationshipld) La estructura de Reiationshipld encapsula una GUID de id de la relación. public class Reiationshipld { // Genera una nueva GUID de id de relaciones, public static Reiationshipld NewRelationsh¡pld( ); // Inicializa una nueva GUID de id de relaciones. public Relationshipld( ); // Inicializa con la GUID especificada, public Relationshipld( Guid id ); // Inicializa con una representación en cadena de una GUID. public Relationshipld( string id ); // Devuelve una representación de una cadena de la GUID de la id de la relación, public override string T String( ); // Convierte una instancia de System. Guid en una instancia Reiationshipld. public static implicit operator Relationshipld(Guid guid); // Convierte una instancia de Relationshipid en una instancia System. Guid. public static ¡mplicit operator Guid(Relationshipld relationshipid); } Este tipo de valor envuelve una guid de manera que los parámetros y propiedades se pueden clasificar sólidamente como una id de relación. Se debe usar Optional Value<Relationshipld>; cuando una id de relación puede ser nula. Un valor vacío, como el que proporciona System. Guid. Empty, no se expone. No se puede construir una Relationshipid con un valor vacío. Cuando el constructor predeterminado se usa para crear una Relationshipid, se crea una nueva GUID. (6) Clase de la colección de relaciones virtuales (VirtualRelationshipCollection) La clase VirtualRelationshipCollection implementa una colección de objetos de relación que incluye objetos del almacén de datos, más los nuevos objetos que se agregan a la colección, pero no incluye objetos que se eliminan de almacén. Los objetos de un tipo de relación especificado con una id de elemento fuente determinado se incluyen en la colección. Ésta es la clase base para la clase de colección de la relación que se genera para cada tipo de relación. Dicha clase se puede usar como el tipo de una propiedad en el tipo del elemento fuente para proporcionar acceso y una manipulación sencilla de las relaciones de un elemento determinado. La enumeración del contenido de una clase VirtualRelationshipCollection (Colección de relaciones virtuales) requiere que un número potencialmente grande de objetos de la relación se carguen desde el almacén. Las aplicaciones deben usar la propiedad Count para determinar el número de relaciones que se pueden cargar antes de enumerar el contenido de la colección. La adición y eliminación de objetos de la colección no requiere que las relaciones se carguen del almacén. Por razones de rendimiento, es preferible que las aplicaciones busquen las relaciones que satisfacen los criterios específicos en lugar de enumerar todas las relaciones de un elemento usando un objeto VirtualRelationshipCollection. La adición de objetos de relación a la colección ocasiona que las relaciones representadas se creen en el almacén cuando se invoca el método ItemContext. Update. La eliminación de objetos de relación a la colección ocasiona que las relaciones representadas se eliminen del almacén cuando se invoca el método ItemContext. Update. La colección virtual contiene el conjunto correcto de objetos sin importar si un objeto de relación se agrega o elimina de la colección Item.Relationships (Elemento. Relaciones) o cualquiera de las colecciones en ese elemento. El código que se muestra a continuación define la clase VirtualRelationshipCollection: public abstract class VirtualRelationshipCollection : Icollection { // La colección contiene las relaciones del tipo especificado que son del elemento // identificadas por la id del elemento. protected VirtualRelationshipCollection( ItemContext itemContext, Itemld itemld, Type relationshipType ); // El enumerador devuelve todos los objetos recuperados del almacén menos cualquier objeto que // con el estado Deleted (Eliminado) además de los objetos que tienen el estado Inserted (Insertado). public lEnumerator GetEnumerator( ); // Devuelve un conteo del número de objetos de relación que son devueltos por // el enumerador. Este conteo se calcula sin que sea necesario recuperar todos los objetos del almacén. public int Count { get; } // Siempre devuelve falso. public bool ICollection.lsSynchronized( ) { get; } // Siempre devuelve este objeto, public object ICollection.SyncRoot { get; } // Busca en el almacén los objetos necesarios, public void Refresh( ); // Agrega la elación especificada a la colección. El objeto debe tener el estado // Constructed (Construido) o Removed (Eliminado). Si el estado es Constructed, cambia a Added (Agregado). Si el estado // es Removed, cambia a Retrieved (Recuperado) o Modified (Modificado), según sea adecuado. // El id del elemento fuente de la relación // debe ser igual que el id del elemento fuente que se proporcionó cuando la colección // se construyó. protected void Add( Relationship relationship ); // Elimina la elación especificada de la colección. El estado del objeto debe ser // Added (agregado), Retrieved (Recuperado) o Modified (Modificado). Si el estado del objeto es Added, se establece en // Constructed (Construido). Si el estado del objeto es Retrieved o Modified, se establece en Removed (eliminado).

// El id del elemento fuente de la relación debe ser igual que el id del elemento fuente que // se proporcionó cuando la colección se construyó, protected void Remove( Relationship relationship ); // Los objetos que se han eliminado de la colección, public ICollection RemovedRelationships { get; } // Los objetos que se han agregado a la colección, public ICollection AddedRelationships { get; } // Los objetos que se han recuperado del almacén. Esta colección estará vacía hasta // después de enumerar o regenerar VirtualRelationshipCollection y se invoca (obtener // este valor de propiedad no ocasiona que se llene la colección). public ICollection StoredRelationships { get; } // Métodos asincronos. public lAsyncResult BeginGetCount( I AsyncCalIback callback, object state ); public int EndGetCount( lAsyncResult asyncResult ); public lAsyncResult BeginRefresh( lAsyncCalIback callback, object state ); public void EndRefresh( lAsyncResult asyncResult ); } b) Tipos de relación generada Cuando se generan clases para un esquema de la plataforma de almacenamiento, se genera una clase para cada declaración de la relación. Además de una clase que representa una relación, también se genera una clase de colección de relación para cada relación. Estas clases se usan como el tipo de propiedades dentro de las clases del elemento fuente u objetivo. Esta sección describe las clases que se generan usando un número de clases "prototipo". Esto es, dada una declaración de relación especificada, se describe la clase que se genera. Es importante observar la clase, el tipo, y los nombres del punto de extremo que se usan en las clases prototipo que son contenedores de lugar para los nombres especificados en el esquema para la relación, y no se deben interpretar literalmente. (1) Tipos de relaciones generadas Esta sección describe las clases que se generan para cada tipo de relación. Por ejemplo: <Relationship Name = "RelationshipPrototype" BaseType = "Holding"> <Source Name = "Head" ltemType = "Foo"/> <Target Name = "Tail" ltemType="Bar" ReferenceType = "ltemlDReference" /> <Property Name = "SomeProperty" Type = "WinFSTypes.String" /> </Relationship> Dada esta definición de relación, se generan las clases RelationshipPrototype (PrototipodeRelación) y RelationshipPrototypeCollection (ColecciónPrototipodelaRelación). La clase RelationshipPrototype representa la relación misma. La clase RelationshipPrototypeCollection proporciona acceso a las instancias RelationshipPrototype que tienen un elemento especificado como el punto de extremo fuente. (2) Clase de prototipo de relaciones (RelationshipPrototype) Esta es una clase de propiedad prototipo para la relación de propiedad denominada "HoldingRelationshipPrototype" en donde el punto de extremo fuente se denomina "Cabeza" y especifica el tipo de elemento "Foo" y el punto de extremo objetivo se denomina "Cola" y especifica el tipo de elemento "Bar". Se define como se indica a continuación: public class RelationshipPrototype : Relationship { public RelationshipPrototype( Bar tailltem ); public RelationshipPrototype( Bar tailltem, string ñame ); public RelationshipPrototype( Bar tailltem, string ñame, bool IsOwned ); public RelationshipPrototype( Bar tailltem, bool IsOwned ); public RelationshipPrototype( ItemldReference tailltemReference ); // Obtener elemento Head (invoca base.Sourceltem). public Foo Headltem { get; } // Obtener elemento Tail (invoca base. Targetltem). public Bar Tailltem { get; } // Representa propiedades adicionales declaradas en el esquema para la relación. Éstos se // generan como las propiedades en un elemento o tipo de elemento anidado. public string SomeProperty {get; set;} public static ItemSearcher GetSearcher( ItemContext ¡temContext ); public static ItemSearcher GetSearcher( Foo headltem ); public static FindResult FindAII( string filter ); public static RelationshipPrototype FindOne( string filter ); public static RelationshipPrototype FindOnly( string filter ); } (3) Clase de colección de prototipos de la relación (RelationshipPrototypeCollection) Esta es una clase prototipo, generada con la clase RelationshipPrototype, que mantiene una colección de instancias de relación RelationshipPrototype que son propiedad de un elemento especificado. Se define como se indica a continuación: public class RelationshipPrototypeCollection VirtualRelationshipCollection { public RelationshipPrototypeCoIlection( ItemContext itemContext, Itemld headltemld ); public void Add( RelationshipPrototype relationship ); public RelationshipPrototype Add( Bar bar ); public RelationshipPrototype Add( Bar bar, string ñame); public RelationshipPrototype Add( Bar bar, string ñame, bool IsOwned ); public RelationshipPrototype Add( Bar bar, bool IsOwned ); public v id Remove( RelationshipPrototype relationship ); public v id Remove( Bar bar ); public void Remove( Itemld barltemld ); public void Remove( Relationshipld relationshipld ); public void Remove( string ñame ); } c) Soporte de las relaciones en la clase de elemento) La clase Item contiene una propiedad Relationship que proporciona acceso a las relaciones en las que el elemento es el origen de la relación. La propiedad de las relaciones tiene el tipo RelationshipCollection (Colección de relación). (1) Clase de elemento (Item) El código a continuación muestra las propiedades del contexto de la relación de la clase Item:, public abstract class Item : StoreObject { // Colección de relaciones en donde este elemento es el origen . public RelationshipCollection Relationships {get;} ... } (2) Clase de colección de relaciones (RelationshipCollection) Esta clase proporciona acceso a las instancias de relación en donde un elemento determinado es el origen de la relación. Se define como se indica a continuación: public class RelationshipCollection : VirtualRelationshipCollection { public RelationshipCollection( ItemContext itemContext, Itemld headltemld ); public void Add( Relationship relationship ); public Relationship Add( Bar bar ); public Relationship Add( Bar bar, string ñame ); public Relationship Add( Bar bar, string ñame, bool IsOwned ); public Relationship Add( Bar bar, bool IsOwned ); public void Remove( Relationship relationship ); public void Remove( Bar bar ); public void Remove( Itemld barltemld ); public void Remove( Relationshipld relationshipld ); public voidRemove( string ñame ); } d) Soporte de las relaciones en las expresiones de búsqueda Es posible especificar el cruce de una unión entre las relaciones y los elementos relacionados en una expresión de búsqueda. (1) Cruce de elementos a relaciones Cuando el contexto actual de una expresión de búsqueda es un conjunto de elementos, una unión entre los elementos y las instancias de relación, en donde el elemento es el origen se puede hacer usando la propiedad Item. Relationships (Elemento. Relaciones). La unión de las relaciones de un tipo específico se puede especificar usando el operador Cast de la expresión de búsqueda. En una expresión de búsqueda también se pueden usar colecciones de relaciones con clasificación sólida (por ejemplo, Folder. MemberRelationships (Carpeta. RelacionesdeMiembros). El reparto del tipo de relación es implícito. Una vez que se ha establecido el conjunto de relaciones, las propiedades de esa relación están disponibles para usarse en predicados o como el objetivo de una proyección. Cuando se usan para especificar el objetivo de una proyección, el conjunto de relaciones se devuelve. Por ejemplo, la siguiente afirmación encontrará a todas las personas relacionadas con una organización en donde la propiedad StartDate (Fechadelnicio) de las relaciones tenía un valor mayor o igual a '1/1/2000'. FindResult result = Person.FindAII( context, "Relationships.Cast(Contact.EmployeeOfOrganization). StartDate > '1/1/2000'" ); Si el tipo Person (Persona) tenía la propiedad EmployerContext (ContextodeEmpleado) del tipo EmployeeSideEmployerEmployee-Relationships (Relaciones-EmpleadodelladodelPatrónEmpleado) (como se genera para un tipo de relación EmployeeEmployer (EmpleadoPatrón), esto se puede escribir de esta manera: FindResult result = Person. FindAII( context, "EmployerRelationships. StartDate > '1/1/2000'" ); Cruce de relaciones elementos Cuando el contexto actual de la expresión de búsqueda es un conjunto de relaciones, una unión de una relación a cualquier punto de extremo de la relación puede cruzar al especificar el nombre del punto de extremo. Una vez que se ha establecido el conjunto de elementos relacionados, las propiedades de esos elementos están disponibles para usarse en predicados o como el objetivo de una proyección. Cuando se usan para especificar el objetivo de una proyección, el conjunto de elementos se devuelve. Por ejemplo, la siguiente afirmación encontrará todas las relaciones EmpIoyeeOfOrganization (EmpleadodelaOrganización), sin importar la organización, donde el apellido del empleado es "Smith": FindResult result = EmpIoyeeOfOrganization. FindAII( context, "Employee.PersonaINames[SurName = 'Smith']" ); El operador Cast de la expresión de búsqueda se puede usar para filtrar él tipo de elemento de punto de extremo. Por ejemplo, para encontrar a todas las instancias de la relación MemberOfFolder (MembresíadeCarpeta) en donde el miembro es un elemento Person (Persona) con el apellido "Smith": FindResult result = MemberOfFolder. FindAII( context, "Member.Cast(Contact.Person).PersonalNames[Surname = 'Smith']" ); (3) Combinación de cruce de relaciones Los dos patrones anteriores, que cruzan de los elementos a las relaciones y de las relaciones a los elementos, se puede combinar para lograr cruces transversales complejos de manera arbitraria. Por ejemplo, para encontrar todas las organizaciones con un empleado que tiene el apellido "Smith": FindResult result = Organizaron. FindAII( context, "EmployeeRelationships." + "Employee." + "PersonalNames[SurName = 'Smith']" ); El ejemplo anterior encuentra todos los elementos Person que representan personas que viven en una familia que está en el área de "Nueva York" (TODO: esto ya no tiene soporte. . . cuál es la alternativa). FindResult result = Person. FindAII( context, "Relationships.Cast(Contact.MemberOfHousehold)." + "Household." + "Relationships.Cast(Contact.LocationOfHousehold)." + "MetropolitonRegion = 'New York'" ); e) Ejemplos de los usos del soporte de relación A continuación se presentan ejemplos sobre cómo se puede usar el soporte de la relación en la API de la plataforma de almacenamiento para manipular las relaciones. Para los ejemplos que se presentan a continuación, suponga las siguientes declaraciones: ItemContext ic = ... ; Itemld fid = ...; // el id del elemento de una carpeta Folder folder = Folder. FindByld( ic, fid ); Itemld sid = // un id del elemento de origen. Item source = item.FindByld( ic, sid ); Itemld tid = // un id del elemento objetivo. Item target = ltem.FindByld( ic, tid ); ItemSearcher searcher = nuil; (1) Búsqueda de relaciones Es posible buscar relaciones de origen y objetivo. Se pueden usar los filtros para seleccionar relaciones de un tipo especificado y que tienen valores de propiedad determinados. Los filtros se pueden usar para seleccionar relaciones con base en el tipo del elemento relacionado o los valores de propiedad. Por ejemplo, se pueden realizar las siguientes búsquedas: Todas las relaciones en donde un elemento determinado es el origen searcher = Relationship.GetSearcher( folder ); foreach( Relatíonship relationship ¡n searcher. FindAII( ) ) ...; Todas las relaciones donde un elemento determinado es el origen gue tiene un nombre que corresponde a "A%" searcher = Relationship. GetSearcher( folder ); searcher. Filters.Add( "Ñame like ?%"' ); foreach( Relationship relationship in searcher. FindAII( ) ) ...; Todas las relaciones FolderMember (Miembro de carpeta) en donde un elemento determinado es el origen searcher = FolderMember. GetSearcher( folder ); foreach( FolderMember folderMember in searcher. F ? n d A 11 ( ) ) Todas las relaciones FolderMember (Miembro de carpeta) en donde un elemento determinado es el origen y un nombre como '?%' searcher = FolderMember. GetSearcher( folder ); searcher. Filters.Add( "Ñame like ?%"' ); foreach( FolderMember folderMember in searcher. F i n d A 11 ( ) ) Todas las relaciones FolderMember (Miembro de carpeta) donde el elemento objetivo es Person (Persona) searcher = FolderMember. GetSearcher( folder ); searcher. Filters.Add( "Memberltem.Cast(Person)" ); foreach( FolderMember folderMember in searcher. FindAII( ) ) Todas las relaciones FolderMember (Miembro de carpeta) donde el elemento objetivo es Person (Persona) con el apellido "Smith" searcher = FolderMember. GetSearcher( folder ); searcher. Filters. Add( "Memberltem.Cast(Person).PersonalNames.Surna-me = 'Smith'" ); foreach( FolderMember folderMember in searcher. F¡ndAII( ) ) Además de la API de GetSearcher (Obtener buscador) que se mostró en párrafos anteriores, cada clase de relación soporta las API estáticas FindAII (Encontrar todo), FindOne (Encontrar uno) y FindOnly (Encontrar sólo). Además, un tipo de relación se puede especificar al invocar I te mCont ext. GetSearcher, Item Context. FindAII, ItemContext. FindOne, o ItemContext. FindOnly. (2) Navegación de una relación a los elementos origen y objetivo Una vez que el objeto de relación se ha recuperado a través de una búsqueda, es posible "navegar" hacia el elemento objetivo u origen. La clase de relación base proporciona las propiedades Sourceltem y Targetltem que devuelven un objeto elemento. La clase de relación generada proporciona las propiedades equivalentes clasificadas sólidamente y denominadas (por ejemplo, FolderMember. Folderltem y FolderMember. Memberltem). Por ejemplo: Navegar al elemento de origen y de destino para la relación con el nombre "Foo" searcher = Relationship. GetSearcher( ); searcher. Filters.Add( "Name = 'Foo"' ); foreach( Relationship relationship in searcher. FindAII( ) ) { Item source = relationship. Sourceltem; Item target = relationship. Targetltem; } Navegar hacia el elemento objetivo searcher = FolderMember. GetSearcher( folder ); searcher. Filters.Add( "Ñame like ?%"' ); foreach( FolderMember folderMember in searcher. FindAII( ) ) { Item member = folderMember. Targetltem; } La navegación hacia un elemento objetivo funciona incluso si el elemento objetivo no está en e dominio donde se encontró la relación. En tales casos, la API de la plataforma de almacenamiento abre una conexión hacia el dominio objetivo como sea necesario. Las aplicaciones pueden determinar si una conexión se requiere antes de recuperar el elemento objetivo. Verificar el elemento objetivo en un dominio sin conexión searcher = Relationship.GetSearcher( source ); foreach( Relationship relationship in searcher. F i n d All ( ) ) { if( reltionship. IsTargetDomainConnected ) { Item member = relationship. Targetltem; ... } } (3) Navegación de los elementos de origen a relaciones Con un objeto de elemento determinado, es posible navegar a las relaciones para las que ese elemento es el origen sin ejecutar una búsqueda implícita. Este se hace usando la propiedad de colección Item. Relationships o una propiedad de colección clasificada sólidamente como Folder.MemberRelationships. Desde una relación es posible navegar hacia el elemento objetivo. Dicha navegación funciona incluso si el elemento objetivo no está en el dominio del elemento asociado con ItemContext del elemento de origen, incluso cuando el elemento objetivo no está en el mismo almacén que el elemento objetivo. Por ejemplo: Navegar de un elemento de origen a una relación a elementos objetivos Consolé. WriteLine( "Item {0} is the source of the following relationships:", source. Itemld ); foreach( Relationship relationship in source. Relationships ) { Item target = relationship. Targetltem; Consolé. WriteLine( " {0} = => {1}", relationship. Relationshipld, target. Itemld ); } Navegar de un elemento de carpeta a relaciones Foldermember (de miembro de carpeta) a elementos objetivo Consolé. WriteLine( "Item {0} is the source of the following relationships:", folder. Itemld ); foreach( FolderMember folderMember in folder. MemberRelationships ) { Item target = folderMember. GetMemberltem( ); Consolé. WriteLine( " {0} = => {1}", folderMember. Relationshipld, target. Itemld ); } elemento puede tener muchas relaciones, manera que las aplicaciones deben tener precaución al enumerar una colección de relaciones. En general, se debe usar una búsqueda para identificar relaciones particulares de interés en lugar de enumerar la colección completa. Incluso, tener un modelo de programación basado en una colección para las relaciones es valioso y los elementos con muchas relaciones poco comunes, que el riesgo de abuso por parte de los desarrolladores se justifica. Las aplicaciones pueden comprobar el número de relaciones de la colección y usar un modelo de programación diferente si lo necesita. Por ejemplo: Comprobar el tamaño de una colección de relación if( folder.MemberRelationships.Count > 1000 ) { Consolé. WriteLine( "Too many relationships!");} de otra manera { } Las relaciones de colecciones que se describen en párrafos anteriores son "virtuales" en el sentido que no están llenas en realidad con objetos que representan cada relación, a menos que la aplicación intente enumerar la colección. Si se enumera la colección, los resultados reflejan lo que encontró en el almacén, además de los que se ha agregado mediante la aplicación, pero aún no se ha guardado, más ninguna relación que haya trasladado la aplicación sin guardarla. (4) Creación de relaciones (y elementos) Se crean nuevas relaciones al crear un objeto de relación, agregándolo a una colección de relación en el elemento de origen y actualizando ItemContext. Para crear un elemento nuevo, se debe crear una relación de propiedad o de incrustación. Por ejemplo: Agregar un elemento nuevo a una carpeta ya existente Bar bar = new Bar( ); folder. Relationships. Add( new FolderMember( bar, "ñame" ) ); ic.Update( ); // O Bar bar = new Bar( ); folder. MemberRelationships.Add( new FolderMember( bar, "ñame" ) ); ¡c.Update( ); // O Bar bar = new Bar( ); folder. MemberRelationships.Add( bar, ñame ); ic.Update( ); Agregar un elemento existente a una carpeta existente folder. MemberRelationsh- ips.Add( target, "name" ); ic.Update( ); Agregar un elemento existente a una carpeta nueva Folder existingFolder = ic. Find ItemBy I d ( fid ) as Folder; Folder newFolder = new Folder( ); existingFolder. MemberRelationships.Add( newFolder, "a name" ); newFolder. MemberRelationships.Add( target, "a name" ); ic.Update( ); Agregar un elemento nuevo a una carpeta nueva Folder existingFolder = ic.FindltemByld( fid ) as Folder; Folder newFolder = new Folder( ); existingFolder. MemberRelationships.Add( newFolder, "a name" ); Bar bar = new Bar( ); newFolder. MemberRelationships.Add( bar, "a name" ); ¡c.Update( ); (5) Eliminación de relaciones (y elementos) Eliminar una relación de propiedad // Si los id del elemento de origen y de relación son conocidos ... Relationshipld rid = ...; Relationship r = ic.FindRelationshipByld( fid, rid ); r.MarkForDelete; ¡c.Update( ); // De otra manera ... folder.MemberRelat¡onships.Remove( target ); ic. Update( ); 8. "Extensión" de la API de la plataforma de almacenamiento Como se observó anteriormente, todos los esquemas de la plataforma de almacenamiento ocasionan un conjunto de clases. Estas clases tienen métodos estándar como Find* (Buscar*) y también tienen propiedades para obtener y establecer valores de campo. Estas clases y sus métodos asociados forman el fundamento de la API de la plataforma de almacenamiento. a) Comportamientos de domino Además de estos métodos estándar; cada uno de los esquemas tiene un conjunto de métodos específicos por dominio para éste. Denominamos a estos dominios comportamientos. Por ejemplo, algunos comportamientos de dominio en el esquema de contactos, Contacts, son: • ¿Es válida una dirección de correo electrónico? • Dada una carpeta, obtener la colección de todos los miembros de la carpeta. • Dado un ID, obtener un objeto que representa este elemento. • Dada una persona, obtener su estado en línea. • Funciones de ayuda para crear un contacto nuevo o un contacto temporal. • Etc. Es importante observar que mientras hacemos una distinción entre comportamientos "estándar" (buscar*, etc.) y los comportamientos del dominio, simplemente aparecen como métodos para el programador. La diferencia entre estos métodos se encuentra en el hecho de que los comportamientos estándar se generan de manera automática a partir de los archivos de las herramientas de tiempo de diseño de los esquemas a través de la API de la plataforma de almacenamiento mientras que los comportamientos del dominio son de código duro. Por su naturaleza, estos comportamientos de dominio se deben elaborar a mano. Esto produce un problema en la práctica: La versión inicial de C# requiere que la implementación completa de una clase se encuentre dentro de un solo archivo. De esta manera, esto forzada a los archivos de clase generada automáticamente para que sean editados para agregar los comportamientos del dominio. Por sí mismo, esto puede ser un problema. Una característica denominada clases parciales se debe introducir en C# para los problemas como éstos.

Básicamente, una clase parcial permite que la implementación de la clase se extienda a varios archivos. Una clase parcial es la misma que una clase regular con excepción de que su declaración es antecedida por la palabra clave parcial: partial public class Person: Deriveditem Base { // implementacón } Ahora, los comportamientos del dominio para Person se pueden colocar en un archivo diferente como: partial public class Person { public EmailAddress PrimaryEmailAddress { get { /*¡mplementation*/ } } } b) Comportamientos de valor agregado Las clases de datos sin comportamientos de dominio forman un fundamento que construyen los desarrolladores de aplicación. Sin embargo, no es posible ni deseable para las clases de datos exponer todos los comportamientos concebibles relacionados con dichos datos. La plataforma de almacenamiento permite que un desarrollador construya sobre la funcionalidad de la base ofrecida por la API de la plataforma de almacenamiento. El patrón básico es escribir una clase cuyos métodos tomen una o más clases de datos de la plataforma de almacenamiento como parámetros. Por ejemplo, el valor y las clases para enviar correo electrónico usando Microsoft Outlook o el mensajero de Windows de Microsoft puede ser como se indica continuación: MailMessage m = MailMessage.FindOne(...); OutlookEMaiIServices.SendMessage(m); Person p = Person.FindOne(...); WindowsMessagerServices m = new WindowsMessagerSer ices(p); m.MessageReceived += new MessageReceivedHandler( f ); m.SendMessage(" Helio"); Estas 'clases de valor agregado se pueden registrar con la plataforma de almacenamiento. Los datos de registro se asocian con los metadatos del esquema que mantiene la plataforma de almacenamiento para cada uno de los tipos instalados en la plataforma de almacenamiento. Estos metadatos se almacenan como elementos de la plataforma de almacenamiento y se pueden consultar. El registro de las clases de valor agregado es una característica poderosa; por ejemplo, permite el siguiente escenario: seleccione con el botón derecho del ratón un objeto Person en el explorador Shell y se derivará el conjunto de acciones permitidas de las clases de valor agregado registrados para Person. c) Comportamientos de valor agregado como proveedores de servicio En la modalidad que se presenta, la API de la plataforma de almacenamiento proporcionó un mecanismo en donde las clases de valor agregado se pueden registrar como "servicio" para un tipo determinado. Esto permite que una aplicación establezca y obtenga proveedores de servicio (= clases de valor agregado) de un tipo determinado. Las clases de valor agregado que desean utilizar este mecanismo deben implementar una interfase ya conocida; por ejemplo: interface IChatServices { void SendMessage(string msg); event MessageReceivedHandIer MessageReceived; } class WindowsMessengerServices : IchatServices { class YahooMessengerServices : IchatServices { } Todas las clases de datos de la API de la plataforma de almacenamiento implementan la interfase System. IServiceProvider como se indica continuación: interface ICachedServiceProvider : System. I serviceProvider { void SetService(System.Type type, Object provider); void RemoteService(System.Type type); } Al usar esta interfase, las aplicaciones pueden establecer la instancia del proveedor de servicio así como solicitar un proveedor de servicio para un tipo específico. Para soportar ésta interfase, la clase de datos de la plataforma de almacenamiento mantiene una tabla de elección arbitraria de los proveedores de servicio que cuentan con claves por tipo. Cuando se solicita un proveedor de servicio, la implementación primero busca en la tabla de elección arbitraria si un proveedor de servicio del tipo especificado ya se ha establecido. Si no es así, la infraestructura del proveedor de servicio registrado se usa para identificar un proveedor de servicio del tipo especificado. Una instancia para este proveedor se crea entonces, se agrega a la tabla de elección arbitraria y se devuelve. Observe que esto también es posible para el método compartido en la clase de datos para solicitar un proveedor de servicio y transferir una operación a dicho proveedor. Por ejemplo, esto se puede usar para proveer un método de envío en la clase de mensaje de correo que usa el sistema de correo electrónico especificado por el usuario. 9. Diseño de la estructura de tiempo Esta sección describe la manera en que el esquema de la plataforma de almacenamiento se mete en las clases de la API de la plataforma de almacenamiento en el cliente y en las clases UDT en el servidor, de conformidad con la presente modalidad de la invención. El diagrama de la figura 24 muestra los componentes involucrados. Haciendo referencia a la figura 24, los tipos del esquema están contenidos en un archivo XML (cuadro 1). Este archivo también contiene el nivel de campo en las restricciones de nivel del elemento asociadas con el esquema. El generador de clase de la plataforma de almacenamiento (xfs2cs.exe -cuadro 2) toma este archivo y genera las clases parciales para los UDT del almacén (cuadro 5) y las clases parciales para las clases del cliente (cuadro 3). Para cada dominio de esquema, existen métodos adicionales, que denominamos comportamientos de dominio. Hay comportamientos de dominio que tienen sentido en el almacén (cuadro 7) en el cliente (cuadro 6) y en ambos lugares (cuadro 4). El código de los cuadros 4, 6 y 7 se escriben de mano (no se generan automáticamente). Las clases parciales de los cuadros 3, 4 y 6. Su forma en la implementación de clase completa para las clases de dominio de la API de la plataforma de almacenan cliente. Los cuadros 3, 4 y 6, se compilan (cuadro 8) para formar las clases de la API de la plataforma de almacenamiento, cuadro 11 (en realidad, la API de la plataforma de almacenamiento es el resultado de la compilación de los cuadros 3, 4 y 6 que resultan de todos los dominios de esquema iniciales). Además de las clases de dominio, también existen las clases adicionales que implementan los comportamientos de valor agregado. Estas clases usan una o más clases en uno o más dominios de esquemas. Esto se representa en el cuadro 10. Las clases parciales en el cuadro 5, 6 y 7 juntas forman la implementación de la clase completa para las clases de UDT del servidor. Los cuadros 4, 5 y 7 se complilan (cuadro 9) para formar el ensamble de UDT lateral del servidor- cuadro 12 (en realidad, el ensambnie de UDT lateral del servidor es el resultado del compilador más ing de los cuadros 4, 5 y 7 que se obtienen de todos los dominios de esquema inicial). El módulo generador de comandos DDL (cuadro 13) toma el ensamble de UDT (cuadro 12) y el archivo de esquema (cuadro 1) y los instala en el almacén de datos. Este proceso involucra, entre otras cosas, la generación de tablas y formularios para los tipos en cada esquema. 10. Formalismos de consulta Cuando se reduce a los puntos básicos, el patrón de la aplicación cuando usa la API de la plataforma de almacenamiento es: Open an ItemContext; usa Find con un criterio de filtro para recuperar los objetos deseados; hacer las operaciones sobre los objetos y enviar los cambios de vuelta al almacén. Esta sección se refiere la sintaxis de lo que va en la cadena de filtrado. La cadena de filtrado se proporciona cuando se encuentran los objetos de datos de la plataforma de almacenamiento describe las condiciones que deben cubrir las propiedades del objeto para que sean devueltas. La sintaxis que usa la API de la plataforma de almacenamiento soporta las fusiones de tipo y el cruce de relaciones. a) Puntos básicos de filtrado Una cadena de filtro puede estar vacía, lo que indica que todos los objetos del tipo especificado se devuelven, o puede ser una expresión booleana que cada objeto devuelto debe satisfacer. La expresión hace referencia a las propiedades del objeto. El tiempo de ejecución de la API de la plataforma de almacenamiento conoce la manera en que estos nombres de propiedades se correlacionan con los nombres de campo de tipo de la plataforma de almacenamiento y, finalmente, con los formularios SQL que mantiene el almacén de la plataforma de almacenamiento. Considere los siguientes ejemplos: // Buscar todas las personas FindResult res1 = Person.FindAII(ctx) // Buscar a todas las personas que tienen un valor de propiedad Gender (género) igual a // "Male" (Masculino) FindResult res2 = Person.FindAII(ctx, "Gender='Male"') // Buscar a todas las personas que tienen un valor de propiedad Gender (género) igual a // "Male" (Masculino) y que nacieron en el milenio pasado. FindResult res3 = Person.FindAII( ctx, "Gender='Male' And Birthdate < '1/1/2001'") Las propiedades de los objetos anidados también se pueden usar en el filtro. Por ejemplo: // Buscar a todas las personas que se modificaron en las últimas 24 horas. FindResult res1 = Person.FindAII( ctx, String.Format("ltem. Modified > '{0}'",DateTime.Now.Subtract(new TimeSpan(24,0,0)))); Para las colecciones, es posible filtrar miembros usando una condición entre corchetes. Por ejemplo: // Buscar a todas las personas con el primer nombre "John" y el apellido // "Smith" FindResult res1 = Person.FindAII( ctx, "PersonalNames[GivenName = 'John' And Surname = 'Smith']") // Buscar a todas las personas con una dirección en tiempo real del proveedor 'x' // y con una categoría de estado en línea de 'y' FindResult res2 = Person.FindAII( ctx, "Personal R ealti meAddr e ss[ Prov iderU Rl-= 'x'].BasicPresence." + "OnlineStatus.Category = 'y"') el siguiente ejemplo enumera a. todas las personas que nacieron desde 31/12/1999: ItemContext ctx = ltemContext.Open("Work Contacts"); FindResult results = Person.FindAII( ctx, "Birthdate > '12/31/1999'" ); foreach( Person person ¡n results ) Console.WriteLine(person- .DisplayName); ctx.Close( ); La línea 1 crea un nuevo objeto ItemContext para acceder a "Contactos del trabajo" en la plataforma de almacenamiento que se comparte en la computadora local.

Las líneas 3 y 4 obtienen una colección de objetos Person en donde la propiedad Birthdate (cumpleaños) especifica una fecha más reciente que 12/31/1999, como se especifica con la expresión "Birthdate > '12/31/ 999'". La ejecución de esta operación FindAII se ilustra en la figura 23. b) Fusiones de tipo Con frecuencia se presenta el caso de que el tipo de un valor almacenado en una propiedad se deriva del tipo declarado de las propiedades. Por ejemplo, la propiedad PersonalEAddresses (Dirección electrónica personal) en Person (Persona) contiene una colección de tipos derivados de EAddress (Dirección electrónica) por ejemplo EMailAdress (Dirección de correo electrónico) y TelephoneNumber (Número telefónico) mudando. Para filtrar con base en el código telefónico de área es necesario hacer una fusión del tipo EAddress con el tipo TelephoneNumber: // Buscar todas las personas con un número telefónico dentro del código de área 425 FindResult res1 = Person. F i n d Al I ( ctx, "PersonalEAddresses." + "Cast(System.Sto ra ge. Contact. TelephoneNumber))." + "AreaCode = '425"'); // De manera alternativa, puede pasar el nombre del tipo como se indica a continuación: FindResult res1 = Person.FindAII( ctx, String. Format(" Pe rsonalEAddresses.Cast({0})).AreaCo de = - '425'", typeof(TelephoneNumber). FullName )) c) Sintaxis de filtro A continuación se presenta una descripción de la sintaxis del filtro que soporta la API de la plataforma de almacenamiento, de conformidad con una modalidad. Filter ::= EmptyFilter | Condition EmptyFilter : : = Condition ::= SimpIeCondition ) CompoundCondition | ParenthesizedCondition SimpIeCondition ::= ExistanceCheck | Comparison ExistanceCheck ::= PropertyReference Comparison ::= PropertyReference ComparisonOp Constant CompoundCondition ::= SimpIeCondition BooleanOp Condition ParenthesizedCondition ::= '(' Condition ')' ComparisonOp ::= «! = ' | '= =' | ' = ' | '<' | '>' | '> = ' | '< = ' BooleanOp ::= 'And' | '&&' | *Or' | '||' Constant ::= StringConstant | NumericConstatant StringConstant ::= "' (any Unicode character)* "' Nota: los caracteres ' incrustados se escapan por duplicidad NumericConstant ::= 0-9* PropertyReference ::= SimplePropertyName | CompoundPropertyName SimplePropertyName ::= (todos los caracteres Unicode excepto '.' y espacio)* Filter? Filter ::= '[' Condition ']' CompoundPropertyName :: = (Typecast | RelationshipTraversal | SimplePropertyName) '.' PropertyReference TypeCast ::= 'Cast(' TypeName ')' RelationshipTraversal ::= TraversalToSource | TraversalToTarget TraversalToSource ::= 'Source(' FullRelationshipName ')' TraversalToTarget ::= 'Targetf FullRelationshipName ')' TypeName ::= un nombre del tipo CLR completamente calificado FullRelationshipName ::= SchemaName RelationshipName SchemaName ::= the storage platformName RelationshipName ::= the storage platformName the storage platformName ::= como se define en [SchemaDef] 11. Acciones remotas a) Transparencia local/remota en la API El acceso a los datos en la plataforma de almacenamiento está dirigido a una instancia local en la plataforma de almacenamiento. La instancia local funciona como un ruteador si la consulta (o parte de ésta) se refiere a datos remotos. De esta manera, la capa de la API de proporcionar transparencia local/remota: no hay diferencia estructural en la API entre el acceso a los datos locales y remotos. Es meramente una función del enfoque solicitado. El almacén de datos de la plataforma de almacenamiento también implementa consultas distribuidas; esto es, es posible conectarse a una instancia de la plataforma de almacenamiento local si realizan una consulta que incluye elementos de diferentes volúmenes, algunos de los cuales se encuentran en un almacén local y otros en el almacén remoto. El almacén asocia los resultados y los presenta la aplicación. Desde el punto de vista de la API de la plataforma de almacenamiento (y por lo tanto el desarrollador de la aplicación) cualquier acceso remoto es completamente uniforme y transparente. La API de la plataforma de almacenamiento permite que una aplicación determine si un objeto ItemContext determinado (como lo devuelve el método ItemContext. Open (ContextodeElemento. Abrir)) representa una conexión local por remota usando la propiedad IsRemote (EsRemoto), ésta es una propiedad del objeto ItemContext. Entre otras cosas, se puede desear que la aplicación cuente con una retroalimentación visual para ayudar a configurar las expectativas del usuario de rendimiento, fiabilidad, etc. b) Implementación de la plataforma de almacenamiento en las acciones remotas Los almacenes de datos de la plataforma de almacenamiento se comuniquen usando un proveedor especial de la base de datos OLE, OLEDB, que se ejecuta sobre http (el proveedor predeterminado de la OLEDB usa TDS). En una modalidad, una consulta distribuida pasa por la funcionalidad OPENROWSET del motor de la base de datos de relación. Una función definida por el usuario especial (UDF): DoRemoteQuery(server, queryText) se proporciona para realizar las acciones remotas reales. c) Acceso a almacenes diferentes a la plataforma de almacenamiento En una modalidad de la plataforma de almacenamiento de la presente mención, no hay una arquitectura de proveedor genérico que permita que cualquier almacén participe en el acceso a los datos de la plataforma de almacenamiento. Sin embargo, se proporciona una arquitectura de proveedor limitada para el caso específico de Microsoft Exchange y Microsoft Active Directory (AD). Esto implica que los desabolladores pueden usar la API de la plataforma de almacenamiento y tener acceso a los datos en AD y Exchange justo como lo harían en la plataforma de almacenamiento, sin embargo los datos a los que pueden tener acceso están limitados a la plataforma de almacenamiento con tipos esquematizados. De esta manera, una libreta de direcciones (= colección de los tipos Person del plataforma de almacenamiento) tiene soporte en AD, correo, calendario y contactos que soporta Exchange. d) Relación con DFS Promotor de las propiedades de la plataforma de almacenamiento no promueve los puntos de soporte pasados. Aún cuando el espacio de nombre tiene una riqueza suficiente para acceder a los puntos de soporte, las consultas no pasan a través de éstos. Los volúmenes de la plataforma de almacenamiento pueden aparecer como nodos de hoja en un árbol DFS. e) Relación con GXA/índigo Un desarrollador puede usar la API de la plataforma de almacenamiento para exponer una "cabeza GXA" en la parte superior de almacén de datos. Conceptualmente, esto no es diferente de la creación de otros servicios de red. La API de la plataforma de almacenamiento no tiene comunicación con el almacén de datos de la plataforma de almacenamiento que usa GXA. Como se mencionó anteriormente, la API se comunica con el almacén local usando TDS; cualquier acción remota se maneja a través del almacén local usando el servicio de sincronización. 12. Restricciones El modelo de datos de la plataforma de almacenamiento permite restricciones de valores en los tipos. Estas restricciones se evalúan en el almacén de manera automática y el proceso es transparente para el usuario. Observan de que las restricciones se verifican en el servidor. Habiendo observado esto, algunas veces, es deseable para el desarrollador contar con flexibilidad para verificar que los datos ingresados satisfacen las restricciones sin incurrir en la sobrecarga de un viaje redondo al servidor. Esto es útil especialmente en las aplicaciones interactivas, donde el usuario final introduce los datos que se usan para llenar un objeto. La API de la plataforma de almacenamiento proporciona esta facilidad. Recuerde que un esquema de la plataforma de almacenamiento se especifica en un archivo XML, el cual se usa a través de la plataforma de almacenamiento para generar los objetos apropiados de la base de datos que representan el esquema. Este también lo usa la estructura del tiempo de diseño de la API de la plataforma de almacenamiento para generar de manera automática las clases. Aquí se muestra una lista parcial del archivo XML que se usa para generar el esquema Contacs: <Schema Name = "Contacts" MajorVersion = "1 " MinorVersion = "8"> < ReferencedSchema Name = "Base" ajorVersion = "1 " /> <Type Name = "Person" MajorVersion = "1 " MinorVersion = "0" ExtendsType = " Principal" ExtendsVersion = "1 "> <Field Name = "Birthdate" Type = "the storage platformTypes.datetime" Nullable = "true" MultiValued = "false" /> < Field Name = "Gender" Type = "the storage platformTypes.nvarchar(16)" Nullable = "true" Multi Valued = "false" /> < F i el d Name = "PersonalNames" Type = "FullName" TypeMajorVersion = "1" Nullable = "true" M ulti Valued = "true" /> <Field Name = "PersonalEAddresses" Type = "EAddress" TypeMajorVersion = "1 " Nullable = "true" Multi Valued = "true" /> < Field Name = "PersonaiPostalAddresses" Type = "PostalAddress" Type ajorVersion = "1 " Nullable = "true" Mult¡Valued = "true" /> <Check>expression</Check> </Type> </Schema> Las etiquetas Check (Comprobar) en el archivo XML anterior especifica las restricciones del tipo Person. Puede haber más de una etiqueta de comprobación. Las restricciones anteriores generalmente se comprueban en el almacén. Especifica que las restricciones también se pueden comprobar de manera explícita a través de la aplicación, el archivo XML anterior se modifica de esta manera: <Schema Name = "Contacts" MajorVersion = "1 " MinorVersion = "8"> <ReferencedSchema Name = "Base" MajorVersion = " 1 " /> <Type Name = "Person" ...> <Field Name = "Birthdate" Type = "the storage platformTypes.datetime" Nullable = "true" Multivalued = "false" /> <Check lnApplication = "true">expression</Check> </Type> </Schema> Observe que el atributo nuevo"l nApplication" en el elemento <Check>, que tiene un valor true. Esto hace que la API de la plataforma de almacenamiento recubra a la restricción en la API a través de un método de instancia en la clase Person denominado Validate( ). La aplicación puede invocar este método en el objeto para asegurar que los datos son válidos, y, evitar un viaje redondo potencialmente inútil al servidor. Esto devuelve un valor booleano para indicar el resultado de la validación. Observe que las restricciones de los valores se aplican al servidor sin importar si el cliente invoca el método <object>. Validate( ) o no. A continuación se da un ejemplo de la manera en que se puede usar Valídate: ItemContext ctx = ltemContext.Open( ); // Crear un contacto en la carpeta del usuario Mis Contactos. Folder f = UserDataFolder.FindMyPersonalContactsFolder( ctx ); Person p = new Person( f ); // Configurar el cumpleaños de la persona. p.Birthdate = new DateTime( 1959, 6, 9 ); // Agregar un nombre categorizado como un nombre personal FullName ñame = new FullName( FullName.Category.Primar Name ); name.GivenName = "Joe"; ñame. Su rn ame = "Smith"; p. PersonalNames.Add( ñame ); // validar el objeto Person si (p.Va!idate( ) = = false) { // los datos no representan una persona válida } // guardar los cambios p.Update( ); ctx.Close( ); Existen diversos trayectos de acceso para el almacén de la plataforma de almacenamiento, la API de la plataforma de almacenamiento, ADO.NET, ODBC, OLEDB y ADO. Esto genera la pregunta de comprobación de restricciones autoritaria, esto es, cómo se puede garantizar que los datos escritos desde, por ejemplo, ODBC, pasan por las mismas restricciones de integridad de datos como sería con los datos escritos desde la API de la plataforma de almacenamiento. Debido a que todas las restricciones se comprueban en el almacén, las restricciones ahora son autoritarios. Sin importar el trayecto de API que se use para llegar al almacén, todos los escritos en el almacén se filtran a través de las comprobaciones de restricciones en el almacén. 13. Compartir Una compartición en la paltaforma del almacén tiene la forma: \\<DNS Name>\<Context Service>, en donde <DNS Name> es el nombre DNS de la máquina y <Context Service> es la carpeta que lo contiene, carpeta virtual o un elemento en un volumen en esa máquina, por ejemplo, suponga quye la máquina "John's_Desktop" tiene un volumen denominado Johns_lnformation, y en este volumen existe una carpeta denominada Contacts_Categories: esta carpeta contiene una carpeta denominada Work, la cual tiene los contactos del trabajo para John: \\Johns_Desktop\Johns_lnformation$.ba-ckslash . Contacts_Categories\Work Esto se puede compartir como "WorkContacts". Con la definición de esta compartición, \\Johns_Desktop\WorkContacts\JaneSmith es un nombre de plataforma de almacenamiento válido, e identifica al elemento Persona JaneSmith. a) Representación de una acción de compartir El tipo de elemento compartir crecientes tropiezos: el nombre de la parte y el objetivo de la parte (esto puede ser un enlace que no tiene propiedad). Por ejemplo, el nombre de la parte mencionada es WorkContacts y el objetivo es Contacts_Categories\Work en el volumen Johns_!nformation. A continuación se muestra el fragmento del esquema para el tipo Share: <Schema xmlns = "http://schemas.microsoft.eom/winfs/2002/11/18/s chema" Name = "Share" MajorVersion = " 1 " MinorVersion = "0"> <ReferencedSchema Name = "Base" MajorVersion = "1 "/> <ReferencedSchema Name = "the storage platformTypes" MajorVersion = " 1 "/> <Type Name = "Share" MajorVersion = " " MinorVersion = "0" ExtendsType = " Base. Item" ExtendsVersion = "1"> <Field Name = "Name" Type = "the storage platformTypes. n va rch a r (512)" TypeMajorVersion = " 1 "/> <Field Name="Target" Type = "Base.RelationshipData" TypeMajorVersion = "1 "/> </Type> </Schema> b) Gestión de las partes Debido a que una parte es un elemento, las partes se puede gestionar igual que otros elementos. Una parte se puede crear, eliminar y modificar. Una parte también se asegura de la misma manera que otros elementos de la plataforma de almacenamiento. c) Acceso a las partes Una aplicación accede a una parte de la plataforma de almacenamiento remoto al pasar el nombre de la parte (por ejemplo, \\Johns_Desktop\WorkContacts) a la API de la plataforma de almacenamiento en la invocación al método de ltemContext.Open( ). ItemContext.Open devuelve una instancia de objeto ItemContext. La API de la plataforma de almacenamiento entonces se comunica con el servicio de la plataforma de almacenamiento local (recuerde que el acceso a las partes de la plataforma de almacenamiento remoto se realiza a través de la plataforma de almacenamiento local). En su momento, el servicio de la plataforma de almacenamiento local se comunica con un servicio de la plataforma de almacenamiento remota (por ejemplo, en la máquina Johns_Desktop) con el nombre de la parte determina (por ejemplo, WorkContacts). El servicio de la plataforma de almacenamiento remota entonces traduce WorkContacts en Contacts_Categories\\Work y la abre. Después de esto, se realiza la consulta y otras operaciones igual que otros enfoques. d) Capacidad de descubrimiento En una modalidad, un programa de aplicación puede descubrir partes disponibles en un <DNS Name>, de las siguientes maneras. De conformidad con la primera manera, la API de la plataforma de almacenamiento acepta un nombre de DNS (por ejemplo, Johns_Desktop) como el parámetro de enfoque en el método ltemContext.Open( ). La API de la plataforma de almacenamiento entonces se conecta al almacén de la plataforma de almacenamiento con este nombre DNS como parte de una cadena de conexión. Con esta conexión, la única cosa posible que una aplicación puede hacer es invocar el método ItemContext. FindAII(typeof(Share)). Entonces, un servicio de la plataforma de almacenamiento asocia todas las partes en todos los volúmenes anexados y devuelve la colección de partes. De conformidad con la segunda manera, en una máquina local, un administrador puede descubrir fácilmente las partes en un volumen particular a través del método FindAII(typeof (Share)), o una carpeta particular a través de FindAII(typeof(Share)), "Target(ShareDestination).ld folderld". 14. Valores semánticos de la búsqueda Los métodos de búsqueda Find* (sin importar i se invocan en el objeto ItemContext o en un elemento individual) generalmente aplican a los Elemntos (inicuyendo los elementos incrustados) dentro de un contexto determinado. Los elementos anidados no tienen un método de búsqueda Find, no se pueden buscar de manera independiente de sus elemenentos que los contienen. Esto es consistente con la semántica deseada a través del modelo de datos de la plataforma de almacenamiento, en donde los elementos anidados derivan su "identidad" del elemento que los contiene. Para hacer más clara esta idea, aquí se muestran ejemplos de operaciones de búsqueda válidas y no válidas: a) Mostrar todos los número telefónicos en el sistema que tengan un código de área 206 ? No es válida, ya que la búsqueda e realiza en los número telefónicos, un elemento, sin hacer referencia a un elemento. b) Mostrar todos los números telefónicos dentro de Persons que tengasn un código de área 206 ? No es válida, aunque está lareferencia a Person ( = EIemento), el criterio de búsqueda tiene un código de área de 206 ? c) Mostrar todos los números telefónicos de Murali ( = una sóla persona) que tengan códigos de área 206 ? Válida, ya que hay un criterio de búsqueda en eun Elemento (una Persona llamada "Murali"). La excepción a esta regla es para los tipos de elementos anidados que se derivan de manera directa o indirecta del tipo Base. Relationship. Estos tipos se puden consultar de manera individual a través de las clases de relación. Dichas consultas se pueden soportar debido a que la implementación de la plataforma de almacenamiento emplea una "tabla de enlaces maestros" para almacenar los elementos de relaciones en lugar de incrustarlos dentro de los UDT del elemento. 15. API de contactos de la plataforma de almacenamiento Esta sección proporciona una descripción general de la API de contactos de la plataforma de almacenamiento. El esquema detrás de la API de contactos se muestra en las figuras 21 A y 21 B. a) Descripción de System.Storage.Contact La API de la plataforma de almacenamiento incluye un espacio de nombre para tratar los elementos dentro del esquema de contactos. Este espacio de nombre se denomina System.Storage.Contact. Este esquema tiene, por ejemplo, las siguientes clases: • Items: UserDataFolder, User, Person, ADService, Service, Group, Organization, Principal, Location. · Elements: Profile, PostalAddress, EmailAddress, TelephoneNumber, RealTimeAddress, EAddress, FullName, BasicPresence, GroupMembership, RoleOccupancy. b) Conductas de dominio A continuación se presenta una lista de comportamientos para el esquema Contacts. Cuando se visualiza desde un nivel alto suficiente, los comportamientos de dominio caen en las categorías bien identificables: • Ayuda estática, por ejemplo, Person. CreatePersonalContact( ) para crear un contacto personal nuevo; • Ayuda de instancia, por ejemplo user.AutoLoginToAIIProfiles( ), que conecta un usuario (instancia de clase User) en todos los perfiles que están marcados para la conexión automática; · CategoryGUIDs, por ejemplo, Category . Home, Category.Work, etc; • Propiedades derivadas, por ejemplo, emailAddress. Address( ) — devuelve una cadena que combina los campos username (nombre de usuario) y domain (domino) de la dirección de correo electrónico determinada, emailAddress ( = instanc¡a de la clase EmailAddress); y • Colecciones derivadas, por ejemplo, person. PersonalEmailAddresses — dada una instancia de clase Person, obtiene sus direcciones de correo electrónico personal. La tabla que se muestra continuación proporciona, para cada clase en Contacts que tiene comportamientos de dominio, una lista de estos métodos y la categoría a la que pertenecen.

TAB LA XX BasicPresence URI de UnknownCategoryURI (URI de categoría desconocida), (Presencia básica) categoría OfflineCategoryURI (URI de categoría fuera de línea), BusyCatégoryURI (URI de categoría ocupada), AwayCategoryURI (URI de categoría alejada), OnlineCategoryURI (URI de categoría en línea). Ayuda estática ConvertPresenceStateToString (ConvertirEstadodePresenciaEnCadena)- da formato al estado de la presencia como una cadena localizada (la localización real necesita agregarse; ólo hace una cadena sencilla en inglés). Category GUID de la Home (Casa), Work (Trabajo), Primary (Principal), Secondary (Categoría) categoría (Secundario), Cell (Célula), Fax, Pager (Localizador). EmailAddress Propiedades Address (Dirección) - combina el nombre del usuario y el (Dirección de correo derivadas dominio. electrónico) Ayuda estática IsValidEmailAddress (Dirección de correo electrónico válida).

Folder (Carpeta) Propiedades GetChildltemCollection derivadas (ObtenerColeccióndeElementosSecundarios) - Hace una colección de elementos con base en los Objetivos de FolderMembership (MembresíadeCarpeta). Ayuda estática GetKnownFolder (ObtenerCarpetaConocida) - consultas especializadas para obtener carpetas ya conocidas. AddToPersonalContacts (AgregarAContactosPersonales) - agrega un elemento a una carpeta de contactos personales ya conocida. Items (Elementos) Ayuda estática GetltemFromlD (ObtenerElementodeID) - hace una consulta basada en los ID. Relationship Ayuda de BindToTarget (UnidoAIObjetivo) - devuelve el elemento para (Relación) Instancia ese objetivo. Person (Persona) Colecciones PersonalRealtimeAddresses derivadas (DireccionesPersonalesEnTiempoReal), PersonalEmailAddresses (DireccionesDeCorreo ElectrónicoPersonales), PersonalTelephoneNumbers (Números TelefónicosPersonales). Propiedades OnlineStatus (EstadoEnLínea), OnlineStatusIconSource derivadas (Fuentedellconode EstadoenLínea), PrímaryEmailAddress (DirecciónPrincipaldeCorreoEIectrónico), PrimarySecuritylD (IDdeSeguridadPrincipal). Ayuda estática CreatePersonalContact (CrearContactoPersonal), CreateTemporaryContact (CrearContactoTemporal) - crea una nueva persona en una carpeta ya conocida. GetCurrentUser (ObtenerUsuarioActual) - obtiene la información de la persona del usuario que está conectado al sistema en el momento. SecuritylD Propiedades UserName (NombredeUsuario) , DomainName (Identificador de derivadas (NombredeDominio), DomalnUserName Sequridad) (NombredeUsuariodeDominio) TelephoneNumber Ayuda de SetFromUserlnputString (Número telefónico) instancia (EstablecerDesdelaCadenadeEntradadelUsuario) - analiza la cadena del número telefónico en partes. Ayuda estática ParseNumber (AnalizarNúmero)- analiza la cadena del número telefónico en partes. User (Usuario) Ayuda de AutoLoginToAIIProfiles (ConexiónAutomátícaA instancia TodosLosPerfiles)- establece una conexión en todos los perfiles que están marcados para una conexión automática. 16. API de los archivos de la plataforma de almacenamiento Esta sección proporciona una descripción general de la API de archivos de la plataforma de almacenamiento, de conformidad con una modalidad de la presente invención. a) Introducción (1) Reflejo de un volumen de NTFS en la plataforma de almacenamiento La plataforma de almacenamiento proporciona una manera para generar un índice sobre el contenido de los volúmenes de NTFS ya existentes. Esto se logra al extraer ("promover") las propiedades de cada flujo de archivos o directorio en NTFS y almacenar esas propiedades como elementos en la plataforma de almacenamiento. El esquema de archivos de la plataforma de almacenamiento define dos tipos de elementos, File (archivo) y Directory (directorio), para almacenar las entidades del sistema de archivos promovidos. El tipo Directory es un subtipo del tipo Folder; es una carpeta de contención que contiene otros elementos del directorio o elementos de archivos. Un elemento Directory puede contener elementos Directory y File, no puede contener elementos de ningún otro tipo. En lo que se refiere a la plataforma de almacenamiento, los elementos Directory y File son de sólo lectura para cualquiera de las API de acceso a los datos. El servicio del gestor de promoción del sistema de archivos (FSPM) promueve de manera asincrona de las propiedades cambiadas en la plataforma de almacenamiento. Las propiedades de los elementos File y Directory pueden cambiar a través de la API de Win32. La API de la plataforma de almacenamiento se puede usar para leer cualquiera de las propiedades de estos elementos, incluyendo el flujo asociado con un elemento File. (2) Creación de archivos y directorios en el espacio de nombre de la plataforma de almacenamiento Cuando un volumen NTFS se promueve a un volumen de la plataforma de almacenamiento, todos los archivos y directorios del volumen se encuentran una parte específica de dicho volumen. Esta área es de sólo lectura desde la perspectiva de la plataforma de almacenamiento; el FSPM puede crear nuevos directorios y archivos y/o cambiar las propiedades de los elementos existentes. El resto del espacio de nombre de este volumen puede contener la gama usual de los tipos de elementos de la plataforma de almacenamiento, Principal, Organization, Document, etc. la plataforma de almacenamiento también permite crear archivos y directorios en cualquier parte del espacio de nombre de la plataforma de almacenamiento.

Estos archivos y directorios "nativo" no tienen una contraparte en el sistema de archivos NTFS; se almacenan por completo la plataforma de almacenamiento. Además, los cambios a las propiedades son visibles de inmediato. Sin embargo, el modelo de programación sigue siendo el mismo: aún son de sólo lectura en lo que se refiere a las API de acceso a los datos de la plataforma de almacenamiento. Los archivos y directorios "nativos" deben actualizarse usando las API de Win32. Esto simplifica el modelo mental del desarrollador el cual es: 1. Cualquier tipo de elemento en la plataforma de almacenamiento se puede crear en cualquier lugar dentro del espacio de nombre (a menos que lo evite algún permiso, desde luego); 2. Cualquier tipo de elemento en la plataforma se puede leer usando la API de la plataforma de almacenamiento; 3. Cualquier tipo de elemento en la plataforma es escribible usando la API de la plataforma de almacenamiento, excepto por los elementos File y Directory; 4. Para escribir los elementos File y Directory sin importar el lugar donde se encuentren dentro del espacio de nombre, se usa la API de Win32; y 5. Los cambios que se hagan a los elementos File/Directory en el espacio de nombre "promovidos" pueden no aparece de inmediato en la plataforma de almacenamiento; en el espacio de nombre "no promovidos", los cambios se reflejan de inmediato dentro de la plataforma de almacenamiento. b) Esquema de archivos La figura 25 ilustra el esquema en el que se basa la API de File.. c) Descripción de System .S tora ge. Files La API de la plataforma de almacenamiento incluye un espacio de nombre para tratar los objetos de los archivos. Este espacio de nombre se denomina System. Storage. Files. Los miembros de los datos de las clases dentro de System. Storage. Files reflejan de manera directa la información que se almacena en el almacén de la plataforma de almacenamiento; esta información se "promueve" desde los objetos del sistema de los archivos o se pueden crear de manera nativa usando la API de Win32. El espacio de nombre System. Storage. Files cuenta con dos clases: Fileltem (ElementoArchivo) y Directoryltem (ElementoDirectorio). Los miembros de estas clases y métodos de los mismos se pueden descubrir al observar el diagrama del esquema que se muestra en la figura 25. Fileltem y Directoryltem son de sólo lectura desde la API de la plataforma de almacenamiento. Para poder modificar los, se debe usar la API de Win32 o las clases en el sistema System.10. d) Ejemplos de códigos En esta sección, se proporcionan tres ejemplos de códigos que ilustran el uso de las clases en System. Storage. Files. (1) Cómo abrir un archivo y escribir en él Este ejemplo muestra cómo hacer una manipulación "tradicional" de un archivo. ItemContext ctx = ltemContext.Open( ); Fileltem f = Fileltem.FindByPath(ctx, @"\My Documents\billg. ppt"); // ejemplo del manejo de las propiedades de un archivo, asegúrese de que el archivo // no es de sólo lectura if (.'f.IsReadOnly) { FileStream fs = f .OpenWrite( ); // Leer, escribir, cerrar flujo de archivos fs } ctx.CIose( ); La línea 3 usa el método FindByPath para abrir el archivo. La línea 7 muestra el uso de la propiedad promovida, IsReadOnly, para comprobar si se puede escribir en el archivo. Si es así, entonces en la línea 9 se usa el método OpenWrite( ) en el objeto Fileltem para obtener el flujo de archivos. (2) Uso de consultas Debido que el almacén de la plataforma de almacenamiento contiene propiedades promovidas desde el sistema de archivos, es posible realizar consultas enriquecidas en los archivos. En este ejemplo, se enumeran todos los archivos modificados en los últimos tres días: // Enumerar todos los archivos modificados durante los últimos tres días FindResult result = Fileltem. Find AII( ctx, "Modified >= '{0}"', DateTime.Now.AddDays(-3)); foreach ( Fileltem file in result ) { } Se muestra otro ejemplo del uso de las consultas, ésta busca todos los archivos en los que se puede escribir de cierto tipo (= extensión): // Buscar todos los archivos .es en los que se puede escribir en un directorio particular. // Equivalente a: dir c:\win\src\api\*. es /a-r-d Directoryltem dir = Directoryltem.FindByPath(ctx, @"c:\win\src\- api"); FindResult result = dir.GetFiles( "Extension^cs* and lsReadOnly = false"); foreach ( File file in result ) { } e) Comportamientos de dominio En una modalidad, además de las propiedades y métodos estándares, la clase de archivo también tiene comportamientos de dominio (propiedades y métodos codificados manualmente). Estos comportamientos generalmente se basan en los métodos de las clases correspondientes en el System. IO. J. CONCLUSIONES Como se ilustra en la presente descripción, la presente invención está dirigida a una plataforma de almacenamiento para organizar, buscar y compartir datos. La plataforma de almacenamiento de la presente invención extiende y amplía el concepto de almacenamiento de datos más allá de los sistemas de archivos existentes y los sistemas de base de datos existentes, y está diseñada para almacenar todo tipo de datos, incluyendo datos estructurados, no estructurados o semiestructurados, como los datos relaciónales (tabulares), XML y una nueva forma de datos denominada Elementos. A través de estos fundamentos del almacenamiento común y datos esquematizados, la plataforma de almacenamiento de la presente invención habilita un desarrollo más eficiente de la aplicación para los clientes, trabajadores intelectuales y las empresas. Ofrece una interfase de programación de aplicaciones rica y extensible que no sólo ofrece la disponibilidad de las capacidades inherentes a este modelo de datos, también involucra y extiende el sistema de archivos existentes y los métodos de acceso a la base de datos. Se entiende que es posible hacer cambios a las modalidades descritas en los párrafos anteriores sin separarse de los amplios conceptos novedosos de la misma. De esta manera, la presente invención no está limitada a las modalidades particulares reveladas, mas tiene la intención de cubrir todas las modificaciones que se encuentran dentro del espíritu y alcance de la invención como se define en las reivindicaciones anexas. A partir de lo anterior, será evidente que todo o las porciones de diversos sistemas, métodos y aspectos de la presente invención se pueden representar en forma de un código de programa (es decir, instrucciones). Este código de programa se puede almacenar en un medio legible por computadora, por ejemplo un medio de almacenamiento magnético, eléctrico u óptico, incluyendo sin limitarse a esto, un disco flexible, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, cinta magnética, memoria instantánea, unidad de disco duro u otro medio de almacenamiento legible a través de una máquina, en donde, cuando el código de programa se carga y se ejecuta mediante una máquina, como una computadora o servidor, la máquina se convierte en un aparato para practicar la invención. La presente invención también se puede representar en forma de un código de programa que se transmite sobre algún medio de transmisión, por ejemplo a través de un cableado eléctrico o alambrado eléctrico, a través de fibra óptica, sobre una red, incluyendo Internet o una red interna, o a través de cualquier otra forma de transmisión, en donde, cuando el código de programa se recibe, se carga y se ejecuta a través de una máquina, por ejemplo una computadora, la máquina se convierte en un aparato para practicar la invención. Cuando se implementa en un procesador de objetivo general, el código de programa se combina con el procesador para proveer un aparato único que funciona de manera análoga para especificar los circuitos lógicos. APÉNDICE A namespace System. Storage { abstract class ItemContext : IDisposable, IserviceProvider { Creación de ItemContext v miembros de gestión // Las aplicaciones no pueden crear objetos ItemContext directamente ni pueden derivar // clases desde ItemContext. interal ltemContext( ); // Crear ItemContext que se puede usar para buscar los trayectos especificados o, si no // se ha especificado un trayecto, el almacén predeterminado en la computadora local. public static ItemContext Open( ); public static ItemContext Open( string path ); public static ItemContext Open( params string[ ] paths ); // Devuelve los trayectos especificados cuando se creó el ItemContext. public string[ ] GetOpenPaths( ); // Crea una copia de este ItemContext. La copia tendrá una transacción, memoria // intermedia y estado de actualización independiente. La memoria intermedia inicialmente // estará vacía. Se espera que el uso de un ItemContext clonado será más eficiente que // abrir un nuevo ItemContext usando los mismos dominios del elemento. public ItemContext Clone( ); // cerrar el ItemContext. Cualquier intento de uso del ItemContext después de cerrarlo // generará una ObjectDisposedException. public void Close( ); void IDisposable.Dispose( ); // Es verdadero si cualquier dominio especificado cuando se abrió el ItemConext se // resolvió para una computadora remota, public bool IsRemote { get; } // Devuelve un objeto que puede proporcionar el tipo de servicio solicitado. Devuelve un // valor nulo si el servicio solicitado no se puede proveer. El uso del patrón // IServiceProvider permite las API que no se usan normalmente y puede confundir a los // desabolladores para que factoricen en fuera de la clase ItemContext. ItemContext // puede proveer los siguientes tipos de servicios: lltemSerialization, Is to re Object Cache public object GetService( Type serviceType ); Actualización de miembros relacionados // Guarda los cambios representados por todos los objetos modificados y todos los objetos // que pasan a MarkForCreate o MarkForDelete. Pueden arrojar una // UpdateCollisionException si se detecta una colisión en la actualización. public void Update( ); // Guarda los cambios representados por los objetos especificados. Los objetos deben // haber sido modificados o pasados a MarkForCreate o MarkForDelete, de otra manera // se arroja una excepción de argumento. Pueden arrojar una UpdateCollisionException // si se detecta una colisión en la actualización. public voidUpdate( object objectToUpdate); public void Update( lEnumerable objectsToUpdate ); // Regenera el contenido de los objetos especificados del almacén. Si ios objetos han // sido modificados, los cambios se sobrescriben y los objetos ya no se consideran // modificados. Arroja una ArgumentException si se especifica cualquier otra cosa // diferente a un objeto de elemento, extensión de elemento, o relación. public void Refresh( object objectToRefresh ); public void Refresh( lEnumerable objectsToRefresh ); // Se genera cuando una actualización detecta que los datos han cambiado en el almacén // entre el momento en que un objeto modificado se recuperó y se hizo un intento para // guardarlo. Si no se registra un manejador de eventos, la actualización arroja una // excepción. Si se registra un manejador de eventos, puede arrojar una excepción para // abortar la actualización, reconocer el objeto modificado para sobre escribir los datos // en el almacén o fusionar los cambios hechos en el almacén y en el objeto. public event ChangeCollisionEventHandler UpdateCollision; // Se genera en varios puntos durante el procesamiento de actualización para proveer // información del avance de la actualización, public event UpdateProgressEventhandIer UpdateProgress; // Versiones asincronas de actualización. public lAsyncResult BeginUpdate( lAsyncCalIback callback, object state ); public lAsyncResult BeginUpdate( object objectToUpdate, lAsyncCalIback callback, object state ); public lAsyncResult BeginUpdate( lEnumerable objectsToUpdate, lAsyncCalIback callback, object state ); public void EndUpdate( lAsyncResult result ); // Versión asincrona de regenerar. public lAsyncResult BeginRefresh( object objectToRefresh, lAsyncCallback callback, object state ); public lAsyncResult BeginRefresh( lEnumerable objectsToRefresh , lAsyncCallback callback, object state ); public void EndRefresh( lAsyncResult result ); Miembros relacionados con la transacción // Comienza una transacción con el nivel de aislamiento especificado. El nivel de // aislamiento predeterminado es ReadCommited. En todos los casos, se inicia una // transacción distribuida debido a que puede ser necesario incluir flujo de cambios con // clasificación de propiedades por elemento, public Transaction BeginTransaction( ); public Transaction BeginTransact¡on( System. Data. IsolationLevel isolation Level ); Búsqueda de miembros relacionados // Crea un ItemSearcher creará una búsqueda en este contexto de elemento de los // objetos del tipo especificado. Arroja una ArgumentException si se especifica un tipo // diferente a un elemento, relación, o extensión de elemento. public ItemSearcher GetSearcher( Type type); // Busca un elemento dado su id. public Item FindltemByld( Itemld ¡temld ); // Busca un elemento teniendo su trayecto. El trayecto puede ser absoluto o relativo. Si es // relativo se arroja una NotSupportedException si se especificaron varios dominios de // elemento cuando se abrió el ItemContext. Devuelve un valor nulo si no existe un // elemento tal. Crea una conexión con la parte \\machine\share del dominio para // recuperar el elemento. El elemento estará asociado con ese dominio. public Item FindltemByPath( string path ); // Buscar un elemento dado su trayecto. El trayecto es relativo al dominio del elemento // especificado. Crea una conexión al dominio especificado para recuperar el elemento. Él // estará asociado con ese dominio. Devolverá nulo si no existe un elemento tal. public Item FindltemByPath( string domain, string path ); // Busca un conjunto de elementos dado un trayecto. El trayecto es relativo a los dominios // del elemento especificados cuando se abrió el ItemContext. Devolverá un resultado // vacío si no existe un elemento tal. public FindResult FindAllltemsByPath( string path ); // Buscar una relación dadas sus id. public Relationship FindRelationshipByld( Itemld itemlD, Relationshipld relationshipld ); // Buscar una extensión de elemento dadas sus id. public ItemExtension FindltemExtensionByld( Itemld itemld, ItemExtensionld itemExtensionld ); // Buscar todos los elementos, relaciones o extensiones de elementos del tipo // especificado opcionalmente que satisfaga un filtro determinado. Arroja una // ArgumentException si se especifica un tipo diferente a éstos. public FindResult Find AII( Type type ); public FindResult FindAII( Type type, string filter ); // Buscar cualquier elemento, relación o extensión de elemento del tipo especificado que // satisfaga un filtro determinado. Arroja una ArgumentException si se especifica //un tipo diferente a éstos. Devuelve nulo si no se encuentra un objeto tal. public object FindOne( Type type, string filter ); // Busca el elemento, relación o extensión de elemento en del tipo especificado que // satisfaga un filtro determinado. Arroja una ArgumentException si se especifica un tipo // diferente a éstos. Arroja ObjectNotFound Exception si no se encuentra ningún objeto tal. //Arroja MultipleObjectsFoundException si encuentra más de un objeto. public object FindOnly( Type type, string filter ); // Devuelve verdadero si existe un elemento, relación o extensión de elemento del tipo // especificado que satisfaga un filtro determinado. // Arroja una ArgumentException si se especifica un tipo diferente a éstos. public bool Exists( Type type, string filter ); // Especifica cómo los objetos devueltos por una búsqueda se relacionan con la // correlación de identidad del objeto mantenida por ItemContext. public SearchCollisionMode SearchCollisionMode { get; set; } // Se genera cuando se especifica PreserveModifiedObjects para ResuItMapping. Este // evento permite que la aplicación actualice de manera selectiva el objeto modificado con // los datos recuperados con la búsqueda. public event ChangeCollisionEventHandler SearchCollision; // Incorpora un objeto desde otro ItemContext en este contexto de elemento. Si un objeto // que representa al mismo elemento, relación o extensión de elemento no existe ya // esta correlación de identidad de ItemContext , se crea un a clon del objeto y se agrega a // la correlación. Si ya existe un objeto, se actualiza con el estado y contenido del objeto // especificado de una manera consistente con el modo S e a r c h C o 11 i s i o n M o d e . public Item I ncorporateltem( Item ¡tem ); public Relationship lncorporateRelationship( Relationship relationship ); public ItemExtension lncorporateltemExtension( ItemExtension ¡temExtension ); } // Manejador para los eventos ItemContext. UpdateCollision e // ItemSearcher. SearchCollision. public delégate void ChangeCollisionEventHandler( object source, ChangeCollisionEventArgs args ); // Argumentos para el delegado ChangeCollisionEventHandler. public class ChangeCollisionEventArgs : EventArgs { // Objeto de elemento, extensión de elemento o relación modificado. public object ModífiedObject { get; } // Propiedades del almacén. public IDictionary StoredProperties { get; } } // Manejador para ItemContext.UpdateProgress. public delégate void UpdateProgressEventHandler( ItemContext itemContext, UpdateProgressEventArgs args ); // Argumentos para el delegado UpdateProgressEventHandler. public class ChangeCollisionEventArgs : EventArgs { // La operación de actualización en curso, public UpdateOperation CurrentOperation { get; } // El objeto que se está actualizando, public object CurrentObject { get; } } // Especifica la manera en que los objetos se devuelven por una búsqueda se refiere a la // correlación de identidad de los objetos que mantiene el ItemContext. public enum SearchCollisionMode { // Indica que los nuevos objetos deben crearse y devolverse. Se ignora a los objetos que // representan al mismo elemento, extensión de elemento o relación en la correlación de // identidad. Si esta opción se identifica no se genera el evento SearchCollision. DoNotMapSearchResults, // Indica que los objetos de la correlación de identidad deben devolverse. Si la aplicación // modificó el contenido de un objeto, el contenido del objeto modificado se conserva. // Si el objeto no se ha modificado, su contenido se actualiza con los datos devueltos // por la búsqueda. La aplicación puede proporcionar un manejador para el evento // SearchCollision y actualizar de manera selectiva el objeto como se desee. P reserve odifiedObjects, // Indica que los objetos de la correlación de identidad deben ser devueltos. El contenido // del objeto se actualiza con los datos devueltos por la búsqueda, incluso si el objeto // fue modificado por la aplicación. Si se especifica esta opción, el evento Search- // Collision no se generará. OverwriteModifiedObjects } // La operación de actualización en curso. public enum UpdateOperation { // Se proporciona cuando se invoca por primera vez el método Update. CurrentObject será // nulo. OverallUpdateStarting, // Se proporciona justo antes de que Update regrese después de una actualización // satisfactoria. CurrentObject será nulo. OverallUpdateCompletedSucessfully, // Se proporciona justo antes de que Update arroje una excepción. CurrentObject será el // objeto de excepción. OverallUpdateCompletedUn-successfully, // Se proporciona cuando la actualización de un objeto inicia. CurrentObject hará // referencia al objeto que se usará para lo actualizado. ObjectUpdateStaring, // Se proporciona cuando se necesita una nueva conexión. CurrentObject será una // cadena que contiene el trayecto que identifica un dominio del elemento como pasó a // ItemContext. Open o como se recuperó desde el campo Location de una relación. OpeningConnection } } APÉNDICE B namespace System. Storage { // Executa una búsqueda a través de un tipo específico en un contexto del elemento, public class ItemSearcher { Constructores public ltemSearcher( ); public ltemSearcher( Type targetType, ItemContext context ); public ltemSearcher( Type targetType, ItemContext context, params SearchExpression[ ] filters ); Propiedades // Los filtros que se usan para identificar los objetos que corresponden. public SearchExpressionCollection Filters {get;} // El ItemContext que especifica los dominios en donde se hará la búsqueda. public ItemContext ItemContext {get; set;} // La colección del parámetro de búsqueda, public ParameterCollection Parameters {get;} // El tipo en el que operará el buscador. Para búsquedas simples éste es el tipo // que será devuelto. public Type TargetType {get; set;} Métodos de búsqueda // Buscar objetos de TargetType que satisfacen las condiciones especificadas por los // filtros. Devuelve un campo FindResult vacío si no existe un objeto tal. public FindResult Find Ail( ); public FindResult FindAII( FindOptions findOptions ); public FindResult FindAII( params SortOption[ ] sortOptions ); // Buscar cualquier objeto TargetType que satisfacen las condiciones especificadas por los // filtros. Devuelve nulo si no existen objetos tales, public object FindOne( ); public object FindOne( FindOptions findOptions ); public object F¡ndOne( params SortOption[ ] sortOptions ); // Buscar el objeto TargetType que satisface las condiciones especificadas por los filtros. // Arroja una ObjectNotFoundException si no se encuentra un objeto tal. Arroja una // MuItipIeObjectsFoundException si se encuentra más de un objeto. public object FindOnly( ); public object FindOnly( FindOptions findOptions ); // Determinar si un objeto de TargetType que satisface las condiciones especificadas por // los filtros existe, public bool Exists( ); // Crea un objeto que se puede usar para ejecutar de manera más eficiente la misma // búsqueda en repetidas ocasiones, public PreparedFind PrepareFind( ); public PreparedFind PrepareFind( FindOptions findOptions ); public PreparedFind PrepareFind( params SortOption[ ] sortOptions ); // Recupera el número de registros que serán devueltos por FindAII( ). public int GetCount( ); // Versiones asincronas de varios métodos. public lAsyncResult BeginFindAII( AsyncCalIback callback, object state ); public lAsyncResult BeginFindAII( FindOptions findOptions, AsyncCalIback callback, object state ); public lAsyncResult BeginFindAII( SortOption[ ] sortOptions, AsyncCallback callback, object state ); public FindResult EndFindAII( lAsyncResult ar ); public lAsyncResult BeglnFindOne( AsyncCallback callback, object state ); public lAsyncResult BeginFlndOne( FindOptions findOptions, AsyncCallback callback, object state ); public lAsyncResult BeginFindOne( SortOption[ ] sortOptions, AsyncCallback callback, object state ); public object EndFindOne( lAsyncResult asyncResult ); public lAsyncResult BeginFindOnly( AsyncCallback callback, object state ); public lAsyncResult BeginFindOnly( FindOptions findOptions, AsyncCallback callback, object state ); public lAsyncResult BeglnFindOnly( SortOptionf ] sortOptions, AsyncCallback callback, object state ); public object EndFindOnly( lAsyncResult asyncResult ); public lAsyncResult BeginGetCount( AsyncCallback callback, object state ); public int EndGetCount( lAsyncResuIt asyncResuIt ); public lAsyncResuIt BeginExists( AsyncCalIback callback, object state ); public bool EndExists( lAsyncR sult asyncResuIt ); // Opciones usadas al ejecutar una búsqueda, public class FindOptions { public FindOptions( ); public FindOptions( params SortOpt¡on[ ] sortOptions ); // Especifica si los campos que se pueden cargar con demora deben estar cargados con // demora. public bool DelayLoad {get; set;} // El número de correspondencias que se devuelven. public ¡nt MaxResults {get; set;} // Una colección de opciones de clasificación, public SortOptionCollection SortOptions {get;} } // Representa un nombre y valor de parámetro. public class Parameter { // Iniciaiiza un objeto de parámetro con un nombre y valor, public Parameter( string ñame, object valué ); // El nombre del parámetro. public string Ñame {get;} // El valor del parámetro, public object Valué {get; set;} } // Una colección de pares de nombre / valor de parámetro, public class ParameterCollection : Icollection { public ParameterCollection( ); public ¡nt Count {get;} public object this[string ñame] {get; set;} public object SyncRoot {get;} public void Add( Parameter parameter ); public Parameter Add( string ñame, object valué); public bool Contains( Parameter parameter ); public bool Contains( string ñame); public void CopyTo( Parameter[ ] array, int index ); void ICollection.CopyTo( Array array, int index ); lEnumerator IEnumerable.GetEnumerator( ); public void Remove( Parameter parameter ); public void Remove( string ñame ); } // Representa una búsqueda que se ha optimizado para una ejecución repetida, public class PreparedFind { public ItemContext ItemContext {get;} public ParameterCollection Parameters {get;} public FindResuIt FindAII( ); public object FindOne( ); public object FindOnIy( ); public bool Exists( ); } // Especifica las opciones de clasificación que se usan en una búsqueda. public class SortOption { // Inicializa un objeto con valores predeterminados, public SortOption( ); // Inicializa un objeto SortOptions con SearchExpression, orden. public SortOption( SearchExpression SearchExpression, SortOrder order ); // Una búsqueda SearchExpression que identifica la propiedad que será clasificada. public SearchExpression Expression {get; set;} // Especifica el orden ascendente o descendente de clasificación. public SortOrder Order {get; set;} } // Una colección de objetos de opción de clasificación, public class SortOptionCollection : llist { public SortOptionCollection( ); public SortOption th i s [i nt index] {get; set;} public int Add( SortOption valué ); public int Add( Search Expression expression, SortOrder order ); int IList.Add( object valué ); public void CIear( ); public bool Contains( SortOption valué ); bool IList.Contains( object valué ); public void CopyTo( SortOption[ ] array, int index ); void ICollection.CopyTo( Array array, int index ); public int Count {get;} iEnumerator I Enumerable. GetEnumerator( ); public void lnsert( int index, SortOption valué ); void IList. Insert( int index, object valué ); public int lndexOf( SortOption valué ); int IList. IndexOf( object valué ); public void Remove( SortOption valué ); void I List. Remove( object valué ); public void RemoveAt( int index ); public object SyncRoot {get;} } // Especifica el orden de clasificación que se usa en un objeto SortOption. public enum SortOrder { Ascending, Descending } } APÉNDICE C Namespace System. Storage { public abstract class FindResult : lasyncObjectReader { public FindResult( ); // Desplaza FindResult a la siguiente posición en el resultado. public bool Read( ); public lAsyncResult BeginRead( AsyncCalIback callback, object state ); public bool EndRead( lAsyncResult asyncResult ); // El objeto actual, public object Current {get;} // Devuelve si FindResult contiene objetos o no. public bool HasResults {get;} // Devuelve si FindResult está cerrado o no. public bool IsClosed {get;} // Devuelve el tipo de elementos en este FindResult. public Type ObjectType {get;} // Cierra FindResult. public void CIose( ); void IDisposable.Dispose( ); // Devuelve un enumerador Returns sobre FindResult, inicia en la posición actual. // Avanza cualquier enumerador en FindResult avanza todos los enumeradores así como // el mismo FindResult. lEnumerator IEnumerable.GetEnumerator( ); public FindResultEnumerator GetEnumerator( ); } public abstract class FindResultEnumerator : lEnumerator, Idisposable { public abstract object Current { get; } public abstract bool MoveNext( ); public abstract void Reset( ); public abstract void Close( ); void I Disposable. Dispose( ); } } namespace System { // Una interfase común para reiterar sobre los objetos. public interface lObjectReader : lEnumerable, Idisposable { object Current {get;} bool IsClosed {get;} bool HasResults {get;} Type ObjectType {get;} bool Read( ); void Close( ); } // Agrega métodos asincronos a lobjectReader. public interface I AsyncObjectReader : lobjectReader { lAsyncResult BeginRead( AsyncCalIback callback, object state ); bool EndRead( lAsyncResult result ); } }

Claims

REIVINDICACIONES

1. Un Almacén de datos que comprende al menos uno de un artículo, un elemento y una relación, en donde: dicho artículo es una unidad de datos que se pueden almacenar en un almacén de datos y además comprende dicho elemento o dicha relación; dicho elemento es una instancia de un tipo que comprende uno o más campos; y dicha relación es un enlace entre al menos dos artículos.

2. El almacén de datos tal y como se describe en la reivindicación 1, caracterizado además por que comprende una pluralidad de artículos, dicha pluralidad de artículos comprenden una carpeta de artículos y al menos otro artículo que es un miembro de dicha carpeta de artículos.

3. El almacén de datos tal y como se describe en la reivindicación 1, caracterizado además por que comprende una pluralidad de artículos, dicha pluralidad de artículos comprende una categoría y al menos otro artículo que es un miembro de dicha categoría

4. El almacén de datos tal y como se describe en la reivindicación 1, caracterizado además por que una relación entre dos artículos se establece de manera automática a través de un sistema de interfase de componentes físicos de computación/programas y sistemas de programación.

5. El almacén de datos tal y como se describe en la reivindicación 4, caracterizado además por que dicho elemento es comprensible mediante un sistema de interfase de componentes físicos de computación/programas y sistemas de programación.

6. El almacén de datos tal y como se describe en la reivindicación 1, caracterizado además por que la relación comprende dicho segundo elemento.

7. El almacén de datos tal y como se describe en la reivindicación 1, caracterizado además por que comprende un esquema núcleo para definir un conjunto de artículos núcleo a través de los cuales un sistema de interfase de componentes físicos de computación/programas y sistemas de programación comprende y procesa de manera directa dicho conjunto de elementos núcleo de una manera predeterminada y predecible.

8. El almacén de datos tal y como se describe en la reivindicación 7, caracterizado además porque cada artículo del conjunto de artículos núcleo se deriva (directa o indirectamente) de un artículo base único común.

9. El almacén de datos tal y como se describe en la reivindicación 7, caracterizado además porque dicho artículo base único común es un artículo fundamental en un esquema base.

10. Un medio legible a través de una computadora con instrucciones legibles a través de una computadora para un almacén de datos que comprende al menos dos artículos, dichos artículos comprenden cada uno al menos un elemento y dichos artículos cada uno comparte una relación con al menos otro artículo.

11. El medio legible a través de una computadora tal y como se describe en la reivindicación 10, caracterizado además porque comprende: instrucciones para dicho almacén de datos para almacenar al menos uno de cada artículo, elemento y relación; instrucciones para dicho artículo que comprende además dicho elemento y dicha relación con dicho almacén de datos; instrucciones para dicho elemento para que comprenda un tipo de uno o más campos; e instrucciones para formar una relación entre dos artículos.

12. Un sistema de cómputo, dicho sistema de cómputo comprende: una pluralidad de elementos en donde cada elemento de entre dicha pluralidad de elementos constituye una instancia de un tipo que compré uno o más campos; una pluralidad de artículos en donde cada artículo de entre dicha pluralidad de artículos constituye una unidad de información que se puede almacenar discreta que puede ser manipulada a través de un sistema de interfases de componentes físicos de cómputo/programas y sistemas de programación y en donde cada artículo comprende al menos un elemento; una pluralidad de relaciones en donde cada relación forma en dicha pluralidad de relaciones un enlace entre al menos dos elementos; un almacén de datos dicho almacén de datos comprende dicha pluralidad de artículos, dicha pluralidad de elementos y dicha pluralidad de relaciones; una plataforma de almacenamiento para administrar dicho almacén de datos y para manipular dicha pluralidad de artículos.

13. El sistema de cómputo tal y como se describe en la reivindicación 12, caracterizado además porque cada artículo entre dicha pluralidad de artículos pertenece al menos a una carpeta de artículos entre una pluralidad de carpetas de artículos, y en donde dicho artículo puede pertenecer a más de una carpeta de artículos entre dicha pluralidad de carpetas de artículos.

14. El sistema de cómputo tal y como se describe en la reivindicación 13, caracterizado además porque la eliminación de dicha carpeta de artículos no ocasiona la eliminación automática de dicho artículo.

15. El sistema de cómputo tal y como se describe en la reivindicación 13, caracterizado además porque un artículo se elimina de manera automática cuando ya no pertenece a ninguna carpeta de artículos.

16. El sistema de cómputo tal y como se describe en la reivindicación 13, caracterizado además porque dicho artículo se elimina automáticamente cuando es miembro de sólo una carpeta de artículos y dicha carpeta de artículos se elimina.

17. El sistema de cómputo tal y como se describe en la reivindicación 13, caracterizado además porque un artículo es automáticamente un miembro de una carpeta de artículos predeterminada.

18. El sistema de cómputo tal y como se describe en la reivindicación 13, caracterizado además porque dicho artículo, cuando es miembro de sólo una carpeta de artículos y dicha carpeta de artículos se elimina, automáticamente se convierte en un miembro de una carpeta de artículos predeterminada.

19. Un método para organizar artículos en un almacén de datos, dichos artículos comprenden (a) una unidad discreta de información que se puede manipular a través de un sistema operativo, (b) al menos un artículo y (c) una relación con al menos otro artículo; dicho método comprende medios a través de los cuales un artículo puede ser un miembro de al menos dos carpetas de artículos, pero no es propiedad de ninguna de dichas carpetas de artículos, de manera que la eliminación de cualquiera de dichas carpetas de artículos no ocasiona la eliminación automática de dicho artículo.

20. El método tal y como se describe en la reivindicación 19, en donde el artículo es un miembro de una carpeta de artículos, pero no es propiedad de la carpeta de artículos, de manera que la eliminación de dicha carpeta de artículos no ocasiona la eliminación automática de dicho artículo.

21. El método tal y como se describe en la reivindicación 20, en donde el artículo se elimina automáticamente cuando ya no pertenece a ninguna carpeta de artículos.

22. El método tal y como se describe la reivindicación 20, en donde dicho artículo, cuando ya no pertenece a ninguna carpeta de artículos, automáticamente se convierte en un miembro de una carpeta de artículos predeterminada.

23. El método tal y como se describe la reivindicación 20, en donde el artículo se elimina de manera automática cuando es un miembro de sólo una carpeta de artículos y dicha carpeta de artículo se elimina.

24. El método tal y como se describe la reivindicación 20, en donde dicho artículo, cuando es un miembro de sólo una carpeta de artículos y dicha carpeta de artículos se elimina, automáticamente se convierte en un miembro de una carpeta de artículos predeterminada.

25. Un sistema de cómputo que comprende: una pluralidad de artículos que comprenden al menos un artículo, en donde dicha pluralidad de artículos constituye una unidad de información discreta que se puede almacenar y que se puede manipular a través de un sistema de interfase de componentes físicos de computación/sistemas y programas de programación; una pluralidad de carpetas de artículos que comprende al menos una carpeta de artículos, en donde dicha pluralidad de carpetas de artículos constituye una estructura organizacional para dichos artículos; y un sistema de interfase de componentes físicos de computación/sistemas y programas de programación para manipular dicha pluralidad de artículos, en donde dicha pluralidad de artículos pertenece al menos a una de dicha pluralidad de carpetas de artículos, y en donde dicha pluralidad de artículos puede pertenecer a más de una carpeta de artículos de dicha pluralidad de carpetas de artículos.

26. El sistema de cómputo tal y como se describe en la reivindicación 25, caracterizado además porque un artículo es un miembro de una carpeta de artículos, pero no es propiedad de dicha carpeta de artículos, de manera que la eliminación de dicha carpeta de artículos no ocasiona la eliminación automática de dicho artículo.

27. El sistema de cómputo tal y como se describe en la reivindicación 25, caracterizado además porque un artículo se elimina de manera automática cuando ya no pertenece a ninguna carpeta de artículos.

28. El sistema de cómputo tal y como se describe en la reivindicación 25, caracterizado además porque dicho artículo se elimina de manera automática cuando es miembro de sólo una carpeta de artículos y dicha carpeta de artículos se elimina.

29. El sistema de cómputo tal y como se describe en la reivindicación 25, caracterizado además porque cada artículo es un miembro de al menos una carpeta de artículos, pero no es propiedad de dicha carpeta de artículos, de manera que la eliminación de dicha carpeta de artículos no ocasiona la eliminación automática de un artículo.

30. El sistema de cómputo tal y como se describe en la reivindicación 25, caracterizado además porque comprende una pluralidad de categorías que comprende al menos una categoría, en donde dicha pluralidad de categorías constituye una estructura organizacional para dichos artículos.

31. El sistema de cómputo tal y como se describe en la reivindicación 30, caracterizado además porque una categoría se define a través de una propiedad de artículo.

32. El sistema de cómputo tal y como se describe en la reivindicación 31, caracterizado además porque una de dicha pluralidad de categorías se define a través de una propiedad de artículo, y sólo un artículo que comprende la propiedad de artículo para una categoría específica entre dicha pluralidad de categorías puede ser un miembro de dicha categoría específica.

33. El sistema de cómputo tal y como se describe en la reivindicación 30, caracterizado además porque cada una de dicha pluralidad de categorías se define a través de una propiedad de artículo.

34. El sistema de cómputo tal y como se describe en la reivindicación 33, caracterizado además porque cada una de dicha pluralidad de categorías se define a través de una propiedad de artículo y sólo los artículos que comprenden la propiedad de artículo para una categoría específica entre dicha pluralidad de categorías puede ser miembro de dicha categoría específica.

35. Un sistema de interfases de componentes físicos de computación/programas y sistemas de programación que es capaz de. manipular un artículo, dicho artículo comprende una unidad de información discreta que comprende un conjunto básico de propiedades que se soportan comúnmente entre los objetos expuestos a través de una cubierta del sistema operativo.

36. El sistema de interfases de componentes físicos de computación/programas y sistemas de programación tal y como se describe en la reivindicación 35, caracterizado además porque dicho artículo es una unidad fundamental de información manipulada a través del sistema operativo.

37. El sistema de interfases de componentes físicos de computación/programas y sistemas de programación tal y como se describe en la reivindicación 36, caracterizado además porque dicho artículo es un miembro de una carpeta de artículos.

38. El sistema de interfases de componentes físicos de computación/programas y sistemas de programación tal y como se describe en la reivindicación 37, caracterizado además porque dicho artículo no es propiedad de dicha carpeta de artículos, de manera que la eliminación de dicha carpeta de artículos no ocasiona la eliminación automática de dicho artículo.

39. El sistema de interfases de componentes físicos de computación/programas y sistemas de programación tal y como se describe en la reivindicación 38, caracterizado además porque dicho artículo se elimina automáticamente cuando no pertenece a ninguna carpeta de artículos.

40. El sistema de interfases de componentes físicos de computación/programas y sistemas de programación tal y como se describe en la reivindicación 38, caracterizado además porque dicho artículo se elimina de manera automática cuando es miembro de sólo una carpeta de artículos, y dicha carpeta de artículos se elimina.

41. Un medio legible a través de una computadora que comprende instrucciones legibles a través de una computadora para un artículo, dicho artículo comprende una unidad discreta de información que se puede manipular a través de un sistema de interfases de componentes físicos de computación/programas y sistemas de programación.

42. Un medio legible a través de una computadora que comprende instrucciones legibles a través de una computadora para un sistema de interfases de componentes físicos de computación/programas y sistemas de programación, dicho sistema operativo comprende: medios para manipular una pluralidad de artículos que comprende al menos un artículo, en donde cada uno de dicha pluralidad de artículos constituye una unidad discreta de información que se puede manipular a través de un sistema de interfases de componentes físicos de computación/programas y sistemas de programación; medios para manipular una pluralidad de carpetas de artículos que comprende al menos una carpeta de artículos, en donde dicha pluralidad de carpetas de artículos constituye una estructura organizacional para dichos artículos; y en donde cada uno de la pluralidad de artículos pertenece al menos a una de dicha pluralidad de carpetas de artículos, y en donde cada uno de dicha pluralidad de artículos puede pertenecer a más de una carpeta de artículos de dicha pluralidad de carpetas de artículos.

43. Un medio legible a través de una computadora con instrucciones legibles a través de una computadora para un sistema de interfases de componentes físicos de computación/programas y sistemas de programación para un sistema de cómputo, en donde dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación manipula una pluralidad de unidades discretas de información ("artículos"), dichos artículos están interconectados a través de una pluralidad de relaciones gestionadas a través de dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación.

44. El medio legible a través de una computadora tal y como se describe en la reivindicación 43, caracterizado además porque un primer artículo tiene una relación para sí mismo con un segundo artículo.

45. El medio legible a través de una computadora tal y como se describe en la reivindicación 44, caracterizado además porque dicho primer artículo es una carpeta de artículos.

46. El medio legible a través de una computadora tal y como se describe en la reivindicación 45, caracterizado además porque dicho segundo artículo es una carpeta de artículos.

47. El medio legible a través de una computadora tal y como se describe en la reivindicación 45, caracterizado además porque dicho segundo artículo es una categoría.

48. El medio legible a través de una computadora tal y como se describe en la reivindicación 45, caracterizado además porque dicho segundo artículo es un artículo que no es una carpeta de artículos ni una categoría.

49. El medio legible a través de una computadora tal y como se describe en la reivindicación 45, caracterizado además porque cada artículo entre dichos artículos tiene una relación con al menos otro artículo.

50. El medio legible a través de una computadora tal y como se describe en la reivindicación 45, caracterizado además porque un subconjunto de artículos comprende carpetas de artículos.

51. El medio legible a través de una computadora tal y como se describe en la reivindicación 45, caracterizado además porque un subconjunto de artículos comprende categorías.

52. El medio legible a través de una computadora tal y como se describe en la reivindicación 45, caracterizado además porque un subconjunto de artículos comprende artículos que no son carpetas de artículos ni categorías.

53. Un medio legible a través de una computadora con instrucciones legibles a través de una computadora para un sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación para un sistema de cómputo, caracterizado además porque dicho sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación manipula una pluralidad de unidades discretas de información que tiene propiedades comprensibles a través de dicho sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación ("artículos").

54. El medio legible a través de una computadora tal y como se describe en la reivindicación 53, caracterizado además porque dicho sistema de ¡nterfases de componentes físicos de computación/programas y sistemas de programación comprende un esquema base para definir al menos uno de un artículo y al menos una de una propiedad.

55. El medio legible a través de una computadora tal y como se describe en la reivindicación 54, caracterizado además porque al menos uno de un artículo en el esquema base es un artículo fundamental, que constituye un tipo de elemento fundamental, desde el cual los demás artículos manipulados en el sistema de interfases de componentes físicos de computación/programas y sistemas de programación se derivan.

56. El medio legible a través de una computadora tal y como se describe en la reivindicación 55, caracterizado además porque dicho tipo de artículo fundamental comprende una propiedad para hacer referencia al menos hacerlo categorías de las cuales dicho artículo es un miembro.

57. El medio legible a través de una computadora tal y como se describe en la reivindicación 55, caracterizado además porque dicho tipo de artículo fundamental comprende una propiedad para una identificación única de dicho artículo en un sistema de interfases de componentes físicos de computación/programas y sistemas de programación.

58. El medio legible a través de una computadora tal y como se describe en la reivindicación 54, caracterizado además porque ai menos uno de una propiedad en el esquema base es una propiedad fundamental, que constituye un tipo de propiedad fundamental, de la cual todas las otras propiedades que se utilizan el sistema de interfases de componentes físicos de computación/programas y sistemas de programación se derivan.

59. El medio legible a través de una computadora tal y como se describe en la reivindicación 54, caracterizado además porque: al menos uno de un artículo es el esquema base de un artículo fundamental, que constituye un tipo de elemento fundamental, del cual todos los otros artículos manipulados en el sistema de interfases de componentes físicos de computación/programas y sistemas de programación se derivan; y al menos uno de una propiedad en el esquema base es una propiedad fundamental que constituye un tipo de propiedad fundamental, desde el cual todas las otras propiedades utilizadas en el sistema de interfases de componentes físicos de computación/programas y sistemas de programación se derivan.

60. El medio legible a través de una computadora tal y como se describe en la reivindicación 59, caracterizado además porque el esquema base adicionalmente comprende un segundo artículo derivado del tipo de artículos fundamentales (primer artículo), dicho segundo artículo constituye el tipo fundamental para una carpeta de artículos y dicho segundo artículo expresa una relación para dicho primer artículo.

61. El medio legible a través de una computadora tal y como se describe en la reivindicación 59, caracterizado además porque el esquema base comprende adicionalmente una segunda propiedad derivada del tipo de propiedad fundamental (primera propiedad), dicha segunda propiedad constituye el tipo fundamental para una propiedad clave de identificador de unidad.

62. El medio legible a través de una computadora tal y como se describe en la reivindicación 59, caracterizado además porque el esquema base comprende adicionalmente una tercera propiedad derivada de dicha segunda propiedad, dicha^ tercera propiedad constituye el tipo fundamental para una referencia de categoría.

63. El medio legible a través de una computadora tal y como se describe en la reivindicación 59, caracterizado además porque el esquema base comprende adicionalmente una segunda propiedad derivada del tipo de propiedad fundamental (primera propiedad), dicha segunda propiedad constituye el tipo fundamental para las categorías.

64. Un medio legible a través de una computadora con instrucciones legibles a través de una computadora para un sistema de interfases de componentes físicos de computación/programas y sistemas de programación para un sistema de cómputo, en donde dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación manipula una pluralidad de unidades discretas de información que tiene propiedades comprensibles a través de un sistema de interfases de componentes físicos de computación/programas y sistemas de programación ("artículos").

65. El medio legible a través de una computadora tal y como se describe en la reivindicación 64, caracterizado además porque dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación comprende un esquema núcleo para definir un conjunto de artículos núcleo, los que dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación comprende y puede procesar de manera directa de una manera predeterminada y predecible.

66. El medio legible a través de una computadora tal y como se describe en la reivindicación 65, caracterizado además porque cada artículo del conjunto de artículos núcleo se deriva (directa o indirectamente) de un artículo base único común.

67. El medio legible a través de una computadora tal y como se describe en la reivindicación 66, caracterizado además porque dicho artículo base único común es un artículo fundamental en un esquema base.

68. El medio legible a través de una computadora tal y como se describe en la reivindicación 67, caracterizado además porque dicho esquema núcleo además define un conjunto de propiedades núcleo, las cuales comprende dicho sistema de interfases de componentes físicos de computación/programas y sistemas de programación y puede procesar de manera directa en una manera predeterminada y predecible.

69. El medio legible a través de una computadora tal y como se describe en la reivindicación 68, caracterizado además porque cada propiedad del conjunto de artículos núcleo se deriva (directa o indirectamente) de al menos una propiedad base.

70. El medio legible a través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende un artículo para los dispositivos.

71. El medio legible a través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende un artículo para los eventos.

72. El medio legible a través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende un artículo para productos.

73. El medio legible a través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende un artículo para mensajes.

74. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende un artículo para elementos principales.

75. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende un artículo para ubicaciones.

76. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende un artículo para documentos.

77. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende un artículo para afirmaciones.

78. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende un artículo para contactos.

79. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende una propiedad para un certificado.

80. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende una propiedad para una clave de identidad de unidad principal.

81. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende una propiedad para una dirección postal.

82. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende una propiedad para un elemento de texto enriquecido.

83. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende una propiedad para una dirección electrónica.

84. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende una propiedad para un paquete de seguridad de identidad de unidad.

85. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende una relación para ocupar un rol entre dos contactos.

86. El medio legible través de una computadora tal y como se describe en la reivindicación 69, caracterizado además porque el esquema núcleo comprende una propiedad para una presencia básica.

87. Un método para manipular una pluralidad de unidades discretas de información ("artículos") en un sistema de interfases de componentes físicos de computación/programas y sistemas de programación para un sistema de cómputo, dicho método comprende la interconexión de dichos artículos con una pluralidad de relaciones y administrar dichas relaciones en el nivel del sistema de interfases de componentes físicos de computación/programas y sistemas de programación.

88. El sistema de interfases tal y como se describe en la reivindicación 87, caracterizado además porque cada relación entre dicha pluralidad de relaciones constituye, en el nivel del sistema de interfases de componentes físicos de computación/programas y sistemas de programación, una correlación entre un par de artículos que dicha relación interconecta.

89. El sistema de interfases tal y como se describe en la reivindicación 88, caracterizado además porque cada relación tiene propiedades.

90. El sistema de interfases tal y como se describe en la reivindicación 89, caracterizado además porque cada relación comprende una propiedad (objetivo) para la identificación de dicho artículo objetivo de la relación.

91. El sistema de interfases tal y como se describe en la reivindicación 90, caracterizado además porque cada relación comprende adicionalmente una propiedad (es propiedad de) para la propiedad de dicho artículo objetivo de la relación.