MXPA05007092A

MXPA05007092A - Sistemas y metodos para proporcionar servicio de sincronizacion para unidades de informacion manejables a traves de un sistema de interfase de hardware/software.

Info

Publication number: MXPA05007092A
Application number: MXPA05007092A
Authority: MX
Inventors: B Taylor Michael
Original assignee: Microsoft Corp
Priority date: 2003-08-21
Filing date: 2004-07-29
Publication date: 2005-09-12
Also published as: EP1581894A1; CA2512185C; EP1581894A4; JP4583376B2; WO2005024665A1; JP2007503050A; AU2004271525A1; BRPI0406612A; AU2004271525B2; CA2512185A1

Abstract

Varias modalidades de la presente invencion emplean adaptadores de sincronizacion para sincronizar informacion entre fuentes de datos "WinFS" y no "Win-FS" (Figura 36, 3622/3666). Ejemplos de adaptadores incluyen un adaptador que sincroniza informacion de libreta de direcciones entre una carpeta de contactos "WinFS" y un correo de no "WinFS" (Figura 36, 3642). En estos casos los desarrolladores de adaptadores puede usar la API de servicios de nucleo de sincronizacion "WinFS" descrita aqui para tener acceso a servicios provistos por la plataforma de sincronizacion de "WinFS" (Figura 36, 3612) con el fin de desarrollar un codigo de transformacion de esquema entre el esquema "WinFS" (Figura 36, 3612) y el esquema de fuente de datos de no "WinFS" (Figura 36, 3624). Ademas, el desarrollador de adaptador proporciona un soporte de protocolo para comunicar los cambios con la fuente de datos "WinFS". Un adaptador de sincronizacion (Figura 36, 3662) es invocado y controlado utilizando la API de controlador de sincronizacion y reporta el progreso y errores utilizando esta API (Figura 36, 3642).

Description

SISTEMAS Y MÉTODOS PARA PROPORCIONAR SERVICIO DE SINCRONIZACIÓN PARA UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFASES DE HARDWARE/SOFTWARE REFERENCIA CRUZADA La presente solicitud reclama la prioridad sobre la Solicitud de Patente Norteamericana No. 10/692,515 (Expediente Legal No. MSFT-2844), presentada en Octubre 24, 2004, titulada "SISTEMAS Y MÉTODOS PARA PROPORCIONAR SERVICIOS DE SINCRONIZACIÓN PARA UNIDADES DE INFORMACIÓN MANEJABLES POR UN SISTEMA DE INTERFASE DE HARDWARE/SOFTWARE"; Solicitud de Patente Norteamericana No. 10/646,575 (Expediente Legal No. MSFT-2733), presentada en Agosto 21, 2003, titulada "SISTEMAS Y MÉTODOS PARA HACER INTERFASE DE PROGRAMAS DE APLICACIÓN CON UNA PLATAFORMA DE ALMACENAMIENTO BASADA EN LAS PARTIDAS"; y la Solicitud Internacional No. PCT/US03/26150 (Expediente Legal No. 2777), presentada en Agosto 21, 2003, titulada "SISTEMAS Y MÉTODOS PARA HACER INTERFASE DE PROGRAMAS DE APLICACIÓN CON UNA PLATAFORMA DE ALMACENAMIENTO BASADA EN PARTIDAS"; cuyas descripciones están incorporadas en su totalidad a la presente descripción como referencia.

Esta solicitud está relacionada por el asunto materia de las invenciones descritas en las siguientes solicitudes generalmente asignadas, cuyos contenidos están incorporados en su totalidad en la presente solicitud (y resumidos parcialmente en la presente solicitud por razones de conveniencia): la Solicitud de Patente Norteamericana No. 10/647,058 (Expediente Legal No. MSFT-1748), presentada en Agosto 21, 2003, titulada "SISTEMAS Y MÉTODOS PARA REPRESENTAR UNIDADES DE INFORMACIÓN MANEJABLES POR UN SISTEMA DE INTERFASE DE HARDWARE/SOFTWARE PERO INDEPENDIENTES DE LA REPRESENTACIÓN FÍSICA"; la Solicitud de Patente Norteamericana No. 10/646,941 (Expediente Legal No. MSFT-1749), presentada en Agosto 21, 2003, titulada "SISTEMAS Y MÉTODOS PARA SEPARAR UNIDADES DE INFORMACIÓN MANEJABLES POR UN SISTEMA DE INTERFASE DE HARDWARE/SOFTWARE DESDE SU ORGANIZACIÓN FÍSICA"; la Solicitud de Patente Norteamericana No. 10/646,940 (Expediente Legal No. MSFT-1750), presentada en Agosto 21, 2003, titulada "SISTEMAS Y MÉTODOS PARA LA IMPLEMENATACIÓN DE UN ESQUEMA BÁSICO PARA UNIDADES DE ORGANIZACIÓN DE INFORMACIÓN MANEJABLE POR UN SISTEMA DE INTERFASE DE HARDWARE/SOFTWARE; la Solicitud de Patente Norteamericana No. 10/646,632 (Expediente Legal No. MSFT- 1751), presentada en Agosto 21, 2003, titulada "SISTEMAS Y MÉTODOS PARA LA IMPLEMANTACIÓN DE UN ESQUEMA NÚCLEO PARA PROPORCIONAR UNA ESTRUCTURA DE ALTO NIVEL PARA UNIDADES DE ORGANIZACIÓN DE INFORMACIÓN MANEJABLE POR UN SISTEMA DE INTERFASE DE HARDWARE/SOFTWARE"; la Solicitud de Patente Norteamericana No. 10/646,645 (Expediente Legal No. MSFT-1752), presentada en Agosto 21, 2003, titulada "SISTEMAS Y MÉTODO PARA REPRESENTAR LAS RELACIONES ENTRE UNIDADES DE INFORMACIÓN MANEJABLES POR UN SISTEMA DE INTERFASE DE HARDWARE/SOFTWARE"; la Solicitud de Patente Norteamericana No. 10/646,646 (Expediente Legal No. MSFT-2734), presentada en Agosto 21, 2003, titulada "PLATAFORMA DE ALMACENAMIENTO PARA LA ORGANIZACIÓN, BÚSQUEDA Y PARTICIPACIÓN DE DATOS"; la Solicitud Patente Norteamericana No. 10/646,580 (Expediente Legal No. MSFT-2735), presentada en Agosto 21, 2003, titulada "SISTEMAS Y MÉTODOS PARA EL DISEÑO DE DATOS EN UNA PLATAFORMA DE ALMACENAMIENTO BASADA EN LAS PARTIDAS"; Solicitud de Patente Norteamericana No. 10/692,779 (Expediente Legal No. MSFT-2829), presentada en Octubre 24, 2003, titulada "SISTEMAS Y MÉTODOS PARA LA IMPLEMANTACIÓN DE UN ESQUEMA DE IMÁGENES DIGITALES PARA UNIDADES DE ORGANIZACIÓN DE INFORMACIÓN MANEJABLE POR UN SISTEMA DE I TERFASE DE HARDWARE/SOFTWARE"; la Solicitud de Patente Norteamericana No. 10/692,508 (Expediente Legal No. MSFT-2845), presentada en Octubre 24, 2003, titulada "SISTEMAS Y MÉTODOS PARA PROPORCIONAR SERVICIOS DE SINCRONIZACIÓN DE RELACIÓN Y JERÁRQUICA PARA UNIDADES DE INFORMACIÓN MANEJABLES POR UN SISTEMA DE I NTERFASE DE HARDWARE/SOFTWARE"; la Solicitud de Patente Norteamericana No. 10/693,362 (Expediente Legal No. MSFT-2846), presentada en Octubre 24, 2003, titulada "SISTEMAS Y MÉTODOS PARA LA IMPLEMENTACION DE UN ESQUEMA DE ORGANIZACIÓN PARA UNIDADES DE INFORMACIÓN MANEJABLES POR UN SISTEMA DE INTERFASE DE HARDWARE/SOFTWARE"; y la Solicitud de Patente Norteamericana No. 10/693,574 (Expediente Legal No. MSFT-2847), presentada en Octubre 24, 2003, titulada "SISTEMAS Y MÉTODOS PARA LAS EXTENSIONES Y HERENCIA PARA UNIDADES DE INFORMACIÓN MANEJABLES POR UN SISTEMA DE INTERFASE DE HARDWARE/SOFTWARE". Campo de la Invención La presente invención se refiere generalmente al campo de almacenamiento y recuperación de información, y más particularmente, a una plataforma activa de almacenamiento para organizar, buscar y compartir diferentes tipos de datos en un sistema computarizado. Antecedentes de la Invención La capacidad individual de los discos ha ido creciendo en aproximadamente un setenta por ciento (70%) por año durante la última década. La ley de Moore pronosticó de manera exacta, las ganancias tremendas en la potencia de la unidad de procesamiento central (CPU) que ha ocurrido con el paso de los años. Las tecnologías cableadas e inalámbricas han proporcionado una capacidad de conexión y ancho de banda tremenda. Presumiendo que las tendencias actuales continúen, dentro de varios años, las computadoras portátiles promedio poseerán aproximadamente un terabyte (TB) de almacenamiento y contendrán millones de archivos y unidades de 500 gigabytes (GB) se convertirán en un lugar común. Los consumidores utilizan generalmente sus computadoras para la comunicación y organización de la información personal, ya sea en datos de un estilo de administración de información personal tradicional (PIM), o medios tales como música o fotografías digitales. La cantidad del contenido digital y la capacidad para almacenar los bytes simples, ha aumentado de una manera tremenda; sin embargo, los métodos disponibles para los consumidores para organizar y unificar estos datos se han mantenido tranquilos. Los trabajadores del conocimiento pasan enormes cantidades de su tiempo administrando y compartiendo información y algunos estudios estiman que los trabajadores del conocimiento pasan del 15% al 25% de su tiempo en actividades relacionadas con información no productiva. Otros estudios estiman que un trabajador de conocimiento típico gasta aproximadamente 2.5 horas diarias buscando la información. Los departamentos de desabolladores y tecnología de información (IT), invierten cantidades importantes de tiempo y dinero en construir sus propios almacenes de datos para las abstracciones de almacenamiento común para que representen cosas tales como gentes, lugares, tiempos y eventos. Esto no solamente resulta en un trabajo de duplicado, sino que también crea islas de datos comunes sin mecanismos para la búsqueda o participación común de esos datos. Solamente si se considera cuantos libros de direcciones pueden existir hoy en una computadora que ejecuta en un sistema operativo Windows Microsoft. Muchas aplicaciones, tales como los clientes del correo electrónico y los programas financieros personales, guardan archivos de direcciones individuales y no existe mucha participación entre las aplicaciones de los datos libres de direcciones que mantienen individualmente dichos programas. Por consiguiente, un programa financiero (como Microsoft Money), no comparte las direcciones para los deudores con las direcciones mantenidas en una carpeta de contactos de correo electrónico (como la de Microsoft Outlook). Indudablemente, muchos usuarios tienen aparatos múltiples y deben de sincronizar de manera lógica sus datos personales entre ellos mismos, y por una amplia variedad de fuentes adicionales, incluyendo teléfonos celulares para los servicios comerciales, tales como MSN y AOL; sin embargo, la colaboración de los documentos compartidos se logra en gran parte adjuntando documentos a los mensajes de correo electrónico - es decir, de una manera manual e ineficiente. Una razón para esta carencia de colaboración, es que los métodos tradicionales para la organización de la información de los sistemas de cómputo se han centrado en el uso de sistemas basados en directorios y carpetas de archivos ("sistemas de archivo") para organizar pluralidades de archivos en jerarquías de carpetas de directorios basados en una abstracción de la organización física del medio de almacenamiento utilizado para almacenar los archivos. El sistema operativo Multics, desarrollado durante los años 1960, puede ser acreditado como pionero del uso de los archivos, carpetas y directorios para manejar unidades de datos que se pueden almacenar en el nivel del sistema operativo. Específicamente, el sistema Multics utilizado para direcciones simbólicas dentro de una jerarquía de archivos (introduciendo de este modo la ¡dea de una trayectoria de archivo), en donde las direcciones físicas de los archivos no fueron transparentes para el usuario (aplicaciones y usuarios finales). Este sistema de archivo no se preocupó en lo absoluto por el formato del archivo de un archivo individual y las relaciones entre los archivos se consideró irrelevante en el nivel del sistema operativo (es decir, a diferencia de la localización de los archivos dentro de la jerarquía). Desde la llegada del sistema Multics, los datos de almacenamiento han sido organizados en archivos, carpetas y directorios en el nivel del sistema operativo. Estos archivos generalmente incluyen la jerarquía de archivo misma (el "directorio"), incorporada en un archivo especial mantenido por el sistema de archivos. Este directorio, a la vez, mantiene una lista de entradas correspondientes a todos los otros archivos del directorio y la localización de los nodos de dichos archivos en la jerarquía (a los que nos referimos en la presente solicitud como las carpetas). Tal ha sido la condición de la técnica por aproximadamente cuarenta años. Sin embargo, aunque se proporciona una representación razonable de la información que reside en el sistema de almacenamiento físico de la computadora, un sistema de archivo es, no obstante, una abstracción de ese sistema de almacenamiento físico y por lo tanto, la utilización de los archivos requiere un nivel de falta de dirección (interpretación) entre lo que el usuario manipula (unidades que tienen contexto, características y relaciones con otras unidades) y lo que proporciona el sistema operativo (archivos, carpetas y directorios). Por consiguiente, los usuarios (aplicaciones y/o usuarios finales) no tienen elección, sino forzar unidades de información dentro de la estructura de archivos aún cuando hacerlo resulta ineficiente, inconsistente o no deseable de otro modo. Además, los sistemas de archivos existentes saben poco acerca de la estructura de datos almacenada en los archivos individuales y debido a esto, la mayor parte de la información permanece cerrada a los archivos en los que solamente se puede tener acceso (y son extensibles) a las aplicaciones que los escribieron. Por consiguiente, esta carencia de una descripción esquemática de la información y los mecanismos para manejar la información, conducen a la creación de silos de datos con poca participación de datos entre los silos individuales. Por ejemplo, muchos usuarios de computadoras personales (PC), tienen más de cinco almacenes diferentes que contienen información acerca de la gente con la que interactúan en algún nivel - por ejemplo, los Contactos de Outlook, las direcciones de cuentas en línea, el Windows Address Book, Quicken Payees, y las listas grandiosas de envío de mensajes instantáneos (IM) - debido a que la organización de los archivos presenta un reto importante para estos usuarios de la PC. Porque la mayor parte de los sistemas de archivo existentes utilizan la metáfora de la carpeta anidada para organizar archivos y carpetas, conforme el número de archivos aumenta, el esfuerzo necesario para mantener un esquema de organización que sea flexible y eficiente se vuelve cada vez más abrumador. En dichas situaciones, sería muy útil tener clasificaciones múltiples en un solo archivo; sin embargo, utilizar enlaces permanentes o temporales en los sistemas existentes de archivos es un poco problemático y difícil de mantener. Se han hecho intentos no exitosos en el pasado para resolver las desventajas de los sistemas de archivo. Algunos de estos intentos previos han comprendido el uso de una memoria que se puede dirigir al contenido para proporcionar un mecanismo por medio del cual se pudiera tener acceso a los datos por medio del contenido, en vez de por la dirección física. Sin embargo, estos esfuerzos han aprobado no ser exitosos debido a que, mientras la memoria que se puede dirigir al contenido ha probado ser útil para el uso de escala pequeña por los aparatos tales como memorias instantáneas y unidades de administración de memoria, el uso en gran escala para los aparatos, tales como los medios de almacenamiento físico todavía no ha sido posible por una variedad de razones y por lo tanto, dicha solución simplemente no existe. Se han hecho otros intentos que utilizan sistemas de bases de datos orientadas al objeto (OODB), pero estos intentos, aunque caracterizan características fuertes de bases de datos y buenas representaciones que no son de archivo, no fueron efectivas para manejar las representaciones de archivo, y no podrían duplicar la velocidad, eficiencia y simplicidad del archivo y la carpeta basados en la estructura jerárquica en el nivel del sistema de interfase de hardware/software. Otros esfuerzos, tales como aquellos que han intentado utilizar SmallTalk (y otros derivados), probaron ser bastante efectivos para el manejo de archivos y las representaciones que no son de archivo, pero carecían de las características de la base de datos necesarias para utilizar de manera eficiente las relaciones que existen entre los diferentes archivos de datos, y de este modo, la eficiencia general de dichos sistemas fue inaceptable. Todavía otros intentos para utilizar el BeOS (y otras búsquedas del sistema operativo) probaron ser inadecuadas en el manejo de representaciones que no son de archivo - la misma desventaja central de los sistemas de archivo tradicionales - a pesar de poder representar de manera adecuada los archivos mientras que se proporcionan algunas características necesarias de la bases de datos. La tecnología de la base de datos en otra área en la técnica en la cual existen retos similares. Por ejemplo, aunque el modelo tradicional de la base de datos ha sido un gran éxito comercial, en una independencia real de los proveedores del software (ISV) generalmente ejercitan una porción pequeña de la funcionalidad disponible en los productos de programa de base de datos de relación (tales como, Microsoft SQL Server). En vez de ello, la mayor parte de la interacción de la aplicación de dicho producto es en la forma de un "obtener" y "pegar" simple. Aunque existe un número de razones fácilmente aparentes para esto - tales como estar en plataformas o agnósticos de las bases de datos - una razón clave que generalmente no se nota, es que la base de datos no proporciona necesariamente las abstracciones exactas que realmente necesita un vendedor de una aplicación comercial mayor. Por ejemplo, aunque el mundo real tiene la noción de "partida", tales como "cliente" o "pedido" (junto con un pedido incrustado "partidas de líneas" como partidas y de ellos mismos), las bases de datos de relación solamente hablan en término de tablas y filas. Por consiguiente, aunque la aplicación puede desear tener aspectos de consistencia, cierre, seguridad y/o detonadores al nivel de partidas (para nombrar unos cuantos), la base de datos generalmente proporciona esas características solamente en un nivel de tabla/fila. Aunque esto puede funcionar bien si cada partida llega a mapear a una sola fila en alguna tabla en la base de datos, en el caso de un pedido con partidas de líneas múltiples pueden existir razones por las cuales una partida generalmente llega a formar un mapa para las tablas múltiples y, cuando es el caso, el sistema de base de datos de relación simple no proporciona bien las abstracciones correctas. Por consiguiente, una aplicación debe de construir la lógica en el encabezado de la base de datos para proporcionar estas abstracciones básicas. En otras palabras, el modelo de relación básico no proporciona una plataforma suficiente para el almacenamiento de datos en la cual se puedan desarrollar fácilmente aplicaciones de nivel más alto, debido a que el modelo de relación básico requiere un nivel de falta de dirección entre la aplicación y el sistema de almacenamiento - en donde la estructura semántica de los datos podría solamente ser visible en la aplicación en algunos objetos específicos. Aunque algunos vendedores de bases de datos están construyendo una funcionalidad de nivel más alto en sus productos - tales como proporcionar capacidades de relación del objeto, nuevos modelos de organización, y similares - ninguno ha proporcionado todavía el tipo de solución extensa necesaria, en donde una solución completamente extensa es una, la cual proporciona tanto las abstracciones del modelo de datos útiles (tales como "Partida", "Extensiones", "Relaciones" y así sucesivamente), para las abstracciones de un campo útil (tales como "Personas", Ubicaciones", "Eventos", etc.). En vista de las deficiencias anteriores en las tecnologías de base de datos y almacenamientos de base de datos existentes, existe la necesidad de una nueva plataforma de almacenamiento que proporcione una capacidad mejorada para organizar, buscar y compartir todos los tipos de datos en un sistema de cómputo -- una plataforma de almacenamiento que se extienda y amplíe la plataforma de datos más allá de los sistemas de archivo existentes y los sistemas de bases de datos, y que esté diseñada para que sea el almacén de todos los tipos de datos. La presente invención, junto con las invenciones relacionadas incorporadas anteriormente como referencia, satisfacen esta necesidad. Sumario de la Invención El siguiente sumario proporciona una vista general de varios aspectos de la invención descritos en el contexto de las invenciones relacionadas incorporadas como referencia anteriormente (las "invenciones relacionadas"). Este sumario no pretende proporcionar una descripción exhaustiva de todos los aspectos importantes de la presente invención, ni definir el alcance de la invención. En vez de ello, este sumario pretende servir como una introducción para la descripción detallada y las figuras siguientes. La presente invención, así como las invenciones relacionadas, se refieren colectivamente 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 del almacenamiento de datos más allá de los sistemas de archivo y los sistemas de base de datos existentes, y está diseñada para que sea el almacén de todos los tipos de datos incluyendo, datos estructurados, sin estructurar, o semi-estructurados. La plataforma de almacenamiento de la presente invención comprende un almacén de datos implementado en una máquina de base de datos. La máquina de base de datos comprende una máquina de base de datos de relación con extensiones de relación de objetos. El almacén de datos implementa un modelo de datos que soporta la organización, búsqueda, participación, sincronización y seguridad de los datos. Los tipos específicos de datos se describen en esquemas y la plataforma proporciona un mecanismo para extender el conjunto de esquemas para definir nuevos tipos de datos (esencialmente subtipos de los tipos básicos proporcionados por el esquema). Una capacidad de sincronización facilita la participación de datos entre usuarios o sistemas. Se proporcionan capacidades similares de los sistemas de archivo, de modo que permiten la interoperabilidad de los almacenes de datos con los sistemas de archivo existentes pero sin la limitación de dichos sistemas de archivo tradicionales. Un mecanismo de rastreo de cambios proporciona la capacidad de rastrear los cambios para el almacén de datos. La plataforma de almacenamiento comprende además un conjunto de interfases de programa de aplicación que hace posible que las aplicaciones accedan a todas las capacidades anteriores de la plataforma de almacenamiento y que accedan a los datos descritos en los esquemas. El modelo de datos implementado por el almacén de datos define unidades de almacenamiento de datos en términos de partidas, elementos y relaciones. Una partida es una unidad de datos que se puede almacenar en un almacén de datos y puede comprender uno o más elementos y relaciones. Un elemento es un ejemplo de un tipo que comprende uno o más campos (al que nos referimos también en esta descripción como una propiedad). Una relación es un enlace entre dos partidas. (Como se usa en la presente descripción, estos y otros términos específicos se pueden escribir con mayúscula con el objeto de diferenciarlos de otros términos utilizados en una proximidad cercana; sin embargo, no existe la intención en absoluto de distinguir entre una partida escrita en mayúsculas, por ejemplo "Partida", y el mismo término cuando no está escrito con mayúscula, es decir, "partida", y no se debe ser presumida o implicada dicha distinción). El sistema de cómputo comprende además una pluralidad de Partidas en donde cada Partida constituye una unidad de información separada que se puede almacenar que puede ser manipulada por un sistema de interfase de hardware/software; una pluralidad de Carpetas de Partidas, que constituyen una estructura de la organización de dichas Partidas y un sistema de interfase de hardware/software para manipular una pluralidad de Partidas y en donde cada Partida pertenece por lo menos a una Carpeta de Partidas y puede pertenecer a más de una Carpeta de Partidas. Una Partida en algunos de los valores de propiedad de las Partidas puede ser computada dinámicamente, opuesto a ser derivadas de un almacén persistente. En otras palabras, el sistema de interfase de hardware/software no requiere que la Partida sea almacenada y son soportadas ciertas operaciones, tales como la capacidad para enumerar el conjunto de Partidas actuales o la capacidad para recuperar una Partida determinada debido a su identificador (el cual se describe más completamente en las secciones que describen la interfase de programación de aplicación o API) de la plataforma de almacenamiento -- por ejemplo, una Partida puede ser la localización actual de un teléfono celular o la lectura de temperatura o un sensor de temperatura. El sistema de interfase de hardware/software puede manipular una pluralidad de Partidas y puede comprender además Partidas interconectadas por una pluralidad de Relaciones manejadas por un sistema de interfase de hardware/software.

Un sistema de interfase de hardware/software para el sistema de cómputo comprende además un esquema de núcleo para definir un conjunto de Partidas del núcleo, las cuales entiende y puede procesar directamente el sistema de interfase de hardware/software de una manera previamente determinada o que se puede pronosticar. Para manipular una pluralidad de Partidas el sistema de cómputo interconecta las Partidas con una pluralidad de Relaciones y maneja dichas Relaciones en el nivel del sistema de interfase de hardware/software. La API de la plataforma de almacenamiento proporciona bases de datos para cada partida, extensión de partidas y la relación definida en el conjunto de esquemas de la plataforma de almacenamiento. Además, la interfase de programación de aplicación proporciona un conjunto de clases del sistema que definen un conjunto común de comportamiento de las clases de datos y que, junto con las clases de datos, proporcionan el modelo básico de programación para la plataforma de almacenamiento API. La plataforma de almacenamiento API proporciona un modelo de solicitud simplificado que hace posible que los programadores de aplicación formulen preguntas basadas en diferentes propiedades de las partidas en el almacén de datos, de una manera que aisla al programador de la aplicación de los detalles del lenguaje de la pregunta en la máquina de base de datos subyacente. La plataforma de almacenamiento API también recolecta los cambios para una partida hechos por un programa de aplicación y luego los organiza en las actualizaciones correctas requeridas por la máquina de base de datos (o cualquier tipo de máquina de almacenamiento), en el cual está implementado el almacén de datos. Esto hace posible que los programadores de aplicación hagan cambios a una partida en la memoria, mientras que dejan la complejidad de las actualizaciones del almacenamiento de datos a la API. A través de estos fundamentos y datos esquematizados de almacenamiento comunes, la plataforma de almacenamiento a la presente invención hace posible un desarrollo de la aplicación más eficiente para los consumidores, trabajadores del conocimiento y empresas. Ofrece una interfase de programación de aplicación rica y que se puede extender y que no solamente pone a la disposición las capacidades inherentes en el modelo de datos, sino también comprende y se extiende a los sistemas de archivo existentes y los métodos de acceso a las bases de datos. Como parte de la estructura que forman un arco de las invenciones interrelacionadas (descritas con detalle en la Sección II de la Descripción Detallada), la presente invención está enfocada específicamente en las APIs de Sincronización (descritas en detalle en la Sección III de la Descripción Detallada). Se podrán apreciar algunas otras características y ventajas de la presente invención, a partir de la siguiente descripción detallada de la invención, y los dibujos adjuntos. Breve Descripción de ios Dibujos El sumario anterior, así como la siguiente descripción detallada de la invención, se comprenderán mejor cuando son leídos en conjunto con los dibujos adjuntos. Con el propósito de ilustrar la invención, se muestran en los dibujos modalidades de ejemplo de los diferentes aspectos de la presente invención; sin embargo, la presente invención no está limitada a los métodos e instrumentalidades específicas descritos. En los dibujos: La figura 1 es un diagrama de bloques que representa un sistema de cómputo en el cual pueden ser incorporados los aspectos de la presente invención; La figura 2 es un diagrama de bloques que ilustra un sistema de cómputo dividido en tres grupos de componentes: el componente de hardware, el componente del sistema de interfase de hardware/software y el componente de programas de aplicación; La figura 2A ¡lustra una estructura jerárquica basada en un á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; La figura 4 ilustra la relación estructural entre las Partidas, Carpeta de Partidas y Categorías; La figura 5A es un diagrama de bloques que ilustra la estructura de una Partida; La figura 5B es un diagrama de bloques que ilustra los tipos complejos de propiedades de una Partida de la figura 5A; La figura 5C es un diagrama de bloques que ilustra la Partida "Localización" en donde sus tipos complejos se describen adicionalmente (en una lista explícita); La figura 6A ilustra una Partida de un subtipo de Partida encontrada en el Esquema Básico; La figura 6B es un diagrama de bloques que ilustra el subtipo de la Partida de la figura 6a, en donde sus tipos heredados se encuentran en una lista explícita (además de sus propiedades inmediatas); La figura 7 es un diagrama de bloques que ¡lustra el Esquema Básico que incluye sus dos tipos de clase de nivel alto, Partida y Propiedad Básica y los tipos de Esquema Básico adicionales derivados de los mismos; La figura 8A es un diagrama de bloques que ilustra las Partidas en el Esquema del Núcleo; La figura 8B es un diagrama de bloques que ilustra los tipos de propiedades en el Esquema del Núcleo; La figura 9 es un diagrama de bloques que ilustra una Carpeta de Partidas y sus Partidas miembros y las Relaciones que la interconectan entre la Carpeta de Archivo y sus Partidas miembro; La figura 10 es un diagrama de bloques que ilustra una Categoría (la cual, nuevamente, es una Partida misma) y sus miembros de las Partidas y las Relaciones que las interconectan entre la Categoría y sus miembros de las Partidas; La figura 11 es un diagrama que ilustra un tipo de jerarquía de referencia del modelo de base de datos de la plataforma de almacenamiento; La figura 12 es un diagrama que ilustra como son clasificadas las relaciones; La figura 13 es un diagrama que ilustra un mecanismo de notificación; La figura 14 es un diagrama que ilustra un ejemplo en el cual dos transacciones están ambas cruzando un nuevo registro dentro del mismo Árbol-B; La figura 15 ilustra el proceso de detección de cambio de datos; La figura 16 ilustra un árbol de directorio de ejemplo; La figura 17 muestra un ejemplo en el cual una carpeta existente de un sistema de archivo basado en el directorio es movido dentro del almacén de datos de la plataforma de almacenamiento; La figura 18 ilustra el concepto de las Carpetas de Contención; La figura 19 ilustra la arquitectura básica de la API de plataforma de almacenamiento; La figura 20 representa esquemáticamente los diferentes componentes de la pila de la API de la plataforma de almacenamiento; La figura 21A es una representación ilustrativa de un esquema de Partida de Contactos de ejemplo; La figura 21B es una representación ilustrativa de los Elementos para el esquema de Partidas de Contactos de la figura 21A; La figura 22 ilustra el sistema de tiempo de ejecución de la API de plataforma de almacenamiento; La figura 23 ilustra la ejecución de una operación "FindAII"; La figura 24 ilustra el proceso por medio del cual las clases de la API de la plataforma de almacenamiento son generadas desde el Esquema de la plataforma de almacenamiento; La figura 25 ilustra el esquema en el cual está basada la API de Archivo; La figura 26 es un diagrama que ilustra un formato de máscara de acceso utilizado para propósitos de seguridad de los datos; La figura 27 (partes a, b y c) ilustra una nueva región de seguridad protegida de manera idéntica estando separada de una región de seguridad existente; La figura 28 es un diagrama que ilustra el concepto de una visión de búsqueda de Partida; La figura 29 es un diagrama que ilustra una jerarquía de Partidas de ejemplo; La figura 30A ilustra una interfase Interface 1 como un conducto a través del cual se comunican el primer y segundo segmento del código; La figura 30B ilustra una interfase que comprende los objetos 11 e 12 de interfase los cuales hacen posible que el primero y segundo elementos del código de un sistema se comuniquen por medio del medio ; La figura 31A ilustra la forma en que se proporciona la función por parte de la Interfasel que puede ser subdividida para convertir las comunicaciones de la interfase en las interfases múltiples InterfacelA, Interface 1B, Interface 1C; La figura 31B ilustra la forma como funciona la interfase 11 proporcionada la cual puede ser subdividida en interfases múltiples 11a, 11 b, 11c; La figura 32A ilustra un escenario en donde la precisión de los parámetros sin significado pueden ser ignorados o reemplazados por un parámetro arbitrario; La figura 32B ilustra un escenario en donde una interfase es reemplazada por una interfase substituto que es definida para ignorar o agregar parámetros a una interfase; La figura 33A ilustra un escenario en donde el 1er y 2do Segmentos de Código son fusionados en un módulo que contiene ambos; La figura 33B ilustra un escenario en donde parte de, o toda una interfase puede ser escrita en línea en otra interfase para formar una interfase fusionada; La figura 34A ¡lustra como una o más piezas de la parte media del programa pueden convertir las comunicaciones de la primera interfase para adaptarlas a una o más interfases diferentes; La figura 34B ilustra la forma en que puede ser introducido un código de segmento con una interfase para recibir las comunicaciones desde una interfase, pero transmitir la funcionalidad a la segunda y tercera interfases; La figura 35A ilustra la forma en que un recopilador justo-a-tiempo (JIT) podría convertir las comunicaciones de un segmento de código en otro segmento de código; La figura 35B ilustra el método JIT de nueva escritura dinámica de una o más interfases que puede ser aplicado para factorizar dinámicamente o alterar de otro modo dicha interfase; La figura 36 ilustra tres ejemplos del almacén común de datos y los componentes para sincronizarlos; y La figura 37 ilustra una modalidad de la presente invención que presume un adaptador simple que no conoce la condición en que es calculada una condición o son intercambiados sus metadatos asociados. Descripción Detallada de la Invención ÍNDICE I. INTRODUCCIÓN 31 A. ENTORNO DE CÓMPUTO DE EJEMPLO 31 B. ALMACENAMIENTO BASADO EN UN ARCHIVO TRADICIONAL 41 II. PLATAFORMA DE ALMACENAMIENTO WINFS PARA LA ORGANIZACIÓN, BÚSQUEDA Y PARTICIPACIÓN DE DATOS 44 A. GLOSARIO 44 B. REVISIÓN GENERAL DE LA PLATAFORMA DE ALMACENAMIENTO 46 C. EL MODELO DE DATOS 50 1. Partidas 53 2. Identificación de Partidas 61 3. Carpetas de Partidas y Categorías 63 4. Esquemas 67 a) Esquema Básico 67 b) Esquema del Núcleo 68 . Relaciones 72 a) Declaración de Relación 74 b) Relación de Posesión 77 c) Relaciones de Incrustación 79 d) Relaciones de Referencia 80 e) Reglas y Restricciones 82 f) Ordenamiento de Relaciones 83 6. Capacidad de Extensión 94 a) Extensiones de Partidas 96 b) Extensión de tipos NestedElement 103 D. MÁQUINA DE BASE DE DATOS 105 1. Implementación del almacén de Datos Utilizando UDTs 108 2. Mapeo de Partidas 110 3. Mapeo de Extensiones 112 4. Mapeo del Elemento Anidado 113 5. Identidad del Objeto 113 6. Denominación del Objeto SQL 114 7. Denominación de la Columna 115 8. Visiones de Búsqueda 116 a) Partida 118 (1) Visión de Búsqueda de Partida Maestra 118 (2) Visión de Búsqueda de Partidas Tipificadas 119 b) Extensiones de Partida 120 (1) Visión de Búsqueda de Extensión Maestra 120 (2) Visión de Búsqueda de Extensión Tipificada 121 c) Elementos Anidados 121 d) Relaciones 122 (1) Visión de Búsqueda de Relación Maestra 122 (2) Visión de Búsqueda de Objetos Específicos de Relación 122 e) -123- ualizaciones 123 astreo de Cambios y Emisiones de Seguridad 125 a) Rastreo de Cambios 125 (1) Rastreo de Cambio en las Visiones "Maestras de Búsqueda" 126 (2) Rastreo de Cambios en Visiones de Búsqueda "Tipificada" 128 b) Emisión de seguridad 129 (1) Emisión de seguridad de Partidas 129 (2) Emisión de seguridad de Extensiones 130 (3) Emisión de seguridad de Relaciones 130 (4) Eliminación de Emisión de seguridad 131 PIs de Ayuda y Funciones 131 a) Función [System. Storage].Getltem 132 b) Función [System. Storage].GetExtension 132 c) Función [System. Storage].GetRelationship 132 12. Metadatos 132 a) Metadatos del Esquema 132 b) Metadatos de Objeto Específico 132 E. SEGURIDAD 133 F. RASTREO DE NOTIFICACIONES Y CAMBIOS 134 G. I NTEROPERABI LIDAD DEL SISTEMA DE ARCHIVO TRADICIONAL 136 H. API DE PLATAFORMA DE ALMACENAMIENTO 138 III. API DE SINCRONIZACIÓN A. VISTA GENERAL DE SINCRONIZACIÓN 153 1. Sincronización de Almacenamiento- Plataforma a Almacenamiento-Plataforma 155 a) Aplicaciones de Control de Sincronización (Sync) 156 b) Anotaciones del Esquema 157 c) Configuración de Sincronización 159 (1) Carpeta de la Comunidad - Mapeo 161 (2) Perfiles 163 (3) Programas 165 d) Manejo de Conflictos 165 (1) Detección de Conflictos 166 (a) Conflictos Basados - en el Conocimiento 166 (b) Conflictos Basados - en las Restricciones 167 (2) Procesamientos de Conflictos 167 (a) Solución Automática de Conflictos 168 (b) Registro de Conflictos 170 (c) Inspección y Solución de Conflictos 171 (d) Convergencia de Replicas y Propagación de Soluciones de Conflictos 171 2. Sincronización para almacenes de datos de la plataforma que no son de almacenamiento 173 a) Servicio de sincronización 174 (1) Enumeración de cambios 174 (2) Aplicación de Cambios 177 (3) Solución de conflictos 178 b) Implementación del adaptador 178 3. Seguridad 179 4. Capacidad de manejo 180 B. REVISIÓN GENERAL - API DE SINCRONIZACIÓN 181 1. Terminología general 182 2. Conceptos principales de la API de sincronización 186 C. SERVICIOS DE LA API DE SINCRONIZACIÓN 190 1. Enumeración de cambios 190 2. Aplicación de cambios 192 3. Código de muestra 194 4. Métodos de sincronización de la API 199 D. ASPECTOS ADICIONALES DEL ESQUEMA DE SINCRONIZACIÓN 202 IV. CONCLUSIÓN 205 1. INTRODUCCIÓN El asunto materia de la presente invención se describe con especificad para cubrir los requerimientos de los estatutos. Sin embargo, la descripción misma no pretende limitar el alcance de esta patente. En vez de ello, los inventores han contemplado que el asunto materia reclamado también puede ser incorporado de otras maneras, para incluir pasos o combinaciones de pasos diferentes similares a los descritos en este documento, en conjunto con otras tecnologías actuales o futuras. Además, aunque el término "paso" puede ser utilizado en la presente descripción para indicar elementos diferentes de métodos empleados, el término no debe de ser interpretado como que implica cualquier orden particular entre varios pasos aquí descritos, al menos y excepto cuando el orden de los pasos individuales se describa de manera explícita. A. ENTORNO DE CÓMPUTO DE EJEMPLO Numerosas modalidades de la presente invención se pueden ejecutar en una computadora. La figura 1 y la siguiente descripción pretenden proporcionar una descripción general breve de un entorno de cómputo adecuado en el cual la presente invención puede ser implementada. Aunque no se requiere, varios aspectos de la presente invención se pueden describir en el contexto general de instrucciones ejecutables por computadora, tales como módulos de programa, siendo ejecutados por una computadora, tales como una estación de trabajo del cliente o un servidor. Generalmente, 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 particulares. Además, la presente invención puede ser practicada con otras configuraciones del sistema de cómputo, incluyendo aparatos portátiles, sistemas de procesador múltiple, microprocesadores basados en componentes electrónicos que se pueden programar por el consumidor, PCs de red, minicomputadoras, computadoras de sistemas y similares. La presente invención también puede ser practicada en entornos de cómputo distribuidos en donde las tareas son realizadas por aparatos de procesamiento remotos que están enlazados a través de una red de comunicaciones. En un entorno de cómputo distribuido, los módulos del programa pueden estar localizados tanto en los aparatos de almacenamiento de memoria locales como remotos. Tal y como se muestra en la figura 1, un sistema de cómputo de uso general de ejemplo incluye una computadora personal convencional 20 o similar que incluye una unidad de procesamiento 21, una memoria de sistema 22, un bus del sistema 23 que conecta varios componentes del sistema incluyendo la memoria del sistema a la unidad de procesamiento 21. El bus del sistema 23 puede ser cualquiera de varios tipos de estructuras del bus, incluyendo, un bus de memoria o controlador de memoria, un bus periférico, un bus local que utiliza cualquiera de una variedad de arquitecturas del bus. La memoria del sistema incluye una memoria solo de lectura, (ROM) 24, y una memoria de acceso aleatorio (RAM) 25. Un sistema de entrada/salida básico 26 (BIOS), que contiene las rutinas básicas para ayudar a transferir la información entre los elementos dentro de la computadora personal, tal como durante el arranque, es almacenado en la memoria ROM 24. La computadora personal 20 puede incluir además una unidad de disco duro 27 para leer y escribir en el disco duro, no mostrado, una unidad de disco magnético 28 para leer y escribir en un disco magnético removible 29, una unidad de disco óptico 30 para leer y escribir en un disco óptico removible 31, tal como un CD ROM u otros medios ópticos. La unidad de disco duro 27, la unidad de disco magnético 28 y la unidad de disco óptico 30 son conectadas al bus del sistema 23 por medio de la interfase de la unidad de disco duro 32, una interfase de unidad de disco magnético 33 y una interfase de unidad de disco óptico 34, respectivamente. Las unidades y sus medios legibles por computadora asociados proporcionan el almacenamiento no volátil de las instrucciones legibles por computadora, las estructuras de datos, módulos de programa y otros datos para la computadora personal 20. Aunque el entorno de ejemplo descrito emplea una unidad de disco duro, aquellos expertos en la técnica deberán apreciar que un disco magnético removible 29 y un disco óptico 21 removible y otros tipos de medios legibles por computadora los cuales pueden almacenar datos y que se puedan tener acceso a ellos por medio de la computadora, tales como cassetes magnéticos, tarjetas de memoria instantánea, discos digitales de video, cartuchos Bernoulli, memorias de acceso aleatorio (RAMs), memoria solo de lectura (ROMs) y similares, también pueden ser utilizados en el entorno operativo de ejemplo. De un modo similar, el entorno de ejemplo puede incluir también muchos tipos de dispositivos de monitoreo tales como sensores de calor y seguridad y sistemas de alarma contra incendio y otras fuentes de información. Un número de módulo de programa pueden ser almacenados en el disco duro, el disco magnético 29, el disco óptico 31, y las memorias RAM 24 ó RAM 25, incluyendo un sistema operativo 35, uno o más programas de aplicación 36, otros módulos dél programa 37 y datos del programa 38. Un usuario puede ingresar comandos e información en la computadora personal 20 a través de los dispositivos de entrada tales como un teclado 40 y un dispositivo de señalamiento 42. Otros dispositivos de entrada (no mostrados) pueden incluir un micrófono, una palanca, una almohadilla de juegos, un disco de satélite, un escáner, o similares. Estos y otros dispositivos de entrada, con frecuencia son conectados a la unidad de procesamiento 21 a través de una inferíase de puerto de serie 46, que está conectado al bus del sistema, pero que pueden ser conectados por otras interfases, tales como un puerto paralelo, puerto para juegos o un bus de serie universal (USB). Un monitor 47 u otro tipo de dispositivo de pantalla pueden ser conectados al bus del sistema 23 por medio de una interfase, tal como un adaptador de video 48. Además del monitor 47, la computadora personal generalmente incluye otros dispositivos de salida periféricos (no mostrados), tales como bocinas e impresoras. El sistema de ejemplo de la figura 1 incluye también un adaptador central 55, un bus de interfase de Sistema de Cómputo Pequeño 56, un dispositivo externo de almacenamiento 62 conectado al bus SCSI 56. La computadora personal 20 puede operar en un entorno de red utilizando conexiones lógicas a una o más computadoras remotas, tales como la computadora remota 49. La computadora remota 49 puede ser otra computadora personal, un servidor, un enrutador, una PC de red, un aparato semejante u otros nodos de red común y generalmente incluye muchos o todos los elementos descritos anteriormente relacionados con la computadora personal 20, aunque solamente se ilustra en la figura 1 un dispositivo de almacenamiento de memoria 50. Las conexiones lógicas ilustradas en la figura 1 incluyen una red de área local (LAN) 51 y una red de área amplia (WAN) 52. Dichos entornos de red son un lugar común en las oficinas, las redes de cómputo de las empresas, la intranet y la Internet. Cuando se utiliza en un entorno de red LAN, la computadora personal 20 es conectada a la red LAN 51 a través de una interfase o adaptador de red 53. Cuando es utilizado en un entorno de red WAN, la computadora personal 20 generalmente, incluye un módem 54 u otros medios para establecer comunicaciones por la red de área amplia 52, tales como la Internet. El módem 54 el cual puede ser interno o externo, es conectado al bus del sistema 23 por medio de la interfase del puerto de serie 46. En un entorno de red, los módulos del programa ilustrados en relación con la computadora personal 20, o porciones de los mismos, pueden ser almacenados en el dispositivo de almacenamiento de memoria remoto. Se deberá apreciar que las conexiones de red mostradas son de ejemplo, que se pueden utilizar también otros medios para establecer un enlace de comunicación entre las computadoras. Tal y como se ilustra en el diagrama de bloques de la figura 2, un sistema de cómputo 200 puede ser dividido simplemente en tres grupos de componentes: el componente de hardware 202, el componente del sistema de interfase hardware/software 204 y el componente de programa de aplicación del programa 206 (al que también nos referimos como el "componente del usuario" o "componente del software" en ciertos contextos en la presente descripción). En varias modalidades de un sistema de cómputo 200 y haciendo referencia nuevamente a la figura 1, el componente del hardware 202 puede comprender la unidad de procesamiento central (CPU) 21, la memoria (tanto ROM 24 como RAM 25), el sistema de entrada/salida básico (BIOS) 26 y varios dispositivos de entrada/salida (l/O), tales como un teclado 40, un ratón 42, un monitor 47 y/o una impresora (no mostrada), entre otras cosas. El componente de hardware 202 comprende la infraestructura física básica para el sistema de cómputo 200. El componente de los programas de aplicación 206 comprenden varios programas de software incluyendo pero sin limitarse a recopiladores, sistemas de base de datos, procesadoras de palabras, programas comerciales, juegos de video y así sucesivamente. Los programas de aplicación proporcionan los medios por los cuales los recursos de la computadora son utilizados para solucionar problemas, proporcionar soluciones y procesar datos para varios usuarios (máquinas, otros sistemas de cómputo y/o usuarios finales). En el componente del sistema de interfase hardware/software 204 comprende (y en algunas modalidades, puede consistir solamente de un sistema operativo que comprende el mismo, en la mayor parte de los objetos específicos, una caparazón y un kernel. Un "sistema operativo"(OS) es un programa especial que actúa como un intermediario entre los programas de aplicación y el hardware de computadora. El componente del sistema de interfase hardware/software 204 también puede comprender un administrador de máquina virtual (VMM), un tiempo de Operación de Lenguaje Común (CLR) o su equivalente funcional, una máquina virtual Java (JVM) o su equivalente funcional u otros componentes de software en lugar de o además del sistema operativo en un sistema de cómputo. El propósito del sistema de interfase hardware/software es proporcionar un entorno en el cual un usuario puede ejecutar los programas de aplicación. La meta de cualquier sistema de interfase de hardware/software es hacer que se use de manera conveniente el sistema de cómputo, así como utilizar el hardware de cómputo de una manera eficiente. El sistema de interfase de hardware/software generalmente es cargado en un sistema de cómputo en el arranque y posteriormente administra todos los programas de aplicación en un sistema de cómputo. Los programas de aplicación interactúan con el sistema de interfase de hardware/software solicitando servicios por medio de la interfase del programa de aplicación (API). Algunos programas de aplicación hacen posible que los usuarios finales interactúen con el sistema de interfase hardware/software por medio de una interfase del usuario tal como un lenguaje de comando o una interfase gráfica del usuario (GUI). Un sistema de interfase de hardware/software realiza tradicionalmente una variedad de servicios para las aplicaciones. En un sistema de interfase de hardware/software de tareas múltiples en donde los programas múltiples pueden ser ejecutados al mismo tiempo, el sistema de interfase de hardware/software determina cuales aplicaciones se deben ejecutar en que orden y cuanto tiempo se debe de permitir para cada aplicación antes de cambiar a otra la aplicación para un turno. El sistema de interfase de hardware/software también administra la participación de la memoria interna entre aplicaciones múltiples y maneja la entrada y salida a y desde los aparatos de hardware adjuntos, tales como los discos duros, impresoras y puertos de marcado. El sistema de interfase de hardware/software también envía mensajes a cada aplicación (y en ciertos objetos específicos, al usuario final), con respecto a las condiciones de operación y cualesquiera errores que pudieran haber ocurrido. El sistema de interfase hardware/software también puede descargar la administración de las tareas del lote (por ejemplo, la impresión), de modo que iniciando una aplicación se libera de este trabajo y puede reasumir otro procesamiento y/u operaciones. En las computadoras que pueden proporcionar el procesamiento paralelo, un sistema de ¡nterfase de hardware/software también administra la división de un programa, de modo que se opere en más de un procesador a la vez. La caparazón del sistema de interfase de hardware/software (a la que aquí nos referimos simplemente como "la caparazón"), es una interfase interactiva del usuario final para un sistema de interfase de hardware/software. (También nos podemos referir a una caparazón como un "interpretador de comandos" o en un sistema operativo, como una "caparazón del sistema operativo"). La caparazón es la capa exterior del sistema de interfase de hardware/software a la que se puede tener directamente acceso por medio de los programas de aplicación y/o usuarios finales. En contraste con la caparazón, un kernel es una capa más interna de los sistemas de interfase de hardware/software que interactúa directamente con los componentes del hardware. Aunque está previsto que numerosas modalidades de la presente invención están particularmente bien adecuadas para los sistemas computarizados, nada en este documento pretende limitar la presente invención a dichas modalidades. Por el contrario, tal y como se usa en la presente descripción el término "sistema de cómputo" pretende comprender cualquiera y todos los aparatos con capacidad para almacenar y procesar información y/o capacidad para utilizar la información almacenada para controlar el comportamiento o ejecución del aparato mismo, independientemente de si dichos aparatos son electrónicos, mecánicos, lógicos o de naturaleza virtual. B. ALMACENAMIENTO BASADO EN ARCHIVO TRADICIONAL En la mayor parte de las computadoras de la actualidad, los "archivos" son unidades de información que se pueden almacenar, que pueden incluir el sistema de interfase de hardware/software, así como los programas de aplicación, conjuntos de datos y así sucesivamente. En todos los sistemas de interfase de hardware/software del módem (Windows, Unix, Linux, Mac OS, sistemas de máquina virtual y así sucesivamente), los archivos son las unidades de información separadas básicas (que se pueden almacenar y recuperar) (por ejemplo, datos, programas y así sucesivamente), que pueden ser manipulados por el sistema de interfase hardware/software. Los grupos de archivos generalmente son organizados en "carpetas". En el sistema Microsoft Windows o Macintosh OS, y otros sistemas de interfase de hardware/software, una carpeta es una colección de archivos que pueden ser recuperados, movidos, o manipulados de otra manera como unidades sencillas de información. Estas carpetas, a la vez, son organizadas en una adaptación jerárquica basada en un árbol denominado un "directorio" (que se explica con mayor detalle más adelante). En otros ciertos sistemas de interfase de hardware/software, tales como DOS,z/OS y la mayor parte de los sistemas operativos basados en Unix, los términos "directorio" y/o "carpeta" son intercambiables, y los primeros sistemas de computadora Apple (es decir, el Apple Me), utilizaron el término "catálogo" en vez de directorio; sin embargo, tal y como se usa en la presente descripción, se considera que todos estos términos son sinónimos e intercambiables y pretenden incluir además todos los otros términos equivalentes y referencias para las estructuras de almacenamiento de información jerárquica y sus carpetas y componentes de archivo. Tradicionalmente, un directorio ( a.k.a. un directorio de carpeta), es una estructura jerárquica basada en un árbol en donde los archivos son agrupados en carpetas y una carpeta, a la vez, es adaptada de acuerdo con las localizaciones relativas del nodo que comprende el árbol de directorios. Por ejemplo, tal y como se ilustra en la figura 2 A, una carpeta básica del sistema de archivo basada en el sistema operativo DOS (o"directorio raíz") 212 puede comprender una pluralidad de carpetas 214, y cada una de ellas puede comprender además carpetas tradicionales (en la forma de "subcarpetas" de esa carpeta particular) 216 y cada una de éstas también puede comprender carpetas adicionales 218 ad infinitum. Cada una de estas carpetas puede tener uno o más archivos 220 aunque, en el nivel de interfase de hardware/software, los archivos individuales de una carpeta, no tienen nada en común con otros, solamente la localización en la jerarquía del árbol. Por lo tanto, no es sorprendente que este método de organización de archivos en jerarquía de carpetas refleje indirectamente la organización física de los medios de almacenamiento típicos utilizados para almacenar estos archivos (es decir, discos duros, discos flexibles, CD-ROMs, etcétera). Además de lo anterior, cada carpeta es un contenedor para subcarpetas y sus archivos -- es decir cada carpeta posee subcarpetas y archivos. Por ejemplo, cuando es borrada una carpeta por el sistema de interfase de hardware/software, las subcarpetas y archivos de la carpeta también son borrados (lo cual en el caso de cada subcarpeta, incluye además sus propias subcarpetas y archivos repetidamente). De un modo similar, cada archivo generalmente es_ poseído por una sola carpeta y aunque el archivo puede ser copiado y la copia localizada en una carpeta diferente, una copia de un archivo mismo es una unidad distinta y separada que no tiene conexión de dirección con el original (por ejemplo, los cambios en el archivo original no son monitoreados por espejo en la copia del archivo en el nivel de sistema de interfase de hardware/software. En este aspecto, los archivos y carpetas son, por lo tanto, característicamente de naturaleza "física" debido a que las carpetas son tratadas como contenedores físicos y los archivos son tratados como elementos físicos separados, dentro de estos contenedores. II. PLATAFORMA DE ALMACENAMIENTO WINFS, PARA ORGANIZAR, BUSCAR Y COMPARTIR DATOS. La presente invención, en combinación con las invenciones relacionadas incorporadas como referencia como se explicará más adelante, se refiere 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 tipos de sistema de archivo existente y sistemas de datos que se explicaron anteriormente, está diseñada para que sea el almacén de todos los tipos de datos, incluyendo una nueva forma de datos denominada Partidas. A. GLOSARIO Como se usa en la presente descripción y las reivindicaciones, los términos siguientes tienen el siguiente significado: • Una "Partida" es una unidad de información que se puede almacenar la cual puede tener acceso a un sistema de la interfase de hardware/software que, a diferencia de un archivo simple, es un objeto que tiene un conjunto básico de propiedades que son soportadas comúnmente en todos los objetos expuestos a un usuario final por la caparazón del sistema de interfase de hardware/software. Las Partidas también tienen propiedades y relaciones que son soportadas de manera común en todos los tipos de "Partidas" incluyendo características que permiten que sean introducidas nuevas propiedades y relaciones (y que se explicarán con mayor detalle más adelante). Un "sistema operativo" (OS), es un programa especial que actúa como un intermediario entre los programas de aplicación y el hardware de la computadora. Un sistema operativo comprende en la mayor parte de los objetos específicos, una caparazón y un kernel. Un "sistema de interfase de hardware/software" es un software o una combinación de hardware y software, que sirve como la interfase entre los componentes subyacentes de hardware de un sistema de cómputo y las aplicaciones que se ejecutan en el sistema de cómputo. Un sistema de interfase de hardware/software comprende generalmente (y en algunas modalidades, puede consistir únicamente de un sistema operativo). Un sistema de interfase de hardware/software también puede comprender un administrador virtual de la máquina (VMM), un tiempo de operación de lenguaje común (CLR) o su equivalente funcional, una máquina virtual Java (JVM) o su equivalente funcional, u otros componentes del software en lugar de o además del sistema operativo en un sistema de cómputo. El propósito de un sistema de interfase de hardware/software es proporcionar un entorno en el cual un usuario puede ejecutar programas de aplicación. La meta de cualquier sistema de interfase de hardware/software es hacer que el sistema de cómputo sea conveniente para utilizarlo, así como también el hardware de cómputo de una manera eficiente. B. REVISIÓN GENERAL LA PLATAFORMA DE ALMACENAMIENTO Haciendo referencia a la figura 3, una plataforma de almacenamiento 300 comprende un almacén de datos 302 implementado en una máquina de base de datos 314. En una modalidad, una máquina de base de datos comprende una máquina de base de datos de relación con extensiones de relación de objetos. En una modalidad, la máquina de base de datos de relación 314 comprende una máquina de base de datos de relación Microsoft SQL Server. El almacén de datos 302 implementa un modelo de datos 304 que soporta la organización, búsqueda, participación, sincronización, y seguridad de los datos. Los tipos específicos de datos se describen en los esquemas, tales como los esquemas 340 y la plataforma de almacenamiento 300 proporciona herramientas 346 para desplegar en pantalla esos esquemas así como para extender esos esquemas, tal y como se describirá con mayor detalle más adelante. Un mecanismo de rastreo de cambios 306 implementado dentro del almacén de datos 302 proporciona la capacidad para rastrear cambios al almacén de datos. El almacén de datos 302 también proporciona capacidades de seguridad 308 y una capacidad de promoción/degradación 310, ambas de las cuales se discutirán con mayor detalle más adelante. El almacén de datos 302 también proporciona conjuntos de interfase de programación de aplicación 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 comprende además, las interfases de programación de aplicación (API)322, las cuales hacen posible que los programas de aplicación, tales como los programas de aplicación 350a, 350b y 350c, accedan a todas las capacidades anteriores de la plataforma de almacenamiento, y accedan a los datos descritos en los esquemas. La plataforma de almacenamiento API 322 puede ser utilizada por los programas de aplicación y en combinación con otras APIs, tales como la API 324 OLE DB y la API 326 Microsoft Windows Win 32. La plataforma de almacenamiento 300 de la presente invención puede proporcionar una variedad de servicios 328 a los programas de aplicación, incluyendo un servicio de sincronización 330 que facilita la participación de datos entre los usuarios o sistemas. Por ejemplo, el servicio de sincronización 330 puede hacer posible la interoperabilidad con otros almacenes de datos 340 que tienen el mismo formato que el almacén de datos 302, así como acceder a los almacenes de datos 342 que tienen formatos diferentes. La plataforma de almacenamiento 300 también proporciona capacidades de sistema de archivo que permiten la interoperabilidad del almacén de datos 302 con los sistemas de archivos existentes, tales como el sistema de archivos Windows NTFS 318. En por lo menos algunas modalidades, la plataforma de almacenamiento 320 también puede proporcionar programas de aplicación con capacidades adicionales para hacer posible que los datos sean activados y para hacer posible la interacción con otros sistema. Estas capacidades pueden ser incorporadas en la forma de servicios adicionales 328, tales como el servicio del Info Agent 334 y un servicio de notificación 332, así como en la forma de otras utilidades 336. En por lo menos algunas modalidades, la plataforma de almacenamiento está incorporada en, o forma una parte integral de, el sistema de interfase de hardware/software de un sistema de cómputo. Por ejemplo, y sin limitación, la plataforma de almacenamiento de la presente invención puede ser incorporada en, o formar una parte integral de, un sistema operativo, 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. A través de sus principios de almacenamiento común y los datos esquematizados, la plataforma de almacenamiento de la presente invención hace posible desarrollos de aplicación más eficientes para los consumidores, trabajadores de conocimiento y empresas. Ofrece un área de superficie de programación rica y que se puede extender, que no solamente pone a disposición las capacidades inherentes en el modelo de datos, sino también comprende y se extiende a los métodos de acceso a la base de datos y sistemas de archivo existentes. En la descripción siguiente y varias de las figuras, a la plataforma de almacenamiento 300 de la presente invención nos podemos referir como "WinFS". Sin embargo, el uso de este nombre para referirnos a la forma de almacenamiento es solamente por razones de conveniencia de la descripción y no pretende ser limitativo de modo alguno. C. EL MODELO DE DATOS El almacén de datos 302 de la plataforma de almacenamiento 300 de la presente invención implementa un modelo de datos que soporta la organización, búsqueda, participación, sincronización y seguridad de datos que residen en el almacén. En el modelo de datos de la presente invención, una "Partida" es la unidad fundamental de la información de almacenamiento. El modelo de datos proporciona un mecanismo para declarar Partidas y extensiones de Partidas y para establecer las relaciones entre las Partidas y para organizar Partidas en Carpetas de Partidas en Categorías, como se describirá más completamente más adelante. El modelo de datos depende de dos mecanismos primitivos, Tipos y Relaciones. Los Tipos son estructuras las cuales proporcionan un formato el cual rige la forma de un ejemplo del Tipo. El formato es expresado como un conjunto de Propiedad ordenada. Una Propiedad es un nombre para un valor o conjunto de valores de un Tipo determinado, por ejemplo, un tipo USPostal Address podría tener las propiedades calle, ciudad, código postal, estado, en las cuales calle, ciudad y estado son un Tipo de cadena y el código postal es un Tipo Int32. La calle puede ser multivaluada (por ejemplo, con un conjunto de valores) que permitan que la dirección tenga más de un valor para la propiedad Calle. El sistema define ciertos sistemas primitivos que pueden ser utilizados en la construcción de otros Tipos --estos incluyen, cadenas, binarios Boolean Int16, Int32, Int34, sencillo, doble, Byte, hora fecha, decimales y GUID. Las Propiedades de un Tipo pueden ser definidas utilizando cualquiera de los Tipos de primitivas (o con algunas restricciones que se observarán más adelante) de cualquiera de los tipos construidos. Por ejemplo, un Tipo de Localización podría ser definido para que tuviera una coordenada de Propiedades y Dirección, en donde la Propiedad de Dirección es del Tipo USPostal Address, tal y como se describió anteriormente. Las Propiedades también pueden ser requeridas u opcionales. Las relaciones pueden ser declaradas y representar un mapeo entre los conjuntos de objetos específicos de dos tipos. Por ejemplo, puede haber una relación declarada entre el Tipo de Persona y el Tipo de Localización , denominado Lives At el cual define que personas viven en que localizaciones. La Relación tiene un nombre, dos puntos finales, es decir un punto final fuente y un punto final objetivo. Las Relaciones también pueden tener un conjunto ordenado de propiedades. Tanto los puntos finales de Fuente como de Objetivo tienen un Nombre y un Tipo. Por ejemplo, la relación Lives At tiene una fuente denominada ocupante de persona Tipo, y un objetivo denominado que vive de la localización Tipo y además tiene y además tiene propiedades StartDate y EndDate que indican el periodo del tiempo por el cual el ocupante vivió en ese alojamiento. Observar que una persona puede vivir en alojamientos múltiples con el paso del tiempo, y un alojamiento puede tener ocupantes múltiples de modo que el lugar más probable para colocar la información StartDate y EndDate es en la relación misma. Las relaciones definen un mapeo entre los objetos específicos que están restringidos por los tipos proporcionados como los tipos de punto final. Por ejemplo, la relación LivesAt, no puede ser una relación en la cual un Automóvil, es el Ocupante debido a que el automóvil no es una persona. El modelo de datos no permite la definición de un subtipo-subrelación subtipo-supertipo entre los tipos. La relación subtipo-supertipo también conocida como la relación BaseType es definida de un modo tal que si el Tipo A es un BaseType para el Tipo B, debe de ser el caso de que cada objeto específico de B también sea un objeto específico de A. Otro modo para expresar esto es que cada objeto específico se adapta a B también se debe de adaptar a A. Si, por ejemplo, A tiene un nombre de propiedad de una cadena Tipo mientras que B tiene una edad de propiedad del Tipo Int16, sigue que cualquier objeto específico de B debe tener, tanto un nombre como una edad. La jerarquía del tipo puede ser contemplada como un árbol con un solo supertipo en la raíz. Las ramas de la raíz proporcionan los subtipos de primer nivel, las ramas en este nivel proporcionan los subtipos del segundo nivel y así sucesivamente, hasta los subtipos de la mayor parte de las hojas, los cuales ellos mismos no tienen ningún subtipo. El árbol no está restringido a que sea de una profundidad uniforme, pero no puede contener cualesquiera ciclos. Un tipo determinado puede tener cero o muchos subtipos, y cero o un supertipo. Un objeto específico determinado se puede adaptar a cuando mucho un tipo junto con los supertipos del tipo. Para ponerlo de otro modo, para un objeto específico determinado en cualquier nivel del árbol el objeto específico se debe de adaptar en su mayor parte a un subtipo en ese nivel. Un tipo se dice que es Abstracto y los objetos específicos del tipo deben tener también un objeto específico de un subtipo del tipo. 1. Partidas Una Partida 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 son soportadas comúnmente en todos los objetos expuestos a un usuario final o programa de aplicación por la plataforma de almacenamiento. Las Partidas también tienen propiedades y relaciones que son soportadas de manera común en todos los tipos de Partidas que incluyen características que permiten que sean introducidas nuevas propiedades y relaciones, como se explicarán más adelante. Las Partidas son los objetos para las operaciones comunes tales como copiar, eliminar, mover, abrir, imprimir, respaldar, restaurar, copiar y así sucesivamente. Las Partidas son las unidades que pueden ser almacenadas y recuperadas, y todas las formas de información que se pueden almacenar manipuladas por la plataforma de almacenamiento, existen en la forma de Partidas, propiedades de Partida o Relaciones entre Partidas, y cada una de las cuales se explicará con mayor detalle más adelante. Las Partidas pretenden representar unidades fácilmente entendibles y del mundo real de datos, tales como contactos, gente, servicios, localizaciones, documentos (de todos los diferentes tipos) y así sucesivamente. La figura 5 A es un diagrama de bloques que ilustra la estructura de una Partida. El nombre sin calificar de la Partida es "localización". El nombre calificado de la Partida es "Core.Location" el cual indica que esta estructura de Partida es definida como un tipo específico de Partida en el esquema del núcleo (el esquema del núcleo se explicará con mayor detalle más adelante).

La Partida de Localización tiene una pluralidad de propiedades incluyendo EAdress, MetrpolitanRegion, Neighborhood, y Postal Addresses. El tipo específico de propiedad para cada uno es indicado inmediatamente después del nombre de la propiedad y está separado del nombre de la propiedad por: (":"). A la derecha del nombre del tipo, el número de valores permitido para ese tipo de propiedad es indicado entre paréntesis ("[ ]") en donde un asterisco ("*") a la derecha de los dos puntos (":") indica un número no especificado y/o ilimitado ("muchos") un "1" a la derecha de los dos puntos indica que puede haber cuando mucho un valor. Un cero ("0") a la izquierda de los dos puntos indican que la propiedad es opcional (que puede no tener valor en lo absoluto). Un "1" a la izquierda de los dos puntos indica que debe de haber por lo menos de haber un valor (la propiedad es requerida). Neighborhood y Metropoltan Región ambos son del tipo "nvarchar" (o equivalente) el cual es un tipo de datos previamente definido o "tipo simple" (y aquí indicado por la falta de letras mayúsculas). Sin embargo, EAddresses y Postal Addresses, son propiedades de tipos definidos o "tipos complejos" (como se indicó en el presente documento por medio de las mayúsculas) de los tipos EAddress y Postal Address, respectivamente. Un tipo complejo es el tipo que es derivado de uno o más tipos de datos simples y/o de otros tipos complejos. Los tipos complejos para las propiedades de una partida también constituyen (elementos anidados) ya que los detalles del tipo complejo son anidados en una partida inmediata para definir sus propiedades y la información que pertenece a ese tipo complejo es mantenida con la Partida que tiene estas propiedades (dentro del límite de las Partidas, como se explicará con mayor detalle más adelante). Estos conceptos de tipificar son bien conocidos y pueden ser apreciados fácilmente por aquellos expertos en la técnica. La figura 5B es un diagrama de bloque que ilustra un tipo de propiedad complejo Postal Address y EAddress. El tipo de propiedad Postal Address define que una Partida del tipo de propiedad Postal Address se puede esperar que tenga valores de Ciudad, cero o uno valores de CountryCode, cero o uno, valores de MailStop, y cualquier número (de cero a muchos) de PostalAddressTypes y así sucesivamente. De este modo, la forma de los datos para una propiedad particular en una Partida se define de esta manera. La propiedad EAddress se define de un modo similar al mostrado. Aunque se usa opcionalmente en esta solicitud, otro medio para representar los tipos complejos en la Partida de Localización, es dibujar la Partida con propiedades individuales de cada tipo de complejo que se encuentra en la lista. La figura 5C es un diagrama de bloques que ilustra la Partida de Localización en donde los tipos complejos se describen adicionalmente. Sin embargo, deberá quedar entendido que esta representación alternativa de la Partida de Localización en esta figura 5C, es para la misma Partida exacta ¡lustrada en la figura 5 A. La plataforma de almacenamiento de la presente invención también permite la subtipificación en donde un tipo de propiedad puede ser un subtipo de otra (en donde un tipo de propiedad hereda las propiedades de otra, de otro tipo de propiedad de origen). De un modo similar pero diferente a las propiedades y subtipos de propiedad, las Partidas representan inherentemente sus propios tipos de Partida que pueden ser sometidas a la subtipificación. En otras palabras, la plataforma de almacenamiento en varias modalidades de la presente invención permite que una Partida, sea un subtipo de otra Partida (en donde la Partida 1 hereda las propiedades de otra, Partida original). Además, en las diferentes modalidades de la presente invención, cada Partida es un subtipo de un tipo de Partida "Partida" el cual es el primer y tipo de Partida fundamental encontrado en el esquema básico (el esquema básico también se describirá con mayor detalle más adelante). La figura 6 A ilustra un Partida, la Partida de Localización en este objeto específico, como que es un subtipo del tipo de Partida encontrado en el esquema básico. En este dibujo, la flecha indica que la Partida de Localización (como todas las otras Partidas), es un subtipo del tipo de Partida. El tipo de Partida es una Partida fundamental desde la cual son derivadas las otras Partidas, y tiene un número de propiedades importantes, tales como Itemld y sellos de tiempos diferentes, y por lo tanto, definen las Propiedades estándar de todas las Partidas de un sistema operativo. En la figura presente, estas propiedades de tipo de Partida son heredadas por la localización, y por lo tanto, llegan a ser propiedades de la localización. Otro modo de representar las propiedades en la Partida de Localización heredadas de otro tipo de Partida, es dibujar la localización con las propiedades individuales de cada tipo de propiedad de la Partida de origen de la lista aquí contenida. La figura 6B es un diagrama de bloques que ilustra la Partida de Localización en donde sus tipos heredados descritos adicionalmente son descritos además de sus propiedades inmediatas. Deberá observarse y entenderse que esta Partida es la misma ilustrada en la figura 5 A, aunque en la figura actual la localización es ilustrada con todas sus propiedades, tanto inmediatas - mostradas en ambas de estas figuras, y la figura 5 A como heredadas - mostradas en esta figura pero no en la figura 5 A (mientras que en la figura 5 A a estas propiedades nos referimos mostrándolas con una flecha de esta Partida de Localización que es un subtipo del tipo de Partida). Las Partidas son objetos independientes; por lo tanto, si usted elimina una Partida, todas las Partidas inmediatas y propiedades heredadas también son eliminadas. De un modo similar, cuando se recupera una Partida lo que es recibido es la Partida y todas sus propiedades inmediatas y heredadas (incluyendo la información perteneciente a sus tipos complejos de propiedad). Ciertas modalidades de la presente invención pueden hacer posible que se solicite un subconjunto de propiedades cuando se recupera una Partida específica; sin embargo, las opciones por omisión (default) para muchas de dichas modalidades es proporcionar la Partida, con todas sus propiedades inmediatas y heredadas cuando son recuperadas. Además, las propiedades de las Partidas pueden ser extendidas agregando nuevas propiedades a las propiedades existentes de ese tipo de Partidas. Estas "extensiones" por lo tanto, son propiedades de buena fe de la Partida, y los subtipos del tipo de Partida pueden incluir automáticamente la extensión de propiedades. El "límite" de la Partida es representado por sus propiedades (incluyendo tipos complejos de propiedad, extensiones y así sucesivamente). Un límite de la Partida también representa el límite de una operación realizada en una Partida tal como copiar, eliminar, mover, crear y así sucesivamente. Por ejemplo, en varias modalidades de la presente invención, cuando es copiada una Partida, todo lo que se encuentra dentro de ese límite de la Partida es copiado también. Para cada Partida, el límite comprende lo siguiente: • El Tipo de Partida de la Partida y si la Partida es un subtipo de otra Partida (como es el caso en varias modalidades de la presente invención, en donde todas las Partidas son derivadas de una sola Partida y Tipo de Partida en el Esquema Básico), cualquier información de subtipo aplicable (es decir, la información que pertenece al Tipo de Partida de origen). Si la Partida original que está siendo copiada es un subtipo de otra Partida, la copia también puede ser un subtipo de esa misma Partida. • Las propiedades y extensiones del tipo complejo de las Partidas, si la hay. Si la Partida original tiene propiedades de tipos complejos (naturales o extendidas), la copia también puede tener los mismos tipos complejos. • Los registros de Partidas en las "relaciones de propiedad", es decir, la propia lista de la Partida de cualesquiera otras Partidas (las "Partidas Objetivo") son poseídas por la Partida actual (la "Partida Propietaria"). Esto es particularmente importante con respecto a las Carpetas de Partidas, que se explicarán con mayor detalle más adelante, y la regla manifestada más adelante de que todas las Partidas deben de pertenecer a por lo menos una Carpeta de Partidas. Además, con respecto a las Partidas incrustadas - que se describen más completamente más adelante - una Partida incrustada es considerada como que es parte de la Partida en la cual es incrustada para operaciones tales como copiar, eliminar y similares. 2. Identificación de Partidas Las Partidas son identificadas de manera única dentro del espacio de partidas globales con un ItemID. El tipo Base. Item define un campo ItemID del tipo GUID que almacena la identidad de la Partida. Una Partida debe de tener exactamente una identidad en el almacén de datos 302.

Una referencia de las partidas en una estructura de datos que contiene información para localizar e identificar una Partida. En el modelo de datos, se define un tipo abstracto denominado del cual se derivan todos los tipos de Partida de Referencia. El tipo ItemReference define un método virtual denominado Resolver. El método Resolver resuelve la ItemReference y regresa una Partida. Este método es pasado por alto por los subtipos concretos del ItemReference, el cual implementa una función que recupera una Partida proporcionada como una referencia. El método Resolver es invocado como parte de la plataforma de almacenamiento API 322. El ItemIDReference es un subtipo de la ItemReference. Define un Localizador y un campo de ItemID. El campo de Localizador denomina (es decir, identifica) un campo de partida. Esto es procesado por un método de resolución del localizador que puede resolver el valor de Localizador para un campo de partida. El campo ItemID es un tipo de ItemID. El ItemPathReference es una especialización del ItemReference que define un Localizador, y un campo de Trayectoria. El campo Localizador identifica un campo de partida. Es procesado por un método de resolución de localizador que puede resolver el valor de Localizador para un campo de partida. El campo de Trayectoria contiene una trayectoria (relativa) en el nombre del espacio de la plataforma de almacenamiento que se encuentra en la raíz de un campo de partida proporcionada por el Localizador. Este tipo de referencia no puede ser utilizado en una operación de ajuste. La referencia debe ser solucionada generalmente a través de un proceso de resolución de trayectoria. El método Resolver de la plataforma de almacenamiento AP1322 proporciona esta funcionalidad. Las formas de referencia explicadas anteriormente son representadas a través de la jerarquía del tipo de referencia ilustrada en la figura 11. Los tipos adicionales de referencia que se heredan de estos tipos pueden ser definidos en los esquemas. Ellos pueden ser utilizados en una declaración de relación como el tipo del campo objetivo. 3. Carpetas de Partidas y Categorías Como se explicará con mayor detalle más adelante, los grupos de Partidas pueden ser organizados en Partidas especiales denominadas Carpetas de Partidas (los que no deberán ser confundidos con las carpetas de archivos). A diferencia de la mayor parte de los sistemas de archivo, sin embargo, una Partida puede pertenecer a más de una Carpeta de Partidas, de modo que cuando una Partida es accedida en una Carpeta de Partida y revisada, a esta Partida revisada se puede tener acceso directamente desde otra Carpeta de Partidas. En esencia, aunque el acceso a una Partida puede ocurrir de diferentes Carpetas de Partidas, a lo que realmente se está teniendo acceso es en efecto a la misma Partida. Sin embargo, la Carpeta de Partidas no necesariamente posee todos sus Partidas miembros, o puede simplemente co-poseer Partidas en conjunto con otras carpetas, de modo que la eliminación de una Carpeta de Partidas no resulte necesariamente en la eliminación de una Partida. No obstante, en varias modalidades de la presente invención, una Partida debe de pertenecer por lo menos a una Carpeta de Partidas de modo que si la Carpeta de Partidas sola para una Partida particular es eliminada entonces, para algunas modalidades, la Partida es eliminada automáticamente o, en modalidades alternativas, la Partida llega a ser automáticamente un miembro de una Carpeta de Partidas por omisión (default) (es decir, una Carpeta de Partidas se "Puede Eliminar" de una manera conceptualmente similar a las carpetas nombradas de un modo similar utilizadas en diferentes sistemas basados en archivos y carpetas). Como también se explicará con mayor detalle más adelante, las Partidas también deben pertenecer a Categorías basadas en las características comunes descritas, tales como (a) un Tipo de Partida (o Tipos), (b) una propiedad específica inmediata o heredada (o propiedades), o (c) un valor específico (o valores) correspondiente a una propiedad de Partida. Por ejemplo, una Partida que comprende propiedades específicas para información de contacto personal podría pertenecer automáticamente a una Categoría de Contacto y cualquier Partida que tiene propiedades de información de contacto, de un modo similar pertenecería automáticamente a esta Categoría. De un modo similar, cualquier Partida que tiene una propiedad de localización con un valor de "Ciudad New York", podría pertenecer automáticamente a la Categoría NewYorkCity. Las Categorías son conceptualmente diferentes de las Carpetas de Partidas debido a que, mientras las Carpetas de Partidas puede comprender Partidas que no están interrelacionadas (es decir, sin características comunes descritas), cada Partida de una Categoría tiene un tipo, propiedad o valor común (una "similitud") que se describe para esa Categoría, y esta similitud que forma la base para su relación con y entre las otras Partidas de la Categoría. Además, mientras una membresía de Paridas en una Carpeta particular no es obligatoria basada en cualquier aspecto particular de esa Partida, para ciertas modalidades, todas las Partidas que tienen una similitud relacionada categóricamente con una Categoría podrían llegar a ser automáticamente un miembro de la Categoría en el nivel del sistema de la interfase de hardware/software. Conceptualmente, las Categorías también se puede considerar que son Carpetas de Partidas virtuales cuya membresía está basada en los resultados de una solicitud específica (tales como en el contexto de una base de datos) y las Partidas que cumplen con estas condiciones de esta solicitud (definidas por las similitudes de la Categoría) comprenderían de este modo una membresía de Categoría. La figura 4 ilustra la relación estructural entre las Partidas, Carpetas de Partidas y Categorías. Una pluralidad de Partidas 402, 404, 406, 408, 410, 412, 414, 416, 418 y 420 son miembros de varias Carpetas de Partidas 422, 424, 426, 428 y 430. Algunas Partidas pueden pertenecer a más de una Carpeta de Partidas, es decir, la Partida 402 pertenece a las Carpetas de Partidas 422 y 424. Algunas Partidas, por ejemplo, las Partidas 402, 404, 406, 408, 410 y 412 también son miembros de una o más Categorías 432, 434 y 436, mientras que otras veces, por ejemplo, las Partidas 414, 416, 418 y 420 pueden pertenecer a ninguna Categoría (aunque esto es altamente improbable en ciertas modalidades en donde la posesión de cualquier propiedad implica automáticamente la membresía en una Categoría, y por lo tanto, una Partida tendría que ser completamente sin características con el objeto de que no fuera un miembro de cualquier categoría en dicha modalidad). En contraste con la estructura jerárquica de las carpetas, tanto las Categorías como las Carpetas de Partidas tienen estructuras similares para las gráficas dirigidas, tal y como aquí se mostró. En cualquier caso, las Partidas, Carpetas de Partidas y Categorías son todas Partidas (independientemente de los Tipos de Partidas diferentes). En contraste con los archivos, carpetas y directorios, las Partidas, Carpetas de Partidas y Categorías de la presente invención, no son de naturaleza característicamente "física" debido a que no tienen los equivalentes conceptuales de los contenedores físicos, y por lo tanto, pueden existir Partidas en más de una de dichas localizaciones. La capacidad de que las Partidas existan en más de una localización de Carpeta de Partidas, así como de que estén siendo organizadas en Categorías proporciona un grado mejorado y enriquecido de la manipulación de datos y las capacidades de estructura de almacenamiento en nivel de ¡nterfase de hardware/software, más allá del que está actualmente disponible en la técnica. 4. Esquemas a) Esquema Básico Para proporcionar el principio universal para la creación y uso de las Partidas, varias modalidades de la plataforma de almacenamiento de la presente invención comprenden un Esquema Básico que establece un sistema conceptual para crear y organizar Partidas y propiedades. El Esquema Básico define ciertos tipos especiales de Partidas y propiedades y las características de estos tipos fundamentales especiales de los cuales se pueden derivar adicionalmente los subtipos. El sistema de este Esquema Básico permite que un programador distinga de manera conceptual las Partidas (o sus tipos respectivos) de las propiedades (y sus tipos respectivos). Además, el Esquema Básico establece los cimientos del conjunto de propiedades que pueden poseer como todas las Partidas (y su Tipo de Partida correspondiente) son derivados de esta Partida fundamental en el Esquema Básico (o su Tipo de Partida correspondiente). Tal y como se ilustra en la figura 7 y con respecto a varias modalidades de la presente invención, el Esquema Básico define tres tipos de nivel superior; Partida, Extensión y Base de Propiedad. Tal y como se muestra, el Tipo de Partida es definido por las propiedades de este Tipo de Partida "Partida" fundamental. En contraste, la propiedad del tipo del nivel superior "PropertyBase" no tiene propiedades previamente definidas, y es únicamente el ancla desde la cual todos los tipos de propiedades son derivados y a través de los cuales todos los tipos de propiedad derivados están interrelacionados (siendo derivados comúnmente de un solo tipo de propiedad). El tipo de propiedades de Extensión, define que Partida comprende las extensiones así como la identificación para distinguir una extensión de la otra, ya que una Partida puede tener extensiones múltiples. La ItemFolder es un subtipo del tipo de Partida que, además de las propiedades heredadas de la Partida, las caracteriza una Relación para establecer los enlaces para sus miembros (si lo hay), mientras que IdentityKey y Property son subtipos del PropertyBase. La CategoryRef, a la vez, es un subtipo de IdentityKey. b) Esquema del Núcleo Varias modalidades de la plataforma de almacenamiento de la presente invención comprenden además un Esquema del Núcleo que proporciona un sistema conceptual para el tipo de Partidas de nivel superior. La figura 8A es un diagrama de bloques que ilustra las Partidas en el Esquema del Núcleo, y la figura 8B es un diagrama de bloques que ilustra los tipos de propiedades en el Esquema del Núcleo. La distinción hecha entre los archivos con extensiones diferentes (*.com, *.exe, *.bat, *.sys, etc.). y otros de dichos criterios en los sistemas basados en carpetas y archivos son análogos a la función del Esquema del Núcleo. En el sistema de interfase de hardware/software basado en las Partidas, el Esquema del Núcleo define un conjunto de tipos de Partidas del núcleo que, directamente (por Tipo de Partida) o indirectamente (por subtipo de Partida), caracterizan todas las Partidas en uno o más tipos de Partidas de Esquema del Núcleo los cuales entiende el sistema de interfase de hardware/software basado en las Partidas y puede procesar directamente de una manera previamente determinada y que se puede pronosticar. Los tipos de Partida previamente determinados reflejan las Partidas más comunes en el sistema de interfase de hardware/software basado en las Partidas y por lo tanto, se gana un nivel de eficacia por parte del entendimiento del sistema de interfase del hardware/software basado en las Partidas de estos tipos de Partida previamente definidos que comprenden el Esquema del Núcleo. En ciertas modalidades, el Esquema del Núcleo no se puede extender - es decir, no pueden sub-tipificarse tipos adicionales de Partidas directamente del tipo de Partida en el Esquema Básico, excepto por los tipos específicos de Partidas derivados previamente definidos que son parte del Esquema del Núcleo. Evitando las extensiones al Esquema del Núcleo (es decir, evitando la adición de nuevas Partidas al Esquema del Núcleo), la plataforma de almacenamiento comanda el uso de los tipos de Partida del Esquema del Núcleo, ya que cada tipo de Partida subsecuente es necesariamente un subtipo del tipo de Partida del Esquema del Núcleo. Esta estructura hace posible un grado razonable de flexibilidad para definir los tipos de Partida adicionales mientras también conserva los beneficios de tener un conjunto previamente determinado de tipos de Partida del núcleo. Para diferentes modalidades de la presente invención, y haciendo referencia a la figura 8A, los tipos de Partida específicos soportados por el Esquema del Núcleo pueden incluir uno o más de los siguientes: • Categorías: Partidas de este Tipo de Partida (y los subtipos derivados del mismo) representan Categorías válidas en el sistema de interfase de hardware/software basado en las Partidas. • Productos Básicos: Partidas que son cosas de valor que se pueden identificar. • Dispositivos: Partidas que tienen una estructura lógica que soporta las capacidades de procesamiento de información.

• Documentos: Partidas con un contenido que no es interpretado por el sistema de interfase de hardware/software basado en las Partidas, pero en vez de ello es interpretado por un programa de aplicación correspondiente al tipo de documento. • Eventos: Partidas que registran ciertas ocurrencias en el entorno. • Localizaciones: Partidas que representan localizaciones físicas (por ejemplo, localizaciones geográficas). • Mensajes: Partidas de comunicación entre dos o más principales (definidos más adelante). • Principales: Partidas que tienen por lo menos una identidad definitivamente probable aparte de cualquier Itemld (es decir, la identificación de una persona, organización, grupo, posesión, autoridad, servicio, etc.). • Manifestaciones: Partidas que tienen información especial con respecto al entorno que incluye, sin limitación, políticas, subscripciones, credenciales, y así sucesivamente. De un modo similar y haciendo referencia a la figura 8B, los tipos de propiedad específicos soportados por el Esquema del Núcleo pueden incluir uno o más de los siguientes: • Certificados (derivados del tipo PropertyBase fundamental en el Esquema Básico) • Claves de Identidad del Principal (derivadas del tipo IdentityKey en el Esquema Básico) • Dirección Postal (derivada del tipo de Propiedad en el Esquema Básico) • Texto Rico (derivada del tipo de Propiedad en el Esquema Básico) • Dirección Electrónica EAddress (derivada del tipo de Propiedad en el Esquema Básico) • IdentitySecurityPackage (derivada del tipo de Relación en el Esquema Básico) • RoleOccupancy (derivada del tipo de Relación en el Esquema Básico) • BasicPresence (derivada del tipo de Relación en el Esquema Básico) Estas Partidas y Propiedades se describen adicionalmente por sus propiedades respectivas establecidas en las figuras 8A y 8B. 5. Relaciones Las relaciones son relaciones binarias en donde una Partida es designada como la fuente y la otra Partida como el objetivo. La Partida fuente y la Partida objetivo están relacionadas por la relación. La Partida fuente generalmente controla el tiempo de vida de la relación. Es decir, cuando la Partida fuente es eliminada, la relación entre las Partidas también es eliminada. Las relaciones se clasifican en: Relaciones de Contenido y Referencia. Las relaciones de contenido controlan el tiempo de vida de las Partidas objetivo, mientras que las relaciones de referencia no proporcionan semánticas de administración del tiempo de vida algunas. La figura 12 ilustra la manera en la cual son clasificadas las relaciones. Los tipos de relación de Contenido son clasificados adicionalmente, en relaciones de Posesión e Incrustación. Cuando todas las relaciones de posesión para una Partida son eliminadas, la Partida es eliminada. La relación de posesión controla el tiempo de vida del objetivo a través del mecanismo de cuenta de referencia. Las relaciones de incrustación hacen posible diseñar las Partidas de compuestos y se puede considerar que son como de relaciones de posesión exclusivas. Una Partida puede ser un objetivo de una o más de las relaciones de posesión, pero una Partida puede ser el objetivo de exactamente una relación de incrustación. Una Partida que es un objetivo de una relación de incrustación no puede ser un objetivo de cualquier otra relación de posesión o incrustación. Las relaciones de referencia no controlan el tiempo de vida de las Partidas objetivo. Ellas pueden estar colgando -la Partida objetivo puede no existir. Las relaciones de referencia pueden ser utilizadas para diseñar referencias en las Partidas en cualquier parte en el espacio de nombre de la Partida global (por ejemplo, incluyendo almacenes de datos remotos). La recuperación de una Partida no recupera automáticamente sus relaciones. Las aplicaciones deben de solicitar explícitamente las relaciones de una Partida. Además, la modificación de una relación no modifica la Partida fuente o el objetivo, de un modo similar, agregar una relación no afecta la Partida fuente/objetivo, a) Declaración de Relación Los tipos de relación explícitos se definen con los siguientes elementos: • Un nombre de relación se específica en el atributo de Nombre. • Tipo de relación, uno de los siguientes: Posesión, Incrustación, Referencia. Éste es especificado en el atributo del Tipo. • Puntos finales de fuente y objetivo. Cada punto final específica un nombre y el tipo de la Partida de referencia. • Campo de punto final de fuente, es generalmente la ItemID del tipo (no declarado), y debe hacer referencia a una Partida en el mismo almacén de datos como el objeto específico de la relación. • Para las relaciones de Posesión e Incrustación, el campo de punto final del objetivo debe de ser del tipo ItemlDReference y debe ser al que nos debemos referir como una Partida en el mismo almacén que la del objeto específico de la relación. Para las relaciones de Referencia el punto final del objetivo puede ser del tipo ItemReference y puede hacer referencia a las Partidas en otros almacenes de datos de la plataforma de almacenamiento. • Opcionalmente, pueden ser declarados uno o más campos del tipo de escala o PropertyBase. Estos campos pueden contener datos asociados con la relación. • Los objetos específicos de la relación son almacenados en la tabla global de relaciones. • Cada objeto específico de la relación es identificado de manera exclusiva por la combinación (ItemID, ID de la relación). La ID de la relación es única dentro de un ItemID fuente determinado para todas las relaciones de la fuente en una Partida determinada independientemente de su tipo. La Partida fuente es la propietaria de la relación. Aunque una Partida designada como propietaria controla el tiempo de vida de la relación, la relación misma es separada de las Partidas con las que se relaciona. La plataforma de almacenamiento API 322 proporciona mecanismos para exponer relaciones asociadas con una Partida. Aquí se encuentra un ejemplo de una declaración de relación: <Nombre de la Relación ="Employment" B a seType = " Refere nce"> <Nombre de Fuente = "Employee" ltemType="Contact.Person"/> <Nombre del Objetivo= "Employer"ltemType="Contact.Organization" Tipo de Referencia = "ltemlDReference"/> <Nombre de la Propiedad = "StartDate" Type = "los Types.DateTime plataforma de almacenamiento'7> <Nombre de la Propiedad="EndDate" Type="los Types.DateTime plataforma de almacenamiento"/> <Nombre de la Propiedad ="Office" Type = "los Types.DateTime plataforma de almacenamiento'7> </Relación> Este es un ejemplo de una relación de Referencia. La relación no puede ser creada si la Partida de la persona a la que se hace referencia por la referencia fuente no existe. También, si la Partida de persona es eliminada, los objetos específicos de relación entre la persona y la organización son eliminados. Sin embargo, si la Partida Organización es eliminada, la relación no es eliminada y está colgando. b) Relación de Posesión Las relaciones de posesión son utilizadas para diseñar la cuenta de referencia basadas en la administración del tiempo de vida de las Partidas objetivo. Una Partida puede ser un punto final fuente para cero o más relaciones para las Partidas. Una Partida que no es una Partida incrustada puede ser un objetivo si sostiene una o más relaciones. El tipo de referencia del tipo final objetivo debe de ser ItemlDReference y debe hacer referencia a una Partida en el mismo almacén que el objeto específico de la relación. Las relaciones de posesión deben poner en vigor la administración del tiempo de vida del punto final objetivo. La creación de la relación de posesión y la Partida que es el objetivo es una operación atómica. Los objetos específicos adicionales de relaciones de posesión pueden ser creados de modo que se dirijan al objetivo de la misma Partida. Cuando es eliminado el último objeto específico de la relación de posesión con una Partida denominada como punto final objetivo, la Partida objetivo también es eliminada. Los tipos de Partidas del punto final especificadas en la declaración de relación generalmente se pondrán en vigor cuando es creado un objeto específico de la relación. Los tipos de las Partidas de punto final no pueden ser cambiados después de que es establecida la relación.

Las relaciones de posesión juegan un papel clave para formar el espacio de nombre de la Partida. Ellos contienen la propiedad "Nombre" que define el nombre de la Partida ^objetivo relacionada con la Partida fuente. Este nombre relativo es único para todas las relaciones de posesión que son originadas de una Partida determinada. La lista ordenada de estos nombres relativos que inicia desde la Partida raíz hasta una Partida determinada, forman el nombre completo de la Partida. Las relaciones de posesión forman un gráfico acíclico dirigido (DAG). Cuando una relación de posesión es creada, el sistema se asegura de que no se ha creado un ciclo, asegurando de este modo, que el espacio de nombre de la Partida forme un DAG. Aunque la relación de posesión controla el tiempo de vida de la Partida objetivo, no controla la consistencia de operación de la Partida objetivo de punto final. La Partida objetivo es independiente operacionalmente de la Partida que la posee a través de una relación de posesión. Las operaciones de Copiar, Mover, Respaldar y otras en una Partida que es una fuente de una relación de posesión no afectan la Partida que es un objetivo de la misma relación - por ejemplo, es decir, el respaldo de una Partida de Carpeta no respalda automáticamente todas las Partidas de la carpeta (los objetivos de la relación FolderMember).

El siguiente es un ejemplo de la relación de posesión: <Nombre de la Relación = "FolderMembers" BaseType = "Holding"> <Nombre de la Fuente ="Folder" ltemType = "Base.Folder'7> <Nombre del Objetivo ="ltem" ltemType = "Base. Item" Tipo de Referencia ="ltem I DReference"/> </Relación> La relación de FolderMembers hace posible el concepto de una Carpeta como una colección genérica de Partidas, c) Relaciones de Incrustación Las relaciones de incrustación diseñan el concepto del control exclusivo del tiempo de vida de una Partida objetivo. Ellas hacen posible el concepto de las Partidas compuestas. La creación de una relación de incrustación y la Partida que es un objetivo es una operación atómica. Una Partida puede originarse de cero o más relaciones de incrustación. Sin embargo, una Partida puede ser un objetivo de una y solamente una relación de incrustación. Una Partida que es un objetivo de una relación de incrustación no puede ser un objetivo de una relación de posesión. El tipo de referencia de punto final del objetivo debe de ser ItemIDReference y debe de hacer referencia a una Partida del mismo almacén de datos que un objeto específico de la relación.

Los tipos de Partidas de punto final especificados en la declaración de relación generalmente se pondrán en vigor, cuando se crea un objeto específico de la relación. Los tipos de Partidas de punto final no pueden ser cambiados después de que es establecida la relación. Las relaciones de incrustación controlan la consistencia de operación del punto final objetivo. Por ejemplo, la operación de señalización de una partida puede incluir la serialización de todas las relaciones de incrustación que se originan de esa Partida, así como todos sus objetivos; copiando una Partida también se copian todas las Partidas incrustadas. La siguiente es una declaración de ejemplo: <Nombre de la Relación ="ArchiveMembers" BaseType="Embedding"> <Nombre de la Fuente ="Archive" ltemType="Zip.Archive"/> <Nombre del Objetivo ="Member" ltemType = "Base. Item" Tipo de Referencia = "ltemlDReference"/> <Nombre de la Propiedad ="ZipSize" Type="los Types.bigint de la plataforma de almacenamiento"/> <Nombre de Propiedad ="SizeReduction" Type="los Types.float plataforma de almacenamiento"/> </Relación> d) Relaciones de Referencia La relación de referencia no controla el tiempo de vida a la Partida a la que hace referencia. Es más, las relaciones de referencia no garantizan la existencia del objetivo, ni garantizan el tipo del objetivo especificado en la declaración de relación. Esto significa que las relaciones de referencia pueden estar colgando. También, la relación de referencia puede hacer referencia a Partidas de otros almacenes de datos. Se puede considerar que las relaciones de referencia son un concepto similar para los enlaces en las páginas web.

Un ejemplo de una declaración de relación de referencia es el siguiente: <Nombre de la Relación ="DocumentAuthor" BaseType = "Reference"> <Tipo de Partida Fuente ="Document" Tipo de Partida= "Base.Document"/> Tipo de Partida Objetivo ="Author" ltemTy e = "Base.Author" Tipo de Referencia ="ltemlDReference"/> <Tipo de Propiedad ="Role" Type="Core.CategoryRef > <Tipo de Propiedad ="DisplayName" Type = "Types.nvarchar(256)" la plataforma de almacén amiento/> </Relación> Esta permitido cualquier tipo de referencia en el punto final del objetivo. Las Partidas que participan en una relación de referencia pueden ser de cualquier tipo de Partida. Las relaciones de referencia se utilizan para diseñar la mayor parte de las relaciones de administración que no son por el tiempo de vida entre las Partidas. Debido a que la existencia del objetivo no se pone en vigor, la relación de referencia es conveniente para diseñar relaciones acopladas-sueltas. La relación de referencia puede ser utilizada para dirigir al objetivo Partidas en otros almacenes de datos incluyendo almacenes de otras computadoras. e) Reglas y Restricciones Las siguientes reglas y restricciones adicionales son aplicables para las relaciones: Una Partida debe de ser un objetivo (exactamente una relación de incrustación) o más relaciones de posesión). Una excepción es la Partida raíz. Una Partida puede ser un objetivo de cero o más relaciones de referencia. Una Partida que es un objetivo de una relación de incrustación no puede ser la fuente de una relación de posesión. Puede ser una fuente de las relaciones de referencia. Una Partida no puede ser una fuente de relaciones de posesión si es promovida desde el archivo. Ésta puede ser una fuente de relaciones de incrustación y relaciones de referencia.

• Una Partida que es promovida desde un archivo no puede ser un objetivo de una relación de incrustación, f) Ordenamiento de Relaciones En por lo menos una modalidad, la plataforma de almacenamiento de la presente invención soporta el ordenamiento de las relaciones. El ordenamiento es logrado a través de una propiedad denominada "Ordenar" en la definición básica de la relación. No existe restricción de exclusividad en el campo de Ordenamiento. El ordenamiento de las relaciones con el mismo valor de propiedad de "ordenar" no está garantizado, sin embargo, está garantizado que pueden ser ordenadas después de relaciones con valores de "orden" más bajas y antes de relaciones con valores de un campo de "orden" más alto. Las aplicaciones pueden obtener las relaciones en el orden por omisión (default) ordenándolas en la combinación (Sourcelteml D, Relationshipl D, Orden). Todos los objetos específicos de relación originados desde una Partida determinada son ordenados como una colección sencilla independientemente del tipo de relaciones de la colección. Esto sin embargo, garantiza que todas las relaciones de un tipo determinado (por ejemplo, FolderMembers) son un subconjunto ordenado de la colección de relación para una Partida determinada.

La API 312 del almacén de datos para manipular las relaciones implementa un conjunto de operaciones que soportan el ordenamiento de las relaciones. Los siguientes términos son introducidos para ayudar a explicar las operaciones: • RelFirst es la primera relación de la colección ordenada con el valor de orden OrdFirst; • RelLast es la última relación en la colección ordenada con el valor de orden OrdLast; · RelX es una relación determinada en una colección con un valor de orden OrdX; • RelPrev es la relación más cercana en la colección a 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 a RelX con el valor de orden OrdNext mayor que OrdX. Las operaciones incluyen, pero no están limitadas a: • \nsertBeforeFirst (SourceltemID, Relatlonship) inserta la relación como la primera relación de la colección. El valor de la propiedad "Orden" de una nueva relación puede ser más pequeño que OrdFirst. • InsertAfterLast (SourceltemID, Relationship) inserta la relación como la última relación de la colección. El valor de la propiedad "Orden" de la nueva relación puede ser mayor que OrdLast. InsertAt (SourceltemID, ord, Relationship) inserta una relación con el valor especificado para la propiedad "Orden". InsertBefore (SourceltemID, ord, Relationship) inserta la relación antes de la relación con el valor de orden determinado. La nueva relación puede tener asignado un valor de "Orden" que se encuentra entre OrdPrev y ord, no inclusivo. InsertAfter (SourceltemID, ord, Relationship) inserta la relación después de la relación con un valor de orden determinado. La nueva relación puede tener asignado un valor de "Orden" que se encuentra entre ord y OrdNext, no inclusivo. MoveBefore (SourceltemID, ord, RelationshipID) mueve la relación con la ID de relación determinada antes de la relación con un valor de "Orden" especificado. A la relación se le puede asignar un nuevo valor de "Orden" que se encuentra entre OrdPrev y ord, no inclusivo. MoveAfter (SourceltemID, ord, RelationshipID) mueve la relación con la ID de relación determinada después de la relación con un valor de "Orden" especificado. La relación puede tener asignado un nuevo valor de "Orden" que se encuentra entre ord y OrdNext, no inclusivo. Como se mencionó anteriormente, cada Partida debe de ser un miembro de una Carpeta de Partidas. En términos de Relaciones, cada Partida debe de tener una relación con una Carpeta de Partidas. En varias modalidades de la presente invención, ciertas relaciones son representadas por las relaciones existentes entre las Partidas. Como se ha implementado por varias modalidades de la presente invención, una Relación proporciona una relación binaria dirigida que es "extendida" por una Partida (la fuente) a otra Partida (el objetivo). Una Relación es poseída por la Partida fuente (la Partida que la extendió) y por lo tanto, la Relación es eliminada si la fuente es eliminada (es decir, la Relación es eliminada cuando la Partida fuente es eliminada). Además, en ciertos casos específicos, una Relación puede compartir la propiedad de una Partida objetivo (copropiedad), y dicha propiedad se podría reflejar en la propiedad IsOwned (o su equivalente) de la Relación (como se muestra en la figura 7 par el tipo de propiedad de Relación). En estas modalidades, la creación de una nueva Relación IsOwned incrementa automáticamente la cuenta de referencia de la Partida objetivo, y la eliminación de dicha Relación puede disminuir la cuenta de referencia en la Partida objetivo. Para estas modalidades específicas, las Partidas continúan existiendo si tienen una cuenta de referencia mayor de cero, y son borradas automáticamente si y cuando la cuenta alcanza cero. Nuevamente, una Carpeta de Partidas, es una Partida que tiene (o tiene la capacidad de tener) un conjunto de Relaciones con otras Partidas, comprendiendo estas otras Partidas la membresía de la Carpeta de Partidas. Otras implementaciones reales de las Relaciones son posibles y anticipadas por la presente invención, para lograr la funcionalidad aquí descrita. Independientemente de la ¡mplementación actual, una Relación es una colección que se puede seleccionar de un objeto a otro. La capacidad de una Partida para pertenecer a más de una Carpeta de Partidas, así como a una o más Categorías y si estas Partidas, Carpetas y Categorías son públicas o privadas, es determinado por los significados proporcionados a la existencia (o falta de la misma) en una estructura basada en las Partidas. Estas Relaciones lógicas son los significados asignados a un conjunto de Relaciones, independientemente de la ¡mplementación física, la cual es empleada específicamente para lograr la funcionalidad aquí descrita. Las Relaciones lógicas son establecidas entre la Partida y su Carpeta de Partidas o Categorías (y viceversa) porque, en esencia, las Carpetas de Partidas y las Categorías son cada una un tipo especial de Partida. Por consiguiente, las Carpetas de Partidas y Categorías pueden ser accionadas de la misma manera que cualquier otra Partida - copiadas, agregadas a un mensaje de correo electrónico, incrustadas en un documento, y así sucesivamente, sin limitación - y las Carpetas de Partidas y Categorías pueden ser serializadas y des-serializadas (importadas y exportadas) utilizando los mismos mecanismos que para otras Partidas. (Por ejemplo, en el XML todas las Partidas podrían tener un formato de serialización, y este formato es aplicable igualmente a las Carpetas de Partidas, Categorías y Partidas). Las Relaciones anteriormente mencionadas, las cuales representan la relación entre una Partida y su Carpeta de Partidas se pueden extender lógicamente de la Partida a la Carpeta de Partidas, desde la Carpeta de Partidas a la Partida, o ambas. Una Relación que se extiende lógicamente de una Partida a una Carpeta de Partidas indica que la Carpeta de Partidas es pública para esa Partida y comparte su información de membresía con esa Partida; por el contrario, la carencia de una Relación lógica de una Partida a una Carpeta de Partidas indica que la Carpeta de Partidas es privada para esa Partida, y no comparte su información de membresía con esa Partida. De un modo similar, una Relación que se extiende lógicamente de una Carpeta de Partidas a una Partida indica que la Partida es pública y se puede compartir para esa Carpeta de Partidas, mientras que la carencia de una Relación lógica de una Carpeta de Partidas para una Partida indica que la Partida es privada y no se puede compartir. Por consiguiente, cuando una Carpeta de Partidas es exportada a otro sistema, estas son las Partidas "públicas" que son compartidas en el contexto nuevo, y cuando una Partida busca su Carpeta de Partidas para otras Partidas que se pueden compartir, son Carpetas de Partidas "públicas" que proporcionan la Partida con información correspondiente a las Partidas que se pueden compartir que pertenecen a la misma. La figura 9 es un diagrama de bloques que ilustra una Carpeta de Partidas (la cual, nuevamente, es una Partida misma) o sus Partidas miembros y las relaciones que las interconectan entre la Carpetas de Partidas y sus Partidas miembros. La Carpeta de Partidas 900 tiene como miembros una pluralidad de Partidas 902, 904 y 906. La Carpeta de Partidas 900 tiene una Relación 912 de ella misma a la Partida 902 lo cual indica que la Partida 902 es pública y se puede compartir para la Carpeta de Partida 900, sus miembros 904 y 906, y cualesquiera otras Carpetas de Partidas, Categorías o Partidas (no mostradas), que podrían tener acceso a la Carpeta de Partidas 900. Sin embargo, no existe una relación de la Partida 902 con la Carpeta de Partidas 900 la cual indique que la Carpeta de Partidas 900 es privada para la Partida 902, y no comparte su información de membresía con la Partida 902. La Partida 904, por otra parte, no tiene una relación 924 de ella misma con la Carpeta de Partidas 900, lo cual indica que la Carpeta de Partidas 900 es pública y comparte su información de membresía con la Partida 904. Sin embargo, no existe relación entre ai Carpeta de Partidas 900 con la Partida 904, lo cual indica que la Partida 904 es privada y no se puede compartir para la Carpeta de Partida 900, o sus miembros 902 y 906 o cualesquiera otras Carpetas de Partidas, Categorías o Partidas (no mostradas), que podrían tener acceso a la Carpeta de Partidas 900. En contraste con sus relaciones (o carencia de las mismas), con las Partidas 902 y 904, la Carpeta de Partidas 900 tiene una relación 916 de ella misma con la Partida 906 y la Partida 906 tiene una relación 926 de regreso a la Carpeta de Partidas 900, las cuales juntas indican que la Partida 906 es pública y se puede compartir para la Carpeta de Partidas 900, sus miembros 902 y 904, y cualesquiera otras Carpetas de Partidas, Categorías o Partidas (no mostradas), que podrían tener acceso a la Carpeta de Partidas 900, y que la Carpeta de Partidas 900 es pública y comparte su información de membresía con la Partida 906. Como se explicó anteriormente, las Partidas de una Carpeta de Partidas no necesitan compartir una similitud debido a que las Carpetas de Partidas no son "descritas". Las Categorías, por otra parte, se describen por una similitud que es común a todas las Partidas miembro. Por consiguiente, la membresía de una categoría está limitada inherentemente a las Partidas que tienen la similitud descrita y, en ciertas modalidades, todas las Partidas que cubren la descripción de una Categoría se hacen automáticamente miembros de la Categoría. Por lo tanto, mientras las Carpetas de Partidas permiten estructuras de tipo trivial para ser representadas por sus miembros, las Categorías permiten la membresía basada en la similitud definida. Pos supuesto, las descripciones de la Categoría son de naturaleza lógica, y por lo tanto, una Categoría se puede describir por cualquier representación lógica de tipos, propiedades y/o valores. Por ejemplo, la representación lógica para una Categoría puede ser su membresía para comprender las Partidas que tienen de 1 de 2 propiedades o ambas. Si estas propiedades descritas para la Categoría son "A" y "B" , entonces la membresía de las Categorías puede comprender Partidas que tiene las propiedad A pero no la propiedad B, Partidas que tienen la propiedad B pero no la propiedad A y partidas que tiene ambas propiedades A y B. Esta representación lógica de las propiedades es descrita por un operador lógica "OR", en donde el conjunto de miembros descritos por la Categoría son partidas que tienen la propiedad A o la propiedad B. También se puede utilizar comandos lógicos similares (incluyendo limitación "AND", "XOR", y "NOT" solas o en combinación), para describir una Categoría según podrá ser apreciado por aquellos expertos en la técnica. No obstante la distinción entre las Carpetas de Partidas (no descritas) y las Categorías (descritas), la Relación de las Partidas con las Categorías son esencialmente del mismo modo que se describió aquí anteriormente para las Carpetas de Partidas y Partidas 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 una Partida misma) o sus Partidas miembro y las Relaciones que interconectan entre la Categoría y sus Partidas miembro. La Categoría 1000 tiene como miembros una pluralidad de Partidas 1002, 1004, y 1006 y todas ellas comparten alguna combinación de propiedades, valores o tipos comunes 1008 tal y como se describieron (descripción de similitud 1008') por la Categoría 1000. La Categoría 1000 tiene una Relación 1012 ella misma con la Partida 1002, lo cual indica que la Partida 1002 es pública y se puede compartir para la Categoría 1000, sus miembros 1004 1006, y cualesquiera otras Categorías, Carpetas de Partidas o Partidas (no mostradas) que podrían tener acceso a la Categoría 1000. Sin embargo, no existe Relación de la Partida 1002 a la Categoría 1000, lo cual indica que la Categoría 1000 es privada para la Partida 1002 y no comparte su información de membresía con la Partida 1002. La Partida 1004, por otra parte, no tiene una relación 1024 de ella misma con la Categoría 1000, lo cual indica que la Categoría 1000 es pública y comparte su información de membresía con la Partida 1004. Sin embargo, no existe Relación extendida de la Categoría 1000 a la Partida 1004, la cual indique que la Partida 1004 es privada y no se puede compartir para la Categoría 1000, sus otros miembros 1002 y 1006, y cualesquiera otras Categorías, Carpetas de Partidas, o Partidas (no mostradas), que podrían tener acceso a la Categoría 1000. En contraste con sus Relaciones (o carencia de las mismas) con las Partidas 1002 o 1004, la Categoría 1000 tiene una Relación 1016 de ella misma con la Partida 1006, la Partida 1006 tiene una Relación 1026 de vuelta con la Partida 1000, las cuales todas juntas indican que la Partida 1006 es pública y se puede compartir para la Categoría 1000, sus miembros de la Partida1002 y 1004, y cualesquiera otras Categorías, Carpetas de Partidas o Partidas (no mostradas) que podrían 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 la Partida 1006. Finalmente, debido a que las Categorías y las Carpetas de Partidas son ellas mismas Partidas, y las Partidas deben tener relación entre ellas, las Categorías pueden tener relación con las Carpetas de Partidas y viceversa, y las Categorías, Carpetas de Partidas y Partidas pueden tener relación con otras categorías, Carpetas de Partidas y Partidas respectivamente, en ciertas modalidades alternativas. Sin embargo, en varias modalidades, las estructuras de la Carpeta de Partidas y/o las estructuras de Categorías están prohibidas, en el nivel de sistemas de interfase de hardware/software, de los ciclos que la contienen, en donde las estructuras de la Carpeta de Partidas y las Categorías son similares hacia gráficos dirigidos, las modalidades que prohiben los ciclos son similares para los gráficos acíciicos dirigidos (DAGs) las cuales pueden ser una definición matemática en la técnica de la teoría de gráficos y son gráficos dirigidos en donde ninguna trayectoria inicia y termina en el mismo vértice. 6.- Capacidad de Extensión La plataforma de almacenamiento pretende estar provista con un conjunto inicial de esquemas 340, tal y como se describieron anteriormente. Sin embargo, además en por lo menos algunas de las modalidades, la plataforma de almacenamiento permite clientes, incluyendo proveedores de software independientes (ISVs), para crear nuevos esquemas 344 (por ejemplo, tipos nuevos de partidas y elementos anidados). Esta sección se refiere a un mecanismo para crear dichos esquemas extendiendo los tipos de Partidas y los tipos de Elementos Anidados (o simplemente tipos de "elementos") definidos por el conjunto inicial de esquemas 340. De preferencia, la extensión del conjunto inicial de tipos de Partidas y Elementos Anidados está restringida de la manera siguiente: · Se permite que un ISV introduzca nuevos tipos de Partidas, es decir, el subtipo Base. Item; • Un ISV tiene permitido introducir nuevos tipos de Elementos Anidados, es decir, el subtipo Base.NestedElement; · Se permite que un ISV introduzca nuevas extensiones, por ejemplo, el subtipo Base.NestedElement; pero, • El ISV no puede formar subtipos de cualesquiera tipos (Partidas, Elementos Anidados o tipos de Extensión) definidos por el conjunto inicial de los esquemas de la plataforma de almacenamiento 340. Debido a que el tipo de Partida, o el tipo de Elemento Anidado definido por el conjunto inicial de esquemas de la plataforma de almacenamiento puede no coincidir exactamente con la necesidad de la aplicación ISV, es necesario permitir que los ISVs personalicen el tipo. Esto es permitido con la noción de las extensiones. Las extensiones son objetos específicos altamente tipificados pero (a) no pueden existir independientemente (b) deben de ser adheridos a una Partida o un Elemento Anidado. Además de solucionar la necesidad de la capacidad de extensión de los esquemas, las extensiones también pretenden solucionar los problemas de "tipificación múltiple". Como en algunas modalidades, la plataforma de almacenamiento no puede soportar la herencia múltiple, o sus subtipos que se traslapan, las aplicaciones pueden utilizar extensiones como un medio para diseñar objetos específicos de tipos que se traslapan (es decir, el documento es un documento legal y también es un documento seguro). Extensiones de Partidas Para proporcionar la capacidad extensión de las Partidas, el modelo de datos define además, un tipo abstracto denominado Base. Extensión. Este es un tipo raíz para la jerarquía de los tipos de extensión. Las aplicaciones pueden tener el subtipo Base. Extensión para crear tipos de extensión específicos. El tipo Base. Extensión es definido por el esquema básico de la manera siguiente: <Nombre del tipo =Base.Extension"lsAbstract="True"> <Nombre de la propiedad = ItemID", tipo= tipos uniqueidentified de la plataforma de almacenamiento Que se pueden anular false de valores múltiples = "false Nombre de la propiedad = "ExtensionID Tipo = "Types.uniqueidentified de la plataforma de Almacenamiento" Que se puede anular ="false" Multivalued == "false" </Tipo> El campo ItemID contiene la identificación de la partida a la que está asociada la extensión. Debe existir una Partida con este ItemID. La extensión no puede ser creada si no existe la Partida con el ItemID determinado. Cuando la Partida es eliminada todas las extensiones con el mismo ItemID son eliminadas. El registro (ItemID, ExtensionID) identifica de manera exclusiva un objeto específico de extensión. La estructura de algún tipo de extensión es similar al de un tipo de partida: • Los tipos de extensión tienes campos; • Los campos pueden ser de tipos primitivos o de tipos de elementos anidados; y • Los tipos de extensión pueden ser sub-tipificados. Las restricciones siguientes son aplicables para los tipos de extensión. • Las extensiones no pueden ser fuentes y objetivos de relaciones; • Los objetos específicos del tipo de extensión no pueden existir independientemente de una partida; y • Los tipos de extensión no pueden ser utilizados como tipos de campo en las definiciones del tipo de plataforma de almacenamiento. No existen restricciones sobre los tipos de extensiones que pueden estar asociados con un tipo de Partida determinado. Se permita cualquier tipo de extensión para que se extienda a cualquier tipo de partida. Cuando son adheridos objetos específicos de extensión múltiples a una Partida, son independientes entre ellos, tanto en la estructura como en su comportamiento. Los objetos específicos de extensión son almacenados y se tiene acceso a ellos por separado desde la partida. Todos los objetos específicos del tipo de extensión son accesibles desde la visión de extensión global. Se puede componer una solicitud eficiente, de modo que regresará todos los objetos específicos de un tipo determinado de extensión independientemente de que tipo de partida que está asociada con ellos. Las APIs de la plataforma de almacenamiento proporcionan un modelo de la programación que puede almacenar, recuperar y modificar las extensiones en las partidas. Los tipos de extensión pueden ser un tipo sub-tipificado que utiliza un modelo de herencia única de la plataforma de almacenamiento. Derivándolo del tipo de extensión se crea un nuevo tipo de extensión. La estructura o el comportamiento de una extensión no puede pasar por alto o reemplazar la estructura o comportamiento de la jerarquía del tipo de partida. Similares a los tipos de Partidas, los objetos específicos del tipo de Extensión pueden ser exhibidos directamente a través de la visión asociada con el tipo de extensión. La ItemID de la extensión indica a que partida pertenece y puede ser utilizada para recuperar el objeto de Partida correspondiente de la visión de Partida, las extensiones se consideran parte de la partida para propósitos de la consistencia de operación. Los comandos Copy/Move, Backup/Restore y otras operaciones comunes que definen la plataforma de almacenamiento pueden operar en las extensiones como parte de la partida. Considerar el ejemplo siguiente. Un tipo de contacto es definido en el conjunto del tipo Windows. <Nombre de tipo ="Contact"BaseType="Base. Item"> <Nombre de la propiedad ="Name" Tipo = :"String Se puede anular = "false"/> MultiValued = "false"/>, <Nombre de la propiedad ="Address Tipo = "Address Se puede anula r="true » MultiValued ="false"/> </Tipo> A un desarrollador de una aplicación CRM le gustaría adjuntar extensiones de aplicación CRM a los contactos almacenados en la plataforma de almacenamiento. El desarrollador de la aplicación definiría una extensión CRM que contendría una estructura de datos adicionales que pueden manipular la aplicación. < Nombre del Tipo = "CRMExtension"BaseType = "Base.Extension"> <Nombre de la propiedad ="CusomerlD" Tipo ="String" Se puede anula r= "false" MultiValued = "false"/> </Tipo> Un desarrollador de una aplicación HR puede querer también adjuntar datos adicionales con el contacto. Estos datos son independientes de los datos de la aplicación CRM. Nuevamente el desarrollador de la aplicación puede crear una extensión. <Nombre del Tipo = HRExtension"EBaseTYPE = "Base.Extension"> <Nombre de la Propiedad = "EmployeeID" Tipo ="String" Se puede anular ="false" MultiValued ="false'7> </Tipo> Las extensiones CRMExtension y HRExtension son dos extensiones independientes que pueden ser adjuntadas a las partidas de Contactos. Éstas son creadas y se tiene acceso a ellas de manera independiente entre ellas. En el ejemplo anterior, los campos y métodos del tipo CRMExtension no pueden pasar por alto los campos o métodos de la jerarquía de Contacto. Deberá observarse que los objetos específicos del tipo de extensión CRMExtension pueden ser adjuntados a los tipos de Partida, en vez de los Contactos. Cuando la partida de Contacto es recuperada, sus extensiones de partida no son recuperadas automáticamente. Debido a que una partida de Contacto está relacionada con extensiones de partidas a las que se pueden tener acceso solicitando la visión de extensión global para las extensiones con la misma ItemID. Todas las extensiones CRMExtension en el sistema pueden ser exhibidas a través de la visión de tipo CRMExtension, independientemente de a que partida pertenecen. Todas las extensiones de partida de una partida comparten la misma ID de la partida. En el ejemplo anterior, el objeto específico de la partida de Contacto y los objetos específicos de Extensiones adjuntos, tienen la misma CRMExtension y HRExtension Itemld La sig u iente es u na ta bl a q ue resu me l as si militudes y diferencias entre los tipos de Partida, Extensión y N ested Element: Pa rtidas vs Extensión de Partida vs N ested Element Partida Extensión de Partida Elemento Anidado ID de la partida Tiene su propia id Comparte la Id de la No tiene su propia id de de la partida partida partida. El elemento anidado es parte de la partida Almacenamiento La jerarquía de la La jerarquía de la Almacenado con la partida es extensión de la partida es partida almacenada en almacenada en sus sus propias tablas propias tablas Solicitud /Búsqueda Puede solicitar las Puede solicitar tablas de Puede ser generalmente tablas de la partida extensión de las partidas solicitado solamente dentro del contexto que contiene la partida Alcance Puede buscar en Puede buscar en todos Puede ser buscada Solicitud/Búsqueda todos los casos de los objetos específicos de generalmente dentro de un tipo de partida un tipo de extensión de los objetos específicos partida del tipo de elemento anidado de una sola partida (que la contiene) Semántica de relación Puede tener Sin relaciones con las No hay relaciones con relaciones con las extensiones de la partida los elementos anidados partidas Asociación con las Puede estar Generalmente solo puede Está relacionado con los partidas relacionada con estar relacionada por campos por medio de la otras partidas por medio de las partida. Los elementos medio de las extensiones. La anidados son parte de la relaciones de semántica de la partida posesión, extensión es similar a la incrustadas y semántica de la partida temporales incrustada b) Extensión de los tipos NestedElement Los tipos NestedElement no son extendidos con el mismo mecanismo que los tipos de Partidas. Las Extensiones de los Elementos Anidados son almacenadas y se tiene acceso a ellos con los mismos mecanismos que los campos de los tipos Elementos Anidados. El modelo de datos define una raíz para los tipos de elementos Anidados denominada Elemento: <Nombre del tipo ="Element" IsAbstract ="True"> <Nombre de la propiedad = "ElementlD" Tipo ="Types.uniqueidentifier plataforma de almacenamiento" Se puede anular = "false" MultiValued ="false"/> </Tipo> El tipo NestedElement se hereda de este tipo. El NestedElement adicionalmente define un campo que es un conjunto múltiple de Elementos. <Nombre del tipo = "NestedElement"BaseType = "Base.Element IsAbstract = "True"> <Nombre de la propiedad ="Extensions" Tipo= "Base.Element" Se puede anular = "false" MultiValued ="true'7> </Tipo Las extensiones del NestedElement son diferentes de las extensiones de las partidas de las siguientes maneras: • Las extensiones del elemento anidado no son tipos extensión. No pertenecen a la jerarquía del tipo de extensión que se encuentra enraizada en el tipo Base. Extensión. • Las extensiones de Elemento Anidado son almacenadas junto con los otros campos de la partida y no se puede tener acceso a ellas de manera global - no se puede componer una solicitud que recupere todos los objetos específicos de un tipo de extensión determinado. • Estas extensiones son almacenadas de la misma manera que los otros elementos anidados (de la partida) que son almacenados. Igual que con otros conjuntos anidados, las extensiones NestedElement son almacenadas en un UDT. Ahí ya se puede tener acceso a través del campo de Extensiones del tipo de elemento anidado. • Las interfases de recolección utilizadas para tener acceso a propiedades de valores múltiples también son utilizadas para tener acceso e interactuar sobre el conjunto del tipo de extensiones.

La tabl a siguiente resu me y com pa ra las extensi ones I tem Extensi o ns a nd Nested E iement. Extensiones d e Pa rtidas vs Extensiones de N ested Eiement.

Extensión de la Partida Extensión de Elementos Anidados Almacenamiento La jerarquía de la extensión de Almacenados como elementos la partida es almacenada en anidados sus propias tablas Solicitud/Búsqueda Puede solicitar las tablas de Generalmente solamente puede extensión de la partida ser solicitada dentro del contexto de la partida que lo contiene Alcance/Solicitud Puede buscar en todos los Generalmente solamente puede búsqueda objetos específicos de un tipo ser buscado dentro de los objetos de extensión de partida específicos del elemento anidado de una sola partida (que las contiene) Capacidad de Necesita APIs especiales de Las extensiones de elementos programación extensión y la solicitud anidados son como cualquier otro especial en las tablas de campo multlvaluado de los extensión elementos anidados; se utilizan APIs del tipo de elemento anidado Comportamiento Puede asociar el No se permite comportamiento (?) comportamiento Semánticas de relación No tiene Relación con las No existe Relación con las extensiones de las partidas extensiones de los elementos anidados ID de la Partida Comparte la id de la partida No tiene su propio id de la partida. Los elementos anidados son parte de la partida D . MÁQU I NA DE BASE DE DATOS Tal y como se mencionó anteriormente, el almacén de datos es implementado en una máquina de base de datos. En la presente modalidad, la máquina de base de datos comprende una máquina de base de datos de relación que implementa un lenguaje de solicitud SQL, tal como la máquina del servidor Microsoft SQL, con extensiones que se relacionan con el objeto. Esta sección describe el mapeo del modelo de datos que implementa el almacén de datos al almacén de relaciones se proporciona información sobre la API lógica consumida por los clientes de la plataforma de almacenamiento, de acuerdo con la presente modalidad. Sin embargo, deberá entenderse que se puede emplear un mapeo diferente cuando se emplea una máquina de base de datos diferente. Indudablemente, además de implementar el modelo de datos del concepto de la plataforma de almacenamiento en la máquina de base de datos de relación, también puede ser implementada en otros tipos de base datos, por ejemplo, bases de datos orientadas al objeto y XML. Un sistema de base de datos orientado al objeto (OO) proporciona persistencia y transacciones para objetos de lenguaje de programación, por ejemplo, (e.g.C + + , Java). La noción de la plataforma de almacenamiento de una (partida), mapea bien a un (Objeto), en los sistemas orientados al objeto a través de colecciones incrustadas que tendrían que ser agregadas a los Objetos. Otros conceptos del tipo de plataforma de almacenamiento, como la herencia y los tipos de elemento anidados, también mapean los sistemas del tipo orientado al objeto. Los sistemas orientados al objeto generalmente ya soportan la identidad del objeto; por lo que, la identidad de la partida puede ser mapeada a la identidad del objeto. Los comportamientos de la partida (operaciones) se mapea bien a los métodos orientados al objeto. Sin embargo, los sistemas orientados al objeto generalmente carecen de capacidades de organización y son deficientes en la búsqueda. Los sistemas orientados al objeto tampoco proporcionan soporte para datos no estructurados y semi-estructurados. Para soportar el modelo de datos de la plataforma de almacenamiento completa aquí descrita, se necesitarían agregar conceptos como relaciones, carpetas y extensiones al modelo de datos de objeto. Además, necesitarían ser implementados mecanismos como promociones, sincronización, notificaciones y seguridad. Similar a los sistemas orientados al objeto, las bases de datos XML, están basadas en el XSD (definición del esquema XML) y soportan una sola herencia basada en el sistema del tipo. El sistema del tipo de partida de la presente invención podría ser mapeado en el modelo del tipo XSD. Los XSDs tampoco proporcionan soporte para los comportamientos. Los XSDs para las Partidas tendrían que ser aumentados con comportamientos de Partidas. Las bases de datos XML tratan con documentos sencillos XSD y carecen de organización y capacidades amplias de búsqueda. Igual que con las bases de datos orientadas al objeto, para soportar el modelo de datos aquí descrito, necesitarían ser incorporados otros conceptos como las relaciones y las carpetas en dichas bases de datos X L; también, necesitarían ser implementados otros mecanismos como la sincronización, notificaciones y seguridad. Con respecto a las sub-secciones siguientes, se proporcionan unas cuantas ilustraciones para facilitar la información general descrita: la figura 13 es un diagrama que ilustra un mecanismo de notificación. La figura 14 es un diagrama que ilustra un ejemplo en el cual están dos transacciones insertando ambas un nuevo registro en el mismo árbol B. La figura 15 ¡lustra un proceso de detección de cambio de datos. La figura 16 ilustra un árbol de directorio de ejemplo. La figura 17 muestra un ejemplo en el cual una carpeta existente de un sistema de archivo basado en el directorio, es movida al almacén de los datos de la plataforma de almacenamiento. 1. Implementacion del Almacén de Datos Utilizando UDTs En la presente invención, la máquina de base de datos de relación 314, la cual en una modalidad comprende la máquina del servidor Microsoft SQL, soporta tipos de escala integrados. Los tipos de escala integrados, son "de origen" y "simples". Estos son de origen en el sentido de que el usuario no puede definir sus propios tipos, y son simples debido a que no pueden encapsular una estructura compleja. Los tipos definidos por el usuario (en lo sucesivo: UDTs) proporcionan un mecanismo para la capacidad de extensión del tipo arriba y mas allá del sistema de tipo de escala de origen, haciendo posible que los usuarios extiendan el sistema de tipo mediante la definición de tipos estructurados complejos. Una vez que es definido por el usuario, un UDT puede ser utilizado en cualquier parte del sistema del tipo en el que podría ser utilizado un tipo de escala integrada. De acuerdo con un aspecto de la presente invención, los esquemas de la plataforma de almacenamiento son mapeados a las clases UDT en el almacén de la máquina de base datos. Las Partidas del almacén de datos son mapeadas a las clases UDT derivándolas del tipo Base. Item. Igual que las Partidas, las Extensiones son mapeadas también a las clases UDT y utilizan la herencia. El tipo de Extensión de raíz es Base. Extensión, de la cual se derivan todos los tipos de Extensión. Una UDT es una clase CLR - tiene manifestaciones (es decir campos de datos) y comportamiento (es decir rutina). Las UDTs son definidas utilizando cualquiera de los lenguajes manejados-C#, VB.NET, etc. Los métodos UDT y los operadores pueden ser invocados en el T-SQL contra un objeto específico de ese 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 y el tipo de una variable en el T-SQL. El mapeo de los esquemas de la plataforma de almacenamiento a las clases UDT, funciona de manera directa bastante bien en un nivel alto. Generalmente, un esquema de plataforma de almacenamiento es mapeado a un espacio para nombre CLR. Un tipo de Plataforma de almacenamiento es mapeada a una clase CLR. La Herencia de la clase CLR tiene un efecto de espejo con la herencia del Tipo de plataforma de almacenamiento, y una Propiedad de la plataforma de almacenamiento es mapeada a una propiedad de la clase CLR. 2. Mapeo de Partidas Debido a lo deseable que es que las Partidas se pueden buscar globalmente y el soporte en la base de datos de relación de la presente modalidad para la herencia y la adaptabilidad del tipo, una implementación posible para el almacenamiento de Partidas en el almacén de la base de datos sería almacenar todas las Partidas en una sola tabla con una columna del tipo Base. Item. Utilizando la adaptabilidad, las Partidas de todos los tipos podrían ser almacenadas y se podrían filtrar búsquedas por el tipo de Partida y subtipos utilizando el operador que "es del (Tipo)" de Yukon. Sin embargo, debido a las preocupaciones acerca de los gastos asociados con dicho método, en la presente modalidad, las Partidas son divididas por el nivel de tipo superior, de modo que las Partidas de cada tipo de "familia" son almacenadas en una tabla separada. Bajo este esquema de división, se crea una tabla para cada tipo de Partida que se hereda directamente de Base. Item. Los tipos de herencia debajo de estos son almacenados en la tabla de la familia del tipo apropiado utilizando la adaptabilidad del tipo, tal y como se describe anteriormente. Solamente el primer nivel de la herencia del Base. Item es tratado de manera especial. Una tabla "sombreada" es utilizada para almacenar las copias de las propiedades que se pueden buscar globaimente de todas las Partidas. Esta tabla puede ser mantenida por el método UpdateQ de la API de la plataforma de almacenamiento, a través del cual se hacen todos los cambios de datos. A diferencia de las tablas de la familia del tipo, esta tabla global de Partidas contiene solamente las propiedades de escala de nivel superior de la Partida y no el objeto de la Partida UDT completo. La tabla global de Partidas permite la navegación al objeto de Partida almacenado en una tabla de familia de tipos, exponiendo un ItemID y un TypelD. La ItemID generalmente identificará de manera exclusiva la Partida dentro del almacén de datos. El TypelD puede ser mapeado utilizando metadatos, los cuales no se describen en esta solicitud a un nombre de tipo y la visión que contiene la Partida. Debido a que el descubrimiento de una Partida por su ItemID puede ser una operación común, tanto en el contexto de la tabla global de Partidas y de otro modo. Se proporciona una función Getltem() es proporcionada para recuperar un objeto de Partida que tiene otorgado un ItemID para las Partidas. Para el acceso conveniente, y para ocultar los detalles de implementación hasta un punto donde sea posible, todas las solicitudes de las Partidas podrían estar contra las visiones construidas en las tablas de Partidas anteriormente descritas. Específicamente, las visiones pueden ser creadas para cada tipo de Partida contra la tabla de la familia del tipo apropiado. Estas visiones del tipo pueden seleccionar todas las Partidas del tipo asociado, incluyendo los subtipos. Por razones de conveniencia, además del objeto UDT, las visiones pueden exponer columnas para todos los campos del nivel superior de ese tipo, incluyendo los campos heredados. 3. Mapeo de Extensiones Las extensiones son muy similares a las Partidas y tiene algunos de los mismos requerimientos. Como en otras herencias del soporte del tipo raíz, las Extensiones son sometidas a muchas de las mismas consideraciones y transacciones en el almacenamiento. Debido a esto, se aplica un mapeo de la familia de un tipo similar al aplicado a las Extensiones, en vez de un solo método de tabla. Por supuesto, en otras modalidades, podría utilizarse un solo método de tabla. En la presente modalidad, una Extensión está asociada exactamente con una Partida por medio de la ItemID, y contiene una ExtensionID que es única en el contexto de la Partida. Igual que con las Partidas se podría proporcionar una función para recuperar una Extensión debido a su identidad, la cual consiste de un par de ItemID y ExtensionID. Una Visión es creada para cada tipo de Extensión, similar a las visiones del tipo de Partida. 4. Mapeo de Elemento Anidado Los elementos anidados son tipos que pueden ser incrustados en las Extensiones, Relaciones y los elementos anidados para formar estructuras anidadas profundamente. Igual que las Partidas y las Extensiones, los Elementos Anidados son implementados como UDTs, pero son almacenados dentro de las Partidas o Extensiones. Por lo tanto, los Elementos Anidados no tienen mapeo de almacenamiento mas allá de sus contenedores de Partida y Extensión. En otras palabras, no existen tablas en el sistema los cuales almacenen directamente objetos específicos de tipos de Elementos Anidados, y no existen visiones dedicadas específicamente a los Elementos Anidados. 5. Identidad del objeto Cada entidad en el modelo de datos, es decir, cada Partida, Extensión y Relación, tiene un valor de clave único. Una Partida es identificada de manera exclusiva por su Itemld. Una Extensión es identificada de manera única por la clave compuesta de (Itemld, Extensionld). Una Relación es identificada por la clave compuesta (Item, Relationshipld). Itemld, Extensionld y Relationship son valoresGUID. 6. Denominación del objeto SQL Todos los objetos creados en el almacén de datos pueden ser almacenados en un nombre del esquema SQL derivado del nombre del esquema de la plataforma de almacenamiento. Por ejemplo, el esquema Básico de la plataforma de almacenamiento (con frecuencia denominado "Base") puede producir tipos en el esquema SQL "(System. Storage)", tales como "(System. Storage). Item". Los nombres generados tienen un prefijo por medio de un calificador para eliminar los conflictos en la denominación. En donde sea apropiado, es utilizado como un separador un carácter de exclamación (!) para cada parte lógica del nombre. La tabla siguiente subraya la convención de denominación utilizada para los objetos en el almacén de datos. Cada elemento del esquema (Partida, Extensión, Relación y Visión) se encuentra en una lista junto con la convención del nombre de la denominación decorada utilizada para tener pases de acceso al almacén de datos. 7. Denominación de la Columna Cuando se mapea cualquier modelo de objeto en un almacén, es posible que ocurran colisiones de denominación a la información adicional almacenada junto con el objeto de aplicación. Con el objeto de evitar las colisiones en la denominación, todas las columnas de tipo no específico (las columnas las cuales no mapean directamente a la propiedad denominada en una declaración del tipo), tendrán un prefijo con un carácter (_) con una marca inferior. En la presente modalidad los caracteres (_) de marca inferior no se permiten como el carácter del inicio de propiedad de identificador alguna. Además con el objeto de unificar la denominación entre el CLR y el almacén de datos, todas las propiedades de un tipo de la plataforma del almacenamiento o elemento de esquema (relación, etc) deben tener un primer carácter en mayúsculas. 8. Visiones de Búsqueda Se proporcionan visiones por parte de la plataforma de almacenamiento para buscar el contenido almacenado. Una visión SQL es proporcionada por cada Tipo de Partida y Extensión. Además, se proporcionan visiones para soportar Relaciones y Vistas (tal y como se definieron por el Modelo de Datos). Todas las visiones SQL y las tablas subyacentes en la plataforma de almacenamiento son solo de lectura. Los datos pueden ser almacenados o cambiados utilizando el método UpdateQ de la API de la plataforma de almacenamiento, como se describirá de una manera más detallada a continuación. Se puede tener acceso a cada una de las visiones explícitamente definida en el esquema de la plataforma de almacenamiento (definida por el diseñador del esquema, y no generada automáticamente por la plataforma de almacenamiento), por medio de la visión SQL [<schema-name>]. [Víew!<view-name<] . Por ejemplo, se podría tener acceso a una visión denominada "Boc-Sales" en el esquema "AcmePublisher.Books" utilizando el nombre "[AcmePublisher.Books].[View!BookSales]". Debido a que el formato de salida de una visión es personalizado en una base por visión (definido por una solicitud arbitraria proporcionada por la parte que define la visión) las columnas son mapeadas directamente basadas en la definición de la visión del esquema . Todas las visiones de búsqueda SQL del almacén de datos de la plataforma de almacenamiento utilizan la siguiente convención de ordenamiento para las columnas: · Columna "clave" lógica de las visiones resulta como Itemld, Elementld, Relationshipld, ... • Información de metadatos sobre el tipo del resultado tal como Typeld. • Cambio del rastreo de columnas tal como CreateVersion, UpdateVersion , ... • Tipo específico de columnas (s) (Propiedades del tipo declarado). • Tipo de visiones específicas (visiones de familia) que también contienen una columna de objeto la cual regresa el objeto.

Los miembros de cada tipo de familia que se pueden buscar utilizando una serie de visiones de Partida, siendo una visión por un tipo de Partida en el almacén de datos. La figura 28, es un diagrama que ilustra el concepto de una visión de búsqueda de Partida, a) Partida Cada visión de búsqueda de Partida contiene una fila para cada caso de una Partida del tipo específico o sus subtipos. Por ejemplo, la visión para Documento podría regresar objetos específicos de Documentos, LegalDocument y ReviewDocument. Debido a este ejemplo, las visiones de Partida pueden ser conceptualizadas, tal y como se muestra en la figura 29. (1) Visión de Búsqueda de Partida Maestra Cada objeto específico del almacén de datos de la plataforma de almacenamiento define una visión de Partida especial denominada Visión de Partida Maestra. Esta visión proporciona información de resumen sobre cada Partida en cada almacén de datos. La visión proporciona una columna por propiedad del tipo de Partida, una columna en la cual se describió el tipo de la Partida y varias columnas las cuales son utilizadas para proporcionar el rastreo de cambios y la información de sincronización. La visión de Partida maestra es identificada por el almacén de datos utilizando el nombre "[System. Storage].[ aster! Item]" (2) Visión de Búsqueda de Partidas Tipificadas Cada tipo de Partida también tiene una visión de búsqueda. Aunque es similar a la visión de Partida raíz, esta visión también proporciona acceso al objeto de la Partida por medio de la columna "_ltem". Cada visión de búsqueda de partida tipificada es identificada en un almacén de datos utilizando el nombre [schemaName].[itemTypeNarne). Por ejem lo [AcmeCorp.Doc].[OfficeDoc].

Columna Tipo Descripción itemld Itemld Identidad de la plataforma de almacenamiento de la Partida <type change Tipo de información de rastreo de cambio tracking> <parent props> <property specifio Una columna por propiedad de origen <item props> <property specifio Una columna por propiedad exclusiva de este tipo Jtern Tipo de partida Objeto CLR - tipo de Partida declarada CL b) Extensiones de Partida Todas las Extensiones de Partida en un almacén WinFS también son accesibles utilizando las visiones de búsqueda. (1) Visión de Búsqueda de Extensión Maestra Cada objeto específico de un almacén de datos define una visión de Extensión especial denominada la Visión de Extensión Maestra. Esta visión proporciona una información de resumen sobre cada Extensión en el almacén de datos. La visión tiene una columna por propiedad de la Extensión, una columna en la cual se describe el tipo de la Extensión y varias columnas que son utilizadas para proporcionar el rastreo de cambios y la información de sincronización. La visión de extensión maestra es identificada en un almacén de datos utilizando el nombre "[System. Storage].[M áster! Extensión]".

Columna Tipo Descripción Itemld Itemld La identidad de plataforma de almacenamiento de la Partida con la cual está asociada esta extensión Extensionld Extensionld Id de este objeto específico de extensión (GUID) JTypeld Typeld La Id del Tipo de la Extensión - identifica el tipo exacto de la extensión y puede ser utilizado para recuperar información sobre la extensión utilizando el catálogo de Metadados. <global change Información de rastreo global de cambios tracking> <ext properties> <property Una columna por propiedad del tipo de Extensión specific> (2) Visión de Búsqueda de Extensión Tipificada Cada tipo de Extensión tiene una visión de búsqueda. Aunque es similar a la visión de extensión maestra, esta visión también proporciona acceso al objeto de la Partida, por medio de la co!umna_Extensión. Cada visión de búsqueda de extensión tipificada es identificada en un almacén de datos utilizando el nombre [schemaName] .[Extensión! extensiónTypeN ame]. Por ejemplo, [AcmeCorp.Doc].[Extensión!OfficeDocExt]. c) Elementos Anidados Todos los elementos anidados son almacenados dentro de los objetos específicos de Partida, Extensiones o Relaciones. Como tales, se tiene acceso a ellos solicitando la visión de búsqueda de Partida, Extensión o Relación apropiada. d) Relaciones Tal y como se explicó anteriormente, las relaciones forman la unidad fundamental de enlace entre las Partidas en un almacén de datos de plataforma de almacenamiento. (1) Visión de Búsqueda de Relación Maestra Cada almacén de datos proporciona una Visión de Relación Maestra. Esta visión proporciona información sobre todos los objetos específicos de relación en el almacén de datos. La visión de relación maestra es identificada en un almacén de datos utilizando el nombre " [System. Storage]. [Mas te r!Relationship]". (2) Visión de Búsqueda de Objetos Específicos de Relación Cada Relación declarada, tiene también una visión de búsqueda la cual regresa todos los objetos específicos de la relación particular. Aunque es similar a la visión de la relación maestra, esta visión también proporciona columnas denominadas por cada propiedad de los datos de relación. Cada visión de búsqueda del objeto específico de la relación es identificado en un almacén de datos utilizando el nombre [schemaName].[Relationship!relationshipName]. Por ejemplo, [Acmé Corp. Doc]. [Relationship! DocumentAuthor], e) 9. Actualizaciones Todas las visiones del almacén de datos de plataforma de almacenamiento son solo de lectura. Con el objeto de crear un nuevo objeto específico de un elemento de modelo de datos (partida, extensión o relación) o para actualizar un objeto específico existente, deben de ser utilizados los métodos ProcessOperation o ProcessUpdategram de la API de la plataforma de almacenamiento. El método ProcessOperation es un solo procedimiento almacenado definido por el almacén de datos, el cual consume una "operación" que detalla una acción que va a ser realizada. El método ProcessUpdategram es un procedimiento almacenado el cual toma un conjunto de operaciones ordenado, conocido como un "updategram", el cual detalla colectivamente un conjunto de acciones que van a ser realizadas. El formato de operación se puede extender y proporciona varias operaciones sobre los elementos del esquema. Algunas operaciones comunes incluyen: 1. Operaciones de Partidas: a. Createltem (crea una nueva partida en el contexto de una relación de incrustación o posesión). b. Updateltem (actualiza una Partida existente). 2. Operaciones de Relación: a. CreateRelationship (crea un objeto específico de una relación de referencia o posesión) b. UpdateRelationship (actualiza un objeto específico de relación) c. DeleteRelationship (elimina un objeto específico de relación). 3.- Operaciones de Extensión: a. CreateExtension (agrega una extensión a una Partida existente). b. UpdateExtension (actualiza una extensión existente). c. DeleteExtension (elimina una extensión). 10 Rastreo de Cambios y Emisiones de Seguridad Los servicios de rastreo de cambios y emisión de seguridad son proporcionados por el almacén de datos, tal y como se explicará con mayor detalle más adelante. Esta sección proporciona un panorama de la información de rastreo de cambio expuesta en un almacén de datos, a) Rastreo de Cambios Cada visión de búsqueda proporcionada por el almacén de datos contiene columnas utilizadas para proporcionar información de rastreo de cambios; las columnas son comunes en todas las partidas, las visiones de Partida, Extensión y Relación. Las visiones del esquema de plataforma de almacenamiento, definidas explícitamente por los diseñadores del esquema no proporcionan automáticamente la información de rastreo de cambios -dicha información es proporcionada indirectamente a través de las visiones de búsqueda sobre las cuales son construidas las visiones mismas. Por cada elemento en el almacén de datos, está disponible la información de rastreo de cambios desde dos lugares - la visión de elemento "maestro" y la visión del elemento "tipificado". Por ejemplo, la información de rastreo de cambios en el tipo AcmeCorp. Document. Documentltem está disponible de la Visión de Partida Maestra "[System. Storage].[Master!ltem]" y la visión de búsqueda de Partida tipificada [AcmeCorp. Document]-[Documento]. (1) Rastreo de Cambios en las Visiones "Maestras de Búsqueda" La información de rastreo de cambios en la visión maestra de búsqueda proporciona información sobre la creación y versiones de actualización de un elemento, información sobre la cual el asociado sync creó el elemento, cuyo asociado sync actualizó finalmente el elemento y los números de versiones de cada asociado para la creación y actualización. Los asociados en las relaciones sync (que se describen más adelante) son definidos por la clave del asociado. Un solo objeto UDT nombrado _ChangeTrackinglnfo del tipo [System. Storage. Store]. ChangeTrackingl nfo contiene toda esta información. El tipo es definido en el esquema System. Storage, está disponible _ChangeTrackinglnfo, en todas las visiones de búsqueda global para la Partida, Extensión y Relación y la definición del tipo de ChangeTrackinglnfo es: <Nombre del Tipo ="ChangeTrackinglnfo BaseType = "Base.NestedElement"> <Nombre de FieldProperty ="CreationLocalTS Type="SqlTypes.Sqllnt64" Se puede anular ="False" /> <Nombre de FieldProperty ="CreatingPartnerKey" Tipo ="SqlTypes.Sqllnt32" Se puede anular="False" /> <Nombre de FieldProperty ="CreatingPartnerTS" Tipo ="SqlTypes.Sqllnt64" Se puede anular="False" /> <Nombre de FieldProperty ="LastUpdateLocalTS" Tipo ="SqlTypes.Sqllnt64" Se puede anular="False" /> Nombre de FieldProperty="l_astUpdatingPartnerKey" Tipo ="SqlTypes.SqIInt32" Se puede anular="False" /> <Nombre de FieldProperty ="LastUpdatingPartnerTS Tipo = "SqlTypes.Sqllnt64" Se puede anular="False" /> </Tipo> Estas propiedades contienen la siguiente información: Columna Descripción _CreafionLocalTS Creación del sello de tiempo por la máquina local _Creat¡ngPartnerKey PartnerKey del asociado quien creó esta entidad. Sí la entidad fue creada localmente, este es el PartnerKey de la máquina local. _Creat¡ngPartnerTS Timestamp el tiempo en el cual está entidad fue creada en el asociado correspondiente a _CreatingPartnerKey.

J-astUpdateLocalTS Timestamp local correspondiente a la fecha de actualización en la máquina local _LastUpdatingPartnerKey PartnerKey del asociado quien actualizó por último esta entidad. Si la última actualización a la entidad fue hecha localmente, este es el PartnerKey de la máquina local. _LastUpdatingPartnerTS Timestamp del tiempo en el cual fue actualizada esta entidad en el asociado correspondiente a _LastUpdatingPartnerKey. (2) Rastreo de Cambios en las Visiones de Búsqueda "Tipificada" Además de proporcionar la misma información que la visión de búsqueda global, cada visión de búsqueda tipificada proporciona información adicional registrando la condición sync de cada elemento en la topología sync.

Columna Tipo Descripción <gIobaI change Información del rastreo global de cambio tracking> _ChangeUnitVers¡ons ultiSet<ChangeUnitVersion> Descripción de los números de versión de las Unidades de Cambio dentro del elemento particular _EIementSyncMetada ElementSync etada etadatos adicionales independientes de la versión acerca de esta partida que son solamente de Interés para el tiempo de ejecución de Sincronización. _VersionSyncMetada VersionSyncMetada Metadatos adicionales específicos de la versión acerca de esta versión que son solamente de interés para el tiempo de ejecución de Sincronización. (b) Emisión de Seguridad El almacén de datos proporciona información de emisión de seguridad para las Partidas, Extensiones y Relaciones. Las visiones de emisión de seguridad proporcionan información acerca de entidades vivas y emisiones de seguridad, (partidas, extensiones y relación) en un lugar. Las visiones de partida y de emisión de seguridad de extensión no proporcionan un acceso al objeto correspondiente, mientras que la visión de emisión de seguridad de relación proporciona acceso al objeto de relación (el objeto de relación es NULO en el caso de una relación de emisión de seguridad). (1) Emisión de Seguridad de Partidas Las Emisiones de Seguridad de Partida son recuperadas del sistema por medio de la visión [System. S tora ge]. [Tombstone! Item], Columna Tipo Descripción Itemld Itemld Identidad de la Partida _TypeID Typeld Tipo de la Partida <ltem properties> Propiedades definidas para todas las partidas _Rootltemld Itemld Itemld de la primera partida que no es de incrustración la cual contiene esta partida _ChangeTrackinglnfo Objeto específico CLR Información de rastreo de cambios para esta de ChangeTrackinglnfo partida JsDeleted BIT Esta es una señal de que es 0 para las partidas de vida, y 1 para las partidas Incluidas en las emisiones de seguridad. _DeletionWallclock UTCDATETIME Fecha y hora del reloj de pared UTC de acuerdo con el asociado el cual eliminó la partida. Esto es NULO si la partida está todavía con vida. (2) Emisión de Seguridad de Extensiones Las Emisiones de Seguridad de extensiones son recuperadas del sistema utilizando la visión [System. Storage].[Tombstone!Extension]. La información de rastreo de cambio de Extensión es similar a la que se proporciona para las Partidas con la adición de la Propiedad. Extensionld. (3) Emisión de Seguridad de Relaciones Los Emisiones de Seguridad de Relaciones son recuperadas del sistema por medio de la visión [System. Storage].[TombstoneRelationship]. La información de los Emisiones de Seguridad de Relaciones es similar a la proporcionada por las Extensiones. Sin embargo, la información adicional es proporcionada en el objetivo ItemRef del objeto específico de la relación. Además, el objeto de la relación también es seleccionado. (4) Eliminación de Emisión de Seguridad Con el objeto de evitar el crecimiento sin límite de la información de emisión de seguridad, el almacén de datos proporciona la tarea de limpieza de emisión de seguridad. Esta tarea determina cuando una información de emisión de seguridad puede ser descartada. La tarea computa un límite en la versión de crear/actualizar local y luego trunca la información de emisión de seguridad descartando todas las versiones anteriores de la emisión de seguridad. 11.- APIs de Ayuda y Funciones El mapeo básico también proporciona un número de funciones de ayuda. Estas funciones son suministradas para ayudar en las operaciones comunes sobre el modelo de datos. a) Función [System. Storage].Getltem Regresa un objeto de Partida con una Itemld proporcionada // Item Getltem (Itemld Itemid) b) Función [System. Storage].GetExtension // Regresa un objeto de extensión que tiene Itemld y Extensionld // Extensión GetExtension (Itemid Itemid, Extensionld Extensionld c) Función [System. Storagej.GetRelationship // Regresa un objeto de relación al que se le ha proporcionado una Itemld y Relationshipid // Relationship GetRelationship (Itemid Itemid, Relationshipid Relationshipid) 12. Metadatos Existen dos tipos de metadatos representados en el Almacén: metadatos de objetos específicos (el tipo de una Partida, etc.) y metadatos de tipo. a) Metadatos de Esquema Los metadatos de esquema son almacenados en el almacén de datos como objetos específicos de tipos de Partida del esquema Meta. b) Metadatos de Objeto Específico Los metadatos de objeto específico son utilizados por una aplicación para solicitar el tipo de una Partida y encuentra las extensiones asociadas con una Partida. Debido a la Itemld para una Partida, una aplicación puede solicitar la visión de partida global para regresar el tipo de la Partida y utilizar este valor para solicitar la visión Meta-Type para regresar información sobre el tipo declarado de la Partida. Por ejemplo, //Regresa el objeto de la Partida de metadatos para un objeto específico de Partida determinada // SELECTm. Item como metadatal nfoObj DE [System. Storage].[ltem]¡ INNER JOIN [Meta].[Type]m ON i. _Typeld = m. Itemld DONDE i. itemld = ©Itemld E. SEGURIDAD En general, todos los objetos que se pueden asegurar acomodan sus derechos de acceso utilizando el formato de máscara de acceso mostrado en la figura 26. En este formato, 16 bits de bajo orden son para los derechos de acceso específicos del objeto, los siguientes 7 bits son derechos de acceso estándar, los cuales son aplicables a la mayor parte de tipos de objetos, y los 4 bits de orden alto son utilizados para especificar derechos genéricos de acceso que pueden mapear cada tipo de objeto a un conjunto de derechos estándar y específicos del objeto. El bit ACCESS_SYSTEM_SECURITY corresponde al derecho para acceder a una SACL de objeto. En la estructura de ocultamiento de acceso de la figura 26, los derechos específicos de la partida son colocados en la sección de Derechos Específicos del Objeto (16 bits de orden bajo), debido a que en la presente modalidad, la plataforma de almacenamiento expone dos conjuntos de APIs para administrar la seguridad - Win32 y la API de plataforma de almacenamiento, los derechos específicos del objeto del archivo deben de ser considerados, con el objeto de motivar el diseño de los derechos específicos del objeto de la plataforma de almacenamiento. El modelo de seguridad para la plataforma de almacenamiento de la presente invención, se describe completamente en las solicitudes relacionadas incorporadas como referencia anteriores. En este aspecto, la figura 27 (partes a, b y c) ¡lustra la nueva región de seguridad protegida de manera idéntica que está siendo separada de una región de seguridad existente, de acuerdo con una modalidad del modelo de seguridad. F. RASTREO DE NOTIFICACIONES Y CAMBIOS De acuerdo con otro objeto de la presente invención, la plataforma de almacenamiento proporciona capacidades de notificaciones que permiten que las aplicaciones rastreen los cambios de datos. Esta característica es pretendida principalmente para aplicaciones las cuales mantienen una condición volátil, o ejecutan lógicas del negocio en eventos de cambio de datos. El registro de aplicaciones para las notificaciones sobre las partidas, extensiones de las partidas y relaciones de las partidas. Las notificaciones son entregadas de una manera asincrona después de que se han hecho los cambios de datos. Las aplicaciones pueden filtrar notificaciones por partida, extensión y tipo de relación, así como el tipo de operación. De acuerdo con una modalidad, la plataforma de almacenamiento API 322 proporciona dos tipos de interfases para las notificaciones. Primero, el registro de aplicaciones para eventos de cambio de datos simples detonados por los cambios a las partidas, extensiones de partidas y relaciones de las partidas. Segundo, las aplicaciones crean objetos del "observador" para monitorear los conjuntos de partidas, extensiones de partidas y relaciones entre las partidas. La condición de un objeto observador puede ser guardada y volverse a crear después de una falla del sistema o después de que un sistema se ha salido de línea por un período de tiempo prolongado. Una sola notificación puede reflejar actualizaciones múltiples. Los detalles adicionales con respecto a esta funcionalidad se pueden encontrar en las solicitudes relacionadas incorporadas como referencia anteriormente. G. INTEROPERABILIDAD DEL SISTEMA DE ARCHIVO TRADICIONAL Como se mencionó anteriormente, la plataforma de almacenamiento de la presente invención, en al menos algunas sus modalidades, pretende ser incorporada como una parte integral del sistema de interfase de hardware/software de un sistema de cómputo. Por ejemplo, la plataforma de almacenamiento de la presente invención puede ser incorporada como una parte integral de un sistema operativo, tal como, la familia Microsoft Windows de sistemas operativos. En esa capacidad, la API de la plataforma de almacenamiento se convierte en parte de las APIs del sistema operativo a través de la cual interactúan los programas de aplicación con el sistema operativo. De este modo, la plataforma de almacenamiento llega a ser el medio a través del cual los programas de aplicación almacenan la información en el sistema operativo, y el modelo de datos basado en las Partidas de la plataforma de almacenamiento, por lo tanto, reemplazan el sistema de archivos tradicional de dicho sistema operativo. Por ejemplo, tal y como está incorporada en la familia Microsoft Windows de sistemas operativos, la plataforma de almacenamiento podría reemplazar el sistema de archivos NTFS implementado en ese sistema operativo. Actualmente, los programas de aplicación tienen acceso a los servicios de sistemas de archivo NTFS a través de las APIs de Win32 expuestas por la familia Windows de sistemas operativos. Sin embargo, reconociendo que reemplazar completamente el sistema de archivo NTFS por la plataforma de almacenamiento de la presente invención requeriría volver a codificar los programas de aplicación existentes basados en Win32 y que dicha descodificación podría ser indeseable, sería benéfico que la plataforma de almacenamiento de la presente invención, proporcionara alguna interoperabilidad con los sistemas de archivo existentes, tales como el NTFS. Por lo tanto, en una modalidad de la presente invención, la plataforma de almacenamiento hace posible que los programas de aplicación que dependen del modelo de programación Win32 tengan acceso al contenido, tanto del almacén de datos de la plataforma de almacenamiento, como al sistema de archivo NTFS tradicional. Con este fin, la plataforma de almacenamiento utiliza una convención de denominación que es un súper conjunto de convenciones de denominación Win32 para facilitar la interoperabilidad fácil. Además, la plataforma de almacenamiento soporta el acceso a archivos y directorios almacenados en el volumen de la plataforma de almacenamiento a través de la API Win32. Los detalles adicionales con respecto a esta funcionalidad se pueden encontrar en las solicitudes relacionadas incorporadas como referencia anteriormente. H. API DE PLATAFORMA DE ALMACENAMIENTO La plataforma de almacenamiento comprende una API que hace posible que los programas de aplicación tengan acceso a las características y capacidades de la plataforma de almacenamiento explicada anteriormente, y tengan acceso a las partidas almacenadas en el almacén de datos. Esta sección describe una modalidad de una API de la plataforma de almacenamiento de la presente invención. Los detalles con respecto a esta funcionalidad se pueden encontrar en las solicitudes relacionadas incorporadas como referencia anteriormente, con algo de esta información resumida a continuación por razones de conveniencia. Haciendo referencia a la figura 18, la Carpeta de Contención, es una partida la cual contiene Relaciones de Posesión para otras Partidas y es el equivalente del concepto como de una carpeta de sistema de archivo. Cada Partida esta "contenida" dentro de por lo menos una carpeta de contención. La figura 19 ilustra la arquitectura básica de la API de la plataforma de almacenamiento de acuerdo con la siguiente modalidad. La API de la plataforma de almacenamiento utiliza SQLCIientl 900 para hablar al almacén de datos local 302, y también puede utilizarla para hablar con los almacenes de datos remotos (es decir, el almacén de datos 340). El almacén local 302, puede hablar al almacén de datos remoto 340 utilizando, ya sea el DQP (Procesador de Solicitud Distribuido) o a través del servicio de sincronización de la plataforma de almacenamiento ("Sync"), que se describirá más adelante. La API 322 de la plataforma de almacenamiento también actúa como la API de puente para las notificaciones del almacén de datos, pasando las subscripciones de la aplicación a la máquina de notificación 332, y enrutando las notificaciones a la aplicación (es decir, la aplicación 350a, 350b ó 350c), como se describió también anteriormente. En una modalidad, la API 332 de la plataforma de almacenamiento también puede definir una arquitectura "proveedora" limitada, de modo que pueda tener acceso a los datos en los sistemas Microsoft Exchange y AD. La figura 20, representa esquemáticamente los diferentes componentes de la API de la plataforma de almacenamiento. La API de la plataforma de almacenamiento consiste de los siguientes componentes: (1) clases de datos 2002, las cuales representan el elemento de la plataforma de almacenamiento y los tipos de datos, (2) el sistema de tiempos de ejecución 2004, el cual administra la persistencia del objeto y proporciona la clase de soporte 2006; y (3) las herramientas 2008, las cuales son utilizadas para generar clases CLR de los esquemas de la plataforma de almacenamiento. La jerarquía de las clases resultantes de un esquema determinado refleja directamente la jerarquía de los tipos de ese esquema. Como un ejemplo, considerar los tipos de Partida definidos en el esquema de Contactos como se muestran en las figuras 21A y 21B. La figura 22, ilustra el sistema de tiempo de ejecución en operación. El sistema de tiempo de ejecución opera de la manera siguiente: 1. Una aplicación 350a, 350b, o 350c se enlaza a una partida en la plataforma de almacenamiento. 2. El sistema 2004 crea un objeto ItemContext 2202 correspondiente a la partida del límite y lo regresa a la aplicación. 3. La aplicación somete un comando de Encontrar sobre este ItemContext para obtener una colección de Partidas; la colección regresada es conceptualmente una gráfica de objetos 2204 (debido a las relaciones). 4. La aplicación de cambios, elimina e inserta datos.

. La aplicación guarda los cambios invocando el método UpdateQ. La figura 23, ilustra la ejecución de una operación "FindAII".

La figura 24, ilustra el proceso por medio del cual las clases de la API de la plataforma de almacenamiento son generadas del Esquema de la plataforma de almacenamiento. La figura 25, ilustra el esquema sobre el cual está basada la API de Archivo. La API de la plataforma de almacenamiento incluye un espacio del nombre para manejar los objetos de archivo. El espacio del nombre es denominado System. Storage. Files. Los miembros de datos de las clases en System. Storage. Files reflejan directamente la información almacenada en el almacén de la plataforma de almacenamiento; esta información es "promovida" de los objetos del sistema de archivo o puede ser creada originalmente utilizando la API Win32. El espacio del nombre System. Storage. Files tiene dos clases: Fileltem y Directoryltem. Los miembros de estas clases y los métodos de los mismos pueden ser encontrados fácilmente buscando un diagrama del esquema en la figura 25. Fileltem y Directoryltem son solo de lectura de la APÍ de la plataforma de almacenamiento. Con el objeto de modificarlos, se tiene que utilizar la API Win32 o las clases en el System.10. Con respecto a las APIs, la ¡nterfase de programación (o más simplemente, la inférase) puede ser vista como un mecanismo, proceso, protocolo para hacer posible que uno o más segmentos del código se comuniquen con o tengan acceso a la funcionalidad proporcionada por uno o más de otros segmentos del código. Alternativamente, una interfase de programación puede ser vista como uno o más mecanismos métodos, invocaciones de función, módulos, objetos, etc., de un componente de un sistema con capacidad para el acoplamiento de comunicación con uno o más mecanismos, métodos, invocaciones de función, módulos, etc., de otros componentes. El término "segmento de código" en la oración anterior pretende incluir una o más instrucciones o líneas de código, e incluye por ejemplo, módulos de código, objetos, subrutinas, funciones, etc., independientemente de la terminología aplicada, o de si los segmentos de código son recopilados por separado, o si los segmentos de código son proporcionados como fuente, intermediarios o códigos de objeto, si los segmentos de código son utilizados en un sistema o proceso de tiempo de ejecución, o si están localizados en la misma máquina o máquinas diferentes o distribuidos en máquinas múltiples, o si la funcionalidad representada por los segmentos de código es impiementada en su totalidad en el software, en su totalidad en el hardware, o una combinación del hardware y el software. Como una noción, una interfase de programación puede ser vista genéricamente como se muestra en la figura 30A o la figura 30B. La figura 30A ¡lustra una interfase Intefacel como el conducto a través del cual se comunican el primer y segundo segmentos de código. La figura 30B ilustra una interfase que comprende los objetos de interfase 11 y 12 (los cuales pueden ser o no parte del primer y segundos segmentos de código) y los cuales hacen posible que el primer y segundo segmentos de código de un sistema se comuniquen por un medio . En la vista de la figura 30B, se pueden considerar los objetos 11 e 12 de la interfase como interfases separadas del mismo sistema, o también se puede considerar que los objetos 11 e 12 más el medio M comprenden la interfase. Aunque las figuras 30A y 30B muestran un flujo bidireccional y las interfases de cada lado del flujo, ciertas implementaciones pueden tener solamente información en el flujo en una dirección (o ningún flujo de información como se describirá más adelante) o pueden tener solamente un objeto de interfase en un lado. A modo de ejemplo, y no de limitación, los términos tales como interfase de programación de aplicación (API), punto de entrada, método, función, subrutina, invocación de procesamiento remoto e interfase del modelo de objeto del componente (COM), están comprendidos dentro de la definición de la interfase de programación. Los aspectos de dicha interfase de programación, pueden incluir el método por medio de los cuales el primer segmento del código transmite información (en donde la "información" es utilizada en su sentido más amplio e incluye datos, comandos, solicitudes, etc.) al segundo segmento de código; el método por medio del cual el segundo segmento de código recibe la información y la estructura, secuencia, sintaxis, organización, esquema, temporización y contenido de la información. En este aspecto, el medio de transporte subyacente mismo puede no ser importante para la operación de la interfase, el medio puede ser, ya sea cableado o inalámbrico o una combinación de ambos, siempre que la información sea transportada de la manera definida por la interfase. En ciertas situaciones, la información puede no ser pasada en una o ambas direcciones en el sentido convencional, ya que la transferencia de información puede ser, ya sea por medio de otro mecanismo (es decir información colocada en una memoria intermedia, archivo, etc., separada del flujo de información entre los segmentos de código) o no existente, como es en el caso cuando un segmento de código simplemente tiene acceso a la funcionalidad realizada por un segundo segmento de código. Cualquiera y todos estos aspectos pueden ser importantes en una situación determinada, es decir, dependiendo de si los segmentos de código son parte de un sistema o en una configuración acoplada de manera suelta o apretada, y de modo que esta lista debe de ser considerada ilustrativa y no limitativa. Esta noción de la interfase de programación es conocida para aquellos expertos en la técnica y es clara a partir de la descripción detallada anterior de la presente invención. Sin embargo, existen otros medios para implementar una interfase de programación y a menos que sean excluidos expresamente, estos también pretenden estar comprendidos por las reivindicaciones establecidas al final de esta descripción. Dichos otros medios pueden parecer más sofisticados o complejos que la visión simple de las figuras 30A y 30B, pero ellos sin embargo, realizan una función similar para lograr el mismo resultado general. Ahora describiremos brevemente algunas implementaciones alternativas ilustrativas de la interfase de programación. Factorización: Una comunicación de un segmento de código a otro puede ser lograda indirectamente, rompiendo la comunicación entre comunicaciones separadas múltiples. Esto se ilustra esquemáticamente en las figuras 31A y 31B. Tal y como se ilustra, algunas interfases se pueden describir en términos de conjuntos de funcionalidad divisibles. Por lo tanto, la funcionalidad de la interfase de las figuras 30A y 30B puede ser factorizada para lograr el mismo resultado, justamente como se puede proporcionar matemáticamente 24, 0 2 x 2 x 3 x 2. Por consiguiente, como se ilustra en la figura 31A, la función proporcionada por la interfase Interfacel puede ser subdividida para convertir la comunicaciones de la interfase en interfases múltiples Interfacel A, InterfacelB, Interfacel C, etc., mientras que se logra el mismo resultado.

Tal y como se ¡lustra en la figura 31B, la función proporcionada por la interfase 11 puede ser subdividida en ¡nterfases múltiples 11a, 11b, 11c, etc, mientras que se logre el mismo resultado. De un modo similar, la interfase 12 del segundo segmento de código, el cual recibe la información del primer segmento de código puede ser factorizada en interfases múltiples 12a, 12b, 12c, etc. Cuando se factoriza, el número de ¡nterfases incluidas en el primer segmento del código no necesita coincidir con el número de ¡nterfases incluidas en el segundo segmento de código. Cualquiera de los casos de las figuras 31A y 31B, el espíritu funcional en las interfases Interfacel y 11 permanecen iguales que en las figuras 30A y 30B, respectivamente. La factorización de las interfases también pueden seguir propiedades asociativas, conmutativas, y otras propiedades matemáticas, de modo que la factorización puede ser difícil de reconocer. Por ejemplo, el ordenamiento de las operaciones puede no ser importante, y por consiguiente, una función realizada por una interfase puede ser llevada a cabo también por anticipado para alcanzar la interfase, por otra pieza de código o interfase, o realizada por un componente separado del sistema. Además, en un aspecto en la técnica de programación se puede apreciar que existe una variedad de medios para hacer las mismas invocaciones de función que logran el mismo resultado.

Redefinición: En algunos casos, puede ser posible ignorar, agregar o volver a definir ciertos aspectos (por ejemplo, parámetros) de una interfase de programación mientras que todavía se logra el resultado pretendido. Esto se ilustra en las figuras 32A y 32B. Por ejemplo, supongamos que la interfase Interfacel de la figura 30A incluye un Cuadro de invocación de función (entrada, precisión, salida), una invocación que incluye tres parámetros, entrada, precisión y salida, y el cual es emitido desde el primer Segmento de Código al segundo Segmento de Código. En la precisión de parámetros de enmedio si no es de preocupación en un escenario determinado, como se muestra en la figura 32A podría justamente ser bien ignorado o aún reemplazado por un parámetro sin significado (en esta situación). También se puede agregar un parámetro adicional, si no existe preocupación. En cualquier caso, puede ser lograda la funcionalidad del cuadrado, siempre que la salida sea regresada después de la entrada y sea elevada al cuadrado por el segundo segmento de código. La precisión puede muy bien ser un parámetro sin significado para alguna porción descendente o de otro tipo del sistema de cómputo. Sin embargo, una vez que se ha reconocido esa precisión no es necesaria para el propósito estrecho de calcular el cuadrado, puede ser reemplazada o ignorada. Por ejemplo, en vez de pasar un valor de precisión válido, se podría pasar un valor sin significado tal como una fecha de nacimiento, sin afectar de manera adversa el resultado. De un modo similar, como se muestra en la figura 32B, la interfase 11 es reemplazada por la interfase 11', se vuelve a definir para ignorar o agregar parámetros a la interfase. La interfase 12 puede ser definida de nuevo de un modo similar al de la interfase 12' definida de nuevo para ignorar parámetros innecesarios o parámetros que pueden ser procesados en alguna otra parte. Aquí el punto es que en algunos casos la interfase de programación puede incluir aspectos, tales como parámetros, que no son necesarios para algún propósito, de modo que ellos pueden ser ignorados o definidos de nuevo, o procesados en cualquier otra parte para otros propósitos. Codificación en Línea: También es posible fusionar algunas o todas las funcionalidades en dos módulos de códigos separados, de modo que la "interfase" entre ellos cambie de forma. Por ejemplo, la funcionalidad de las figuras 30A y 30B puede ser convertida en la funcionalidad de las figuras 33A y 33B, respectivamente. En la figura 33A, el primer y segundos segmentos de código anteriores de la figura 30a, son fusionados en un módulo que los contiene a ambos. En este caso, los segmentos de código todavía pueden estarse comunicando entre ellos, pero la interfase puede ser adaptada a una forma, la cual sea más adecuada para un solo módulo. Por lo tanto, por ejemplo, las manifestaciones de Invocación y Regreso formales pueden no ser necesarias ya, pero el procesamiento o respuesta similar de conformidad con la interfase 1 puede estar todavía en efecto. De un modo similar, como se muestra en la figura 33B, parte (o toda) 12 de la figura 30B puede ser escrita en línea dentro de la interfase 11 para formar la interfase 11". Tal como se ilustró, la interfase 12 es dividida en la I2a e I2b, y la porción de interfase i 2 b ha sido codificada en línea con la interfase 11 para formar la interfase 11". Para un ejemplo concreto, considerar que la interfase 11 de la figura 30B realiza un cuadrado de la invocación de función (entrada, salida), el cual es recibido por la interfase 12, el cual después de procesar el valor pasado con la entrada (elevado al cuadarado por el segundo segmento de código vuelve a pasar el resultado elevado al cuadrado con la salida. En dicho caso, el procesamiento realizado por el segundo segmento de código (entrada para elevarlo al cuadrado) puede ser realizada por el primer segmento de código sin una invocación a la interfase. Separación: Una comunicación de un segmento de código a otro puede ser realizada indirectamente, rompiendo la comunicación en comunicaciones múltiples separadas. Esto se ilustra esquemáticamente en las figuras 34A y 34B. Tal y como se muestra en la figura 34A, una o más piezas intermedias (interfases de separación, ya que separan la funcionalidad y/o funciones de la interfase de la interfase original) son proporcionadas para convertir las comunicaciones de la primera interfase Interfacel, para adaptarlas a una interfase diferente, en este caso, las interfases lnterface2A, lnterface2B e lnterface2C. Esto se podría hacer, por ejemplo, en donde existe una base de aplicación instalada y diseñada para comunicarse con un sistema operativo de acuerdo con un protocolo de la interfacel, pero entonces el sistema operativo es» cambiado para utilizar una interfase diferente, en este caso las interfases lnterface2A, lnterface2B, e lnterface2C. El punto es que la interfase original utilizada por el Segundo Segmento de Código es cambiada, de modo que ya no es compatible con la interfase utilizada por el Primer Segmento de Código, y de este modo, se utiliza un intermediario para hacer compatibles a la interfase vieja y nueva. De un modo similar, tal como se muestra en la figura 34B, un tercer Segmento de Código puede ser introducido por la interfase de separación D11 para recibir las comunicaciones de la interfase 11 y con la interfase de separación DI2 para transmitir la funcionalidad de interfase a, por ejemplo, las interfases I2a e I2b, y volver a diseñarlas para funcionar con la DI2 pero para proporcionar el mismo resultado funcional. De un modo similar, las interfases DI1 y DI2 pueden funcionar juntas para traducir la funcionalidad de las interfases 11 e 12 de las figuras 30B a un nuevo sistema operativo, mientras que proporcionan un resultado funcional igual o similar. Nueva Escritura: Todavía es posible una variante para volver a escribir de manera dinámica el código para reemplazar la funcionalidad de interfase con algo más, pero la cual logra el mismo resultado general. Por ejemplo, puede ser un sistema en ei cual el segmento de código presentado en un lenguaje intermedio (por ejemplo, Microsoft IL, JavaByteCode, etc.) es proporcionado a un recopilador Justo a Tiempo (JIT) o interpretador en un entorno de ejecución (tal como el que es proporcionado por el sistema .Net, el entorno de tiempo de ejecución Java u otros entornos de un tipo del tiempo de ejecución similares). El recopilador JIT puede ser escrito de modo que convierta dinámicamente las comunicaciones del 1er. Segmento del Código al 2o. Segmento del Código, es decir, que los adapte a una interfase diferente como pueda ser requerido por el 2o. Segmento de Código ( ya sea el original o un 2°. Segmento de Código diferente). Esto se ilustra en la figura 35A y 35B. Se puede apreciare en la figura 35A, que el método es similar al escenario de Preparación descrito anteriormente. Esto se puede hacer, por ejemplo, en donde una base de aplicación instalada está diseñada para comunicarse con un sistema operativo, de acuerdo con protocolo de Interfase 1, pero entonces el sistema operativo es cambiado para utilizar una ¡nterfase diferente. El recopilador JIT podría ser utilizado para adaptar las comunicaciones al vuelo desde una aplicación base instalada a la interfase nueva del sistema operativo. Tal y como se ilustra en la figura 35B, este método para volver a escribir dinámicamente las interfases pueden ser aplicadas para factorizar dinámicamente, o alterar de otro modo las interfases también. También deberá quedar entendido que los escenarios descritos anteriormente para lograr resultados iguales o similares como una interfase por medio de modalidades alternativas pueden ser combinados también de diferentes maneras, en serie y/o en paralelo, o con otros códigos de intervención. Por lo tanto, las modalidades alternativas presentadas anteriormente no son exclusivas mutuamente y pueden ser mezcladas, acopladas y combinadas para producir el mismo escenario o escenarios equivalentes a los escenarios genéricos presentados en las figuras 30A y 30B. También deberá observarse que, como en la mayoría de las construcciones de programación, existen otros medios similares para lograr una funcionalidad igual o similar de una interfase, los cuales pueden no ser descritas en este documento, pero que sin embargo, son representadas por el espíritu y alcance de la presente invención, es decir, se debe observar que es por lo menos parcialmente la funcionalidad representada por, y los resultados ventajosos posibilitados por, una interfase que subyace el valor de una ¡nterfase. III. API DE SINCRONIZACIÓN Son posibles varios métodos para la sincronización en un sistema de interfase de hardware/software basado en las Partidas. La Sección A describe varias modalidades de la presente invención, mientras que la Sección B se enfoca en varias modalidades de una API para la sincronización. A. REVISIÓN GENERAL DE SINCRONIZACIÓN Para varias modalidades de la presente invención, y con respecto a la figura 3, la plataforma de almacenamiento proporciona un servicio de sincronización 330 que (i) permite casos múltiples de la plataforma de almacenamiento (cada una con su propio almacén de datos 302) para sincronizar partes de su contenido de acuerdo con un conjunto de reglas flexibles y (ii) proporciona una estructura 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 de propiedad. La sincronización de almacenamiento-plataforma a almacenamiento-plataforma ocurre entre un grupo de "réplicas" participantes. Por ejemplo, haciendo referencia a la figura 3, puede ser deseable proporcionar la sincronización entre el almacén de datos 302 y la plataforma de almacenamiento 300 con otro almacén de datos remoto 338 bajo el control de otro objeto específico de plataforma de almacenamiento, que tal vez opera en un sistema de cómputo diferente. La membresia total de este grupo no es necesariamente conocida para cualquier réplica determinada en cualquier momento determinado. Las réplicas diferentes pueden hacer los cambios independientemente (es decir, simultáneamente). El proceso de sincronización es definido como que hace que cada réplica se entere de los cambios hechos por otras réplicas. Esta capacidad de sincronización es inherentemente de maestro múltiple. La capacidad de sincronización de la presente invención permite réplicas para: • determinar de cuales cambios está informada la otra réplica; · solicitar información acerca de los cambios de los que no está informada esta réplica; • transportar información acerca de los cambios de los que no está informada la otra réplica; • determinar cuando dos cambios están en conflicto entre ellos; • aplicar localmente los cambios; • transportar las resoluciones del conflicto a otras réplicas para asegurar la convergencia; y • solucionar los conflictos en base a políticas especificadas para la resolución de conflictos. 1. Sincronización Almacenamiento-Plataforma a Almacenamiento -Plataforma La aplicación principal del servicio de sincronización 330 de la plataforma de almacenamiento de la presente invención, es sincronizar casos múltiples de plataformas de almacenamiento (cada uno con su propio almacén de datos). El servicio de sincronización opera en el nivel de los esquemas de la plataforma de almacenamiento (en vez de las tablas subyacentes de la máquina de la base de datos 214). Por lo tanto, por ejemplo, se utilizan los "Alcances" para definir los conjuntos de sincronización, tal y como se describirán más adelante. El servicio de sincronización opera bajo el principio de "cambios netos". En vez del registro y envió de operaciones individuales (tal como con la duplicación de transacciones) el servicio de sincronización envía el resultado final de estas operaciones, por lo tanto, con frecuencia consolida los resultados de operaciones múltiples en un solo cambio resultante. El servicio de sincronización en general no respeta los límites de la transacción. En otras palabras, si se hacen dos cambios a un almacén de datos de una plataforma de almacenamiento en una sola transacción, no existe garantía de que estos cambios son aplicados en todas las réplicas atómicamente - una se podría mostrar sin los otros cambios.

La excepción al principio es que si se hacen dos cambios a la misma Partida en la misma transacción, entonces estos cambios están garantizados para ser enviados y aplicados a otras réplicas atómicamente. Por lo tanto, las Partidas son 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 sync. Dicha aplicación proporciona todos los parámetros necesarios para realizar la sincronización (ver perfil sync más adelante). A dichas aplicaciones nos referimos en la presente descripción como Aplicaciones de Control Sync (SCAs). Cuando se están sincronizando dos casos de plataforma de almacenamiento, la sicronización es inicializada en un lado por un SCA. El SCA informa al servicio de sincronización local para que se sincronice con el asociado remoto. Por otra parte, el servicio de sincronización es despertado por los mensajes enviados por el servicio de sincronización de la máquina que lo solicita. Este responde basado en la información de configuración persistente (ver mapeado más adelante) presente en la máquina de destino. El servicio de sincronización puede ser ejecutado en un programa o en respuesta a eventos. En estos casos, el servicio de sincronización que implementa el programa llega a ser un SCA. Para hacer posible la sincronización, se necesitan tomar dos pasos. Primero, el diseñador del esquema debe anotar el esquema de la plataforma de almacenamiento con semánticas de sincronización apropiadas (diseñando Unidades de Cambio, como se describe más adelante). Segundo, la sincronización debe de ser configurada de manera correcta en todas las máquina que tienen un caso de plataforma de almacenamiento que va a participar en la sincronización (como se describe más adelante). b) Anotaciones del Esquema Un concepto fundamental del servicio de sincronización es el de la unidad de cambio. Una unidad de cambio es la pieza más pequeña del esquema que es rastreada individualmente por la plataforma de almacenamiento. Por cada Unidad de Cambio, el servicio de sincronización puede determinar si ha cambiado o no desde la última sincronización . La designación de las Unidades de Cambio en el esquema sirve para varios propósitos. Primero, determina la vibración que tiene el servicio de sincronización en el cable. Cuando se hace un cambio dentro de una Unidad de Cambio, la Unidad de Cambio completa es enviada a las otras réplicas, ya que el servicio de sincronización no conoce qué parte de la Unidad de Cambio fue cambiada. Segundo, determina la granularidad de la detección del conflicto. Cuando se hacen dos cambios simultáneos (estos términos se definen detalladamente en secciones posteriores), a la misma Unidad de Cambio el servicio de sincronización origina un conflicto; por otra parte, si se hacen cambios simultáneos a diferentes Unidades de Cambio, entonces no se origina conflicto y los cambios son fusionados automáticamente. Tercero, afecta de manera fuerte la cantidad de metadatos mantenidos por el sistema. Muchos de los metadatos del servicio de sincronización son mantenidos por la Unidad de Cambio; por lo tanto, hacer más pequeñas las Unidades de Cambio aumenta la carga de la sincronización. La definición de las Unidades de Cambio requiere encontrar las negociaciones correctas. Por esta razón, el servicio de sincronización permite a los diseñadores del esquema a participar más en el proceso. En una modalidad, el servicio de sincronización no soporta Unidades de Cambio que sean más grandes que un elemento. Sin embargo, soporta la capacidad para que los diseñadores de esquema especifiquen Unidades de Cambio más pequeñas - - - es decir, que agrupen atributos múltiples de un elemento en una Unidad de Cambio separada. En esta modalidad, esto se logra utilizando la siguiente sintaxis: < Nombre del Tipo = "Appointment" MajorVersion = "1 " MinorVersion = "0" Extiende el Tipo ="Base. Item" Extiende la Versión <Nombre de Campo eetingStatus" Tipo = "Types.uniqueidentifier de la plataforma de almacenamiento se puede anular ="False'7> <Nombre del Campo = OrganizerName" Tipo = "Types.nvarchar(512) de la plataforma de almacenamiento se puede anular ="False"> <Nombre del Campo = OrganizerEmail" Tipo = "Types.nvarchar(512) de la plataforma de almacenamiento" TypeMajorVersion = "1" MultiValued = "True"/> <Nombre de la Unidad de Cambio ="CU_Status <Nombre del Campo =" eetingStatus" > </ChangeUnit> <Nombre de la Unidad de Cambio ="Organizer" <Nombre del Campo ="OrganizerName'7> <Nombre del Campo ="OrganizerEmail'7> </ChangeUnit> </Tipo> c) Configuración de Sincronización Un grupo de los asociados de la plataforma de almacenamiento que desea mantener ciertas partes de sus datos en sincronización es al que nos referimos como una comunidad de sincronización. Aunque los miembros de la comunidad desean permanecer en sincronización, necesariamente representan los datos exactamente del mismo modo, en otras palabras, los asociados de sincronización pueden transformar los datos que ellos están sincronizando. En un escenario de semejante-a-semejante, es práctico para los semejantes mantener mapeos de la transformación de todos sus asociados. En vez de ello, el servicio de sincronización toma el camino de definir "Carpetas de la Comunidad". Una carpeta de la comunidad es abstracción que representa una "carpeta compartida" hipotética con la que se están sincronizando todos los miembros de la comunidad. Esta noción se ilustra mejor por un ejemplo. Si Joe quiere mantener las carpetas de Mis Documentos de sus diferentes computadoras en sincronización, Joe define una carpeta de la comunidad, denominada, digamos, Documentos de Joe. Entonces, en cada computadora, Joe configura un mapeo entre la carpeta hipotética del Documento de Joe, y la carpeta local de Mis Documentos. Desde este punto en adelante, cuando las computadoras de Joe se sincronizan entre ellas, ellas hablan en términos de los documentos de Joe, en vez de sus partidas locales. De este modo, todas las computadoras de Joe se entienden entre ellas sin tener que conocer quienes son por - la Carpeta de la Comunidad llega a ser de lengua franca de la comunidad de sincronización. La configuración del servicio de sincronización consiste de tres pasos: (1) definir los mapeos entre las capetas locales y las carpetea de la comunidad, (2) definir los perfiles de sincronización que determinan qué va a ser sincronizado (por ejemplo, a quienes sincronizar con y cuales subconjuntos deben de ser enviados y cuales recibidos) y (3) definir los programas sobre los cuales deben de operar los diferentes perfiles de sincronización u operarlos manualmente. (1) Carpeta de la Comunidad - Mapeo Los mapeos de la Carpeta de la Comunidad son almacenados como archivos de configuración XLM en las máquinas individuales. Cada mapeo tiene el siguiente esquema: /mappings/communityFolder Este elemento designa la carpeta de la comunidad para la que está mapeando. El nombre sigue las reglas de sintaxis de las Carpetas. /mappings/LocalFolder Este elemento designa la carpeta local en la que está transformando el mapeo. El nombre sigue reglas de sintaxis de las Carpetas. La carpeta ya debe de existir para que el mapeo sea válido. Las partidas dentro de esta carpeta se consideran para la sincronización de acuerdo con este mapeo. /mappi'ngs/transformations Este elemento define como transformar las partidas de la carpeta de la comunidad en una carpeta local y viceversa. Si está ausente o vacío, no se realizan transformaciones. En particular, esto significa que ninguna ID es mapeada. Esta configuración es principalmente útil para crear una memoria instantánea de una Carpeta. /mappings/transformations/mapIDs Este elemento solicita que sean asignadas IDs locales generadas recientemente a todas las partidas mapeadas de la carpeta de la comunidad, en vez de volver a emitir las IDs de la comunidad. El tiempo de operación de sincronización mantendrá los mapeos de la ID para convertir las partidas hacia delante y hacia atrás. /mappings/transformations/localRoot Este elemento solicita que todas las partidas raíz de la carpeta de la comunidad se hagan descendientes de la raíz especificada. /mappings/runAs Este elemento controla bajo la autorización de quién se solicita que sea procesado este mapeo. Si está ausente, se supone un emisor. /mappings/runAs/sender La presencia de este elemento indica que el emisor de los mensajes para este mapeo debe de ser personificado, y solicita que sea procesado bajo sus credenciales. (2) Perfiles Un perfil de sincronizaciones es un conjunto total de parámetros necesarios para iniciar la sincronización. Debe de ser suministrado por un SCA al tiempo de Operación de Sincronización para iniciar la sincronización. Los perfiles de sincronización para la sincronización de plataforma-dealmacenamiento-a-plataforma-de-almacenamiento contienen la siguiente información: Carpeta Local, para servir como fuente y destino para los cambios; Nombre de la Carpeta Remota para sincronizarla con - esta carpeta debe de ser publicada desde el asociado remoto por medio de un mapeo, tal y como se definió anteriormente; Dirección - el servicio de sincronización soporta una sincronización solo de enviar, solo de recibir y de enviar y recibí r; Filtro Local - selecciona que información enviar al asociado remoto. Expresada como la solicitud de la plataforma de almacenamiento sobre la carpeta local; Filtro Remoto - selecciona que información remota recuperar del asociado remoto - expresada como la solicitud de la plataforma de almacenamiento sobre la carpeta de la comunidad ; Transformaciones - define como transformar las partidas en, desde el formato remoto; Seguridad local - específica si los cambios recuperados del punto final remoto van a ser aplicados bajo los permisos del punto final remoto (personificados), o el usuario que inicie localmente la sincronización; y Política de resolución de conflictos - - - especifica si los conflictos deben de ser rechazados, registrados o solucionados automáticamente - en este último caso, específica qué conflictos utilizará el solucionador, así como los parámetros de configuración para el mismo. El servicio de sincronización proporciona una clase CLR de tiempo de ejecución que permite la construcción simple de los perfiles de sincronización. Los perfiles también pueden ser serializados desde los archivos XML para un almacenamiento fácil (con frecuencia los programas juntos). Sin embargo, no existe lugar estándar en la plataforma de almacenamiento en donde se han almacenado todos los perfiles; los SCAs son bienvenidos para construir el perfil en el punto sin hacerlo persistir. Observar que no existe la necesidad de tener un mapeo local para iniciar la sincronización. Toda la información de sincronización puede ser especificada en el perfil. Sin embargo, se requiere el mapeo con el objeto de resolver a las solicitudes de sincronización iniciadas por el lado remoto. (3) Programas En una modalidad, el servicio de sincronización, no proporciona su propia estructura de programación. En vez de ello, depende de otro componente para realizar esta tarea -el programador Windows disponible con el sistema operativo Microsoft Windows. El servicio de sincronización incluye una utilidad de línea de comandos que actúa como un SCA u detona la sincronización basada en un perfil de sincronización guardado en un archivo XML. Esta utilidad hace muy fácil configurar el Programador de Windows para ejecutar la sincronización, ya sea en el programa o en respuesta a eventos tales como registros o cancelaciones de registro del usuario. d) Manejo de Conflictos El manejo de conflictos en el servicio de sincronización es dividido en tres etapas: (1) la detección del conflicto, la cual ocurre en el tiempo de aplicación del cambio - este paso determina si puede ser aplicado un cambio de manera segura; (2) la resolución automática y registro del conflicto- durante este paso (que tiene lugar inmediatamente después de que es detectado el conflicto), los solucionadores automáticos de conflicto son consultados para ver si ei conflicto puede ser solucionado - si no es así, el conflicto puede ser registrado opcionalmente; y (3) inspección y solución de conflictos este paso tiene lugar si han sido registrados algunos conflictos y ocurren fuera del contexto de la sesión de sincronización - en este momento, los conflictos registrados pueden ser solucionados y eliminados del registro. (1) Detección de Conflictos En la presente modalidad, el servicio de sincronización detecta dos tipos de conflicto: basados en el conocimiento y basados en la restricción. (a) Conflictos Basados en el Conocimiento Un conflicto basado en el conocimiento ocurre cuando dos réplicas hacen cambios independientes a alguna Unidad de Cambio. Se dice que son independientes dos cambios si se hacen sin el conocimiento del otro - en otras palabras, la versión de un primero no es recuperada por el conocimiento del segundo y viceversa. El servicio de sincronización detecta automáticamente todos dichos conflictos basado en el conocimiento de las réplicas, tal y como se describieron anteriormente. Algunas veces es útil considerar los conflictos como confluencias de la historia de la versión de una Unidad de Cambio. Si no ocurren conflictos en la vida de una Unidad de Cambio. Su historia de la versión es una cadena simple -cada cambio que ocurre después de uno anterior. En el caso de un conflicto basado en el conocimiento, ocurren dos cambios en paralelo, ocasionando que la cadena se divida y llegue a ser un árbol de versión. (b) Conflictos Basados en las Restricciones Existen casos en donde los cambios independientes violan una restricción de integridad cuando son aplicados juntos. Por ejemplo, dos réplicas que crean un archivo con el mismo nombre en el mismo directorio ocasionarían que ocurriera dicho conflicto. Un conflicto basado en las restricciones comprenden dos cambios independientes (justamente como uno basado en el conocimiento), pero ellos no afectan la misma Unidad de Cambio. En vez de ello, afectan diferentes Unidades de Cambio, pero con una restricción insistente entre ellas. El servicio de sincronización detecta las violaciones de las restricciones en el momento de la aplicación de cambios, y origina automáticamente los conflictos basados en las restricciones. La solución de los conflictos basados en las restricciones requieren generalmente un código de personalización que modifica el cambio de un modo tal que no viole las restricciones; el servicio de sincronización no proporciona un mecanismo para uso general para hacerlo de este modo. (2) Procesamiento de Conflictos Cuando un conflicto es detectado, el servicio de sincronización puede tomar una de tres acciones (seleccionadas por el iniciador de sincronización en el perfil de sincronización): (1) rechazar el cambio, regresándolo al emisor; (2) registrar un conflicto en un registro de conflictos; ó (3) solucionar el conflicto automáticamente. Si el cambio es rechazado, entonces el servicio de sincronización actúa como si el cambio no hubiera llegado en la réplica. Un conocimiento negativo se envía de vuelta al que lo originó. Esta política de resolución es principalmente útil en las réplicas sin cabeza (tales como los servidores de archivo) en donde el registro de conflictos no es posible. En vez de ello, dichas reglas fuerzan a los otros a tratar con los conflictos rechazándolos. Los iniciadores de sincronización configuran la solución de conflictos en sus perfiles de sincronización. El servicio de sincronización soporta la combinación de múltiples solucionadores de conflictos en un solo perfil de las siguientes maneras - primero, especificando una lista de solucionadores de conflictos para que sean probados después de otros, hasta que uno de ellos tiene éxito; y segundo, asociando los solucionadores de conflictos con los tipos de conflicto; es decir dirigiendo los conflictos basados en el conocimiento de actualización a actualización a un solucionador, pero todos los otros conflictos al registro, (a) Solución Automática de Conflictos El servicio de sincronización proporciona un número de solucionadores de conflictos por omisión (default). Esta lista incluye: • ganadores locales: ignora los cambios entrantes si están en conflicto con los datos almacenados localmente; • ganadores remotos: ignora los datos locales si están en conflicto con los cambios entrantes; • ganadores del último escritor. Seleccionan ya sea los ganadores locales o los ganadores remotos por Unidad de Cambio basados en el sello del tiempo de cambio (observar que el servicio de sincronización en general no depende de valores de reloj; este solucionador de conflictos es la única excepción a esa regla); • Determinantes: seleccionan un ganador de una manera que está garantizada que sea el mismo en todas las réplicas, pero que de otra manera no es importante - una modalidad de los servicios de sincronización utiliza comparaciones lexicográficas en las IDs de los asociados para implementar esta característica. Además, las ISVs pueden implementar e instalar su propio solucionador de conflictos. Los solucionadores de conflictos personalizados pueden aceptar parámetros de configuración; dichos parámetros deben de ser especificados por SCA, en la sección de resolución de conflictos de perfil de sincronización.

Cuando un solucionador de conflictos maneja un conflicto, regresa a la lista de operaciones que necesitan ser realizadas (en vez del cambio en conflicto) de regreso al tiempo de ejecución. El servicio de sincronización entonces aplica estas operaciones, teniendo ajustado correctamente el conocimiento remoto para incluir cual manejador de conflictos ha sido considerado. Es posible que otros conflictos sean detectados mientras se aplica la solución. En dicho caso, debe de ser solucionado un conflicto nuevo antes que el procesamiento original se vuelva a asumir. Cuando se piensa de los conflictos como ramificaciones de la historia de la versión de una partida, las soluciones del conflicto pueden ser vistas como uniones - - - combinando dos ramificaciones para formar un solo punto. Por lo tanto, las soluciones de conflictos se vuelven historias de la versión dentro de los DAGs. (b) Registro de Conflictos Un tipo muy particular de un solucionador de conflictos es ConflictLogger. El servicio de sincronización registra los conflictos como partidas del tipo ConflictRecord. Estos registros se vuelven a relacionar con las partidas que están en conflicto (a menos que las partidas mismas hayan sido eliminadas). Cada registro de conflicto contiene: el cambio entrante que ocasionó el conflicto; el tipo de conflicto: actualización-actualización, actualización-eliminación, eliminación-actualización, insertar-insertar, 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 la inspección y solución, tal y como se describe más adelante. (c) Inspección y Solución de Conflictos El servicio de sincronización proporciona una API para aplicaciones para examinar el registro de conflictos y sugerir soluciones de los conflictos que se encuentran en la misma. La API permite que la aplicación enumere todos los conflictos o los conflictos relacionados con una partida determinada. También permite que dichas aplicaciones solucionen los conflictos registrados de una de tres maneras: (1) ganadores remotos - - - aceptando el cambio registrado y volviendo a escribir el cambio local en conflicto; (2) ganadores locales - -- ignorando las partes en conflicto el cambio registrado; (3) sugiere cambios nuevos - - - en donde la aplicación propone una fusión que, en su opinión, soluciona el conflicto. Una vez que son solucionados los conflictos por una aplicación, el servicio de sincronización los elimina del registro. (d) Convergencia de Réplicas y Propagación de Soluciones de Conflictos En escenarios complejos de sincronización, el mismo conflicto puede ser detectado en múltiples réplicas. Si esto ocurre, pueden suceder varias cosas: (1) el conflicto puede ser solucionado en una réplica y la solución será enviada a la otra; (2) el conflicto es solucionado en ambas réplicas automáticamente o (3) el conflicto es solucionado en ambas réplicas manualmente (a través de la API de inspección de conflictos). Para asegurar la convergencia, el servicio de sincronización envía las soluciones de los conflictos a las otras réplicas. Cuando un cambio que soluciona un conflicto llega a una réplica, el servicio de sincronización encuentra automáticamente en el registro cualesquiera registros del conflicto que son solucionados por esta actualización y los elimina. En este sentido, una solución de conflicto en una réplica se está enlazando a todas las otras réplicas. Si se seleccionan ganadores diferentes por réplicas diferentes para el mismo conflicto, el servicio de sincronización aplica el principio de enlace de la solución del conflicto y recolecta una de las dos soluciones para que gane sobre la otra automáticamente. El ganador es recolectado de un modo determinante que está garantizado que produce los mismos resultados en todo momento (una modalidad utiliza comparaciones lexicográficas de la ID de la réplica). Si se sugieren "nuevos cambios" diferentes para réplicas diferentes para el mismo conflicto, el servicio de sincronización trata este nuevo conflicto como un conflicto especial, y utiliza el Registrador de Conflictos para evitar que se propague a otras réplicas. Esta situación se origina generalmente con la solución manual de conflictos. 2. Sincronización para Almacenes de Datos de la Plataforma que no son de Almacenamiento De acuerdo con otro aspecto de la plataforma de almacenamiento de la presente invención, la plataforma de almacenamiento proporciona una arquitectura para que la ISVs implemente los Adaptadores de Sincronización que permiten que la plataforma de almacenamiento sincronice los sistemas de herencia, tales como el Microsoft Exchange, AD, Hotmail. Los Adaptadores de Sincronización se benefician de muchos servicios de sincronización proporcionados por el servicio de sincronización, tal y como se describe más adelante. No obstante el nombre, los Adaptadores de Sincronización no necesitan ser implementados como programas auxiliares en la arquitectura de alguna plataforma de almacenamiento. Si se desea, un "adaptador de sincronización" puede ser simplemente cualquier aplicación que utiliza las interfases del tiempo de ejecución del servicio de sincronización para obtener servicios, tales como la enumeración y aplicación de cambios. Con el objeto de hacer más fácil que otros configuren y ejecuten la sincronización hasta un extremo para un fin determinado, los escritores del Adaptador de Sincronización son alentados para exponer la interfase estándar del Adaptador de Sincronización, la cual ejecuta la sincronización determinada por el Perfil de Sincronización, tal y como se describió anteriormente. El perfil proporciona información de configuración al adaptador y algunos de dichos adaptadores pasan el Tiempo de Ejecución de Sincronización a los servicios de tiempo de ejecución de control (es decir, la carpeta que se va a sincronizar). a) Servicio de Sincronización El servicio de sincronización proporciona un número de servicios de sincronización para los escritores de un adaptador. Para el resto de esta sección, es conveniente referirnos a la máquina en la cual está haciendo la sincronización la plataforma de almacenamiento como el "cliente", y el extremo posterior de la plataforma que no es de almacenamiento a la que está hablando el adaptador como el "servidor". (1) Enumeración de Cambios Basados en los datos de rastreo de cambios mantenidos por el servicio de sincronización, la Enumeración de Cambios permiten que los adaptadores de sincronización enumeren fácilmente los cambios que han ocurrido a una carpeta del almacén de datos desde la última vez que se intentó la sincronización con este asociado.

Los cambios son enumerados basados en el concepto de una "ancla" - - - una estructura opaca que representa la información acerca de la última sincronización. El ancla toma la forma del conocimiento de la plataforma de almacenamiento como se describió en las secciones anteriores. Los adaptadores de sincronización que utilizan el servicio de la enumeración del cambio, se encuentran en dos categorías amplias. Aquellos que utilizan "anclas almacenadas" contra aquellos que utilizan "anclas suministradas". La distinción está basada en donde es almacenada la información acerca de la última sincronización - - - en el cliente o en el servidor. Con frecuencia es más fácil para los adaptadores almacenar esta información en el cliente - - - el extremo posterior con frecuencia no tiene la capacidad de almacenar de manera conveniente esta información. Por otra parte, si clientes múltiples se sincronizan con el mismo extremo posterior, el almacenamiento de esta información en el cliente es deficiente y en algunos casos incorrecto - - -hace que un cliente no esté advertido de los cambios que ya ha impulsado el otro cliente para el servidor. Si un adaptador quiere utilizar un ancla almacenada en el servidor, el adaptador necesita volverlo a suministrar a la plataforma de almacenamiento en el momento de la enumeración del cambio.

Con el objeto de que la plataforma de almacenamiento mantenga el ancla (ya sea para el almacenamiento local o remoto), la plataforma de almacenamiento necesita estar advertida de los cambios que fueron aplicados de manera exitosa en el servidor. Estos y solamente estos cambios pueden estar incluidos en el ancla. Durante la enumeración del cambio, los Adaptadores de Sincronización utilizan la interfase de Acuse de Recibo para reportar qué cambios fueron aplicados de manera exitosa. En el extremo de sincronización, los adaptadores que utilizan las anclas suministradas deben de leer el ancla nueva (la cual incorpora todos los cambios aplicados de manera exitosa) y enviarlos a su extremo posterior. Con frecuencia, los Adaptadores necesitan almacenar datos específicos del adaptador junto con las partidas que se insertan dentro del almacén de datos de la plataforma de almacenamiento. Los ejemplos comunes de dichos datos son las IDs remotas y las versiones remotas (sellos de tiempo). El servicio de sincronización proporciona un mecanismo para almacenar estos datos y la Enumeración de Cambios proporciona un mecanismo para recibir estos datos extra junto con los cambios que están siendo regresados. En la mayoría de los casos, esto elimina la necesidad de que los adaptadores vuelvan a hacer solicitudes a la base de datos. (2) Aplicación del Cambio La Aplicación del Cambio permite que los Adaptadores de Sincronización apliquen cambios recibidos de sus extremos posteriores a la plataforma de almacenamiento local. Se espera que los adaptadores transformen los cambios al esquema de la plataforma de almacenamiento. La figura 24 ilustra el proceso por medio del cual son generadas las clases de la API de la plataforma de almacenamiento del esquema de la plataforma de almacenamiento. La función principal de la aplicación de cambios es detectar automáticamente los conflictos. Como en el caso de la sincronización de Plataforma-de-Almacenamiento-a-Plataforma-de-Almacenamiento, un conflicto es definido como dos cambios que se están haciendo, los cuales se traslapan sin el conocimiento entre ellos. Cuando los adaptadores utilizan la Aplicación de Cambio deben de especificar el ancla con respecto a la cual se realizó la detección del conflicto. La Aplicación de Cambio origina un conflicto si el cambio local que se traslapa no está cubierto por el conocimiento del adaptador en el que es detectado. De un modo similar a la Enumeración de Cambios los adaptadores pueden utilizar, ya sea anclas almacenadas o suministradas. La Aplicación de Cambio soporta el almacenamiento eficiente de los metadatos específicos del adaptador. Dichos datos pueden ser adjuntados por el adaptador a los cambios que están siendo aplicados y podrían ser almacenados por el servicio de sincronización. Los datos podrían ser regresados en la siguiente enumeración de cambio. (3) Solución de Conflictos El mecanismo de Solución de Conflictos descrito anteriormente (opciones de registro y solución automática) está disponible también para los adaptadores de sincronización. Los adaptadores de sincronización pueden especificar la política para la solución del conflicto cuando se aplican los cambios. Si está especificado, los conflictos pueden ser pasados al manejador de conflictos especificado y solucionados (de ser posible). Los conflictos pueden ser registrados. Es posible que el adaptador pueda detectar un conflicto cuando intenta aplicar un cambio local al extremo posterior. En dicho caso, el adaptador todavía puede pasar el conflicto al tiempo de ejecución de sincronización para que sea solucionado de acuerdo con la política. Además, los Adaptadores de Sincronización pueden solicitar que cualesquiera conflictos detectados por el servicio de sincronización se envíen de regreso a ellos para el procesamiento. Esto es particularmente conveniente en el caso en donde el extremo posterior tiene la capacidad de almacenar y solucionar conflictos. (b) Implementación del Adaptador Aunque algunos "adaptadores" son aplicaciones que utilizan simplemente interfases del tiempo de ejecución, los adaptadores son alentados para implementar interfases de estándar del adaptador. Estas interfases permiten que las aplicaciones que controlan la sincronización: soliciten que el adaptador realice la sincronización de acuerdo con el perfil de sincronización determinado, cancele la sincronización en progreso, y reciba un reporte del progreso (porcentaje completado) en una sincronización en progreso. 3. Seguridad El servicio de sincronización se esfuerza por introducir tan pocos modelos de seguridad como sean posibles implementados por la plataforma de almacenamiento. En vez de definir nuevos derechos para la sincronización, se utilizan los derechos existentes. Específicamente, • nadie que pueda leer una Partida del almacén de datos puede enumerar los cambios a esa partida; • cualquiera que pueda escribir en una partida del almacén de datos puede aplicar cambios a esa partida; y • cualquiera que pueda extender una partida del almacén de datos puede asociar metadatos de sincronización con esa partida. El servicio de sincronización no mantiene información segura acerca de la autoría. Cuando se hace un cambio en la réplica A por el usuario U y es enviado a la réplica B, se pierde el hecho de que el cambio fuera originalmente hecho en A (o por U). Si B envía este cambio a la réplica C, esto se hace bajo la autorización de los Bs, y no del A. Esto conduce a la siguientes limitación: si una réplica no es confiada para hacer sus propios cambios a una partida, no puede enviar los cambios hechos por otros. Cuando el servicio de sincronización es iniciado, esto se hace por medio de la aplicación del control de sincronización. El servicio de sincronización personifica la identidad de SCA y realiza todas las operaciones (tanto localmente como de manera remota) bajo esta identidad. Para ilustrarlo, observar que el usuario U puede ocasionar que el servicio de sincronización local recupere los cambios de una plataforma de almacenamiento remota para las partidas a las que el usuario U para leerlas. 4. Capacidad de Administración El monitoreo de una comunidad distribuida de réplica es un problema complejo. El servicio de sincronización puede utilizar un algoritmo de "barrido" para recolectar y distribuir la información más cercana de las condiciones de las réplicas. Las propiedades del algoritmo de barrido aseguran que la información acerca de todas las réplicas configuradas sea recolectada finalmente y que sean detectadas las réplicas que están fallando (las que no tienen capacidad de respuesta).

Esta información de monitoreo en toda la comunidad se pone disponible en cada réplica. Las herramientas de monitoreo pueden ser ejecutadas en una réplica seleccionada arbitrariamente para examinar esa información de monitoreo, y tomar las decisiones administrativas. Cualesquiera cambios en la configuración se deben de hacer directamente en las réplicas afectadas. B. REVISIÓN GENERAL DE LA API DE SI CRO IZACIÓN En un mundo digital crecientemente distribuido, los individuos y grupos de trabajo con frecuencia almacenan información y datos en una variedad de dispositivos y localizaciones diferentes. Esto ha impulsado el desarrollo de servicios de sincronización de datos que puedan mantener la información en estos almacenes de datos separados, con frecuencia disparatados, sincronizados en todo momento, con una intervención mínima del usuario. La plataforma de sincronización de la presente invención, la cual es parte de una plataforma de almacenamiento rica descrita en la Sección 11 en esta descripción (a.k.a., "WinFS"), aborda tres objetivos principales. • Permite que las aplicaciones y servicios sincronicen los datos de manera eficiente entre almacenes "WinFS" diferentes. · Hace posible que los desabolladores construyan soluciones ricas para los datos de sincronización entre los almacenes "WinFS" y que no son "WinFS". • Proporciona los desabolladores interfases apropiadas para personalizar la experiencia del usuario de sincronización. 1. Terminología General En lo sucesivo se presentan algunas definiciones adicionales refinadas y conceptos clave importantes para las explicaciones posteriores de esta sección III. B: Réplica de Sincronización: La mayor parte de las aplicaciones están interesadas solamente en el rastreo, enumeración y sincronización de cambios para un subconjunto de partidas determinado dentro del almacén WinFS. El conjunto de partida que forma parte de una operación de sincronización es denominado como una réplica de sincronización. Una réplica es definida en términos de partidas contenidas dentro de una jerarquía de contención WinFS determinada (generalmente enraizada en una partida de carpeta). Todos los servicios de sincronización se llevan a cabo dentro del contexto de una réplica determinada. La sincronización WinFS proporciona un mecanismo para definir, administrar y eliminar las réplicas. Cada réplica tiene un identificador GU1D que la identifica de manera exclusiva dentro de un almacén WinFS determinado.

Asociado de Sincronización: Un asociado de sincronización es definido como una entidad que tiene la capacidad de efectuar cambios en las partidas, extensiones y relaciones WinFS. Por lo tanto, cada almacén WinFS puede ser denominado como un asociado de sincronización. Cuando se está sincronizando con un almacén que no es WinFS, la fuente de datos externa (EDS) también es denominada como socio de sincronización. Cada asociado tiene un GUID identificador que lo identifica de manera exclusiva. Comunidad de Sincronización: Una comunidad de sincronización es definida como una colección de réplicas que son mantenidas en sincronización por medio de operaciones de sincronización de semejante-a-semejante. Estas réplicas pueden estar todas en el mismo almacén WinFS, o en almacenes WinFS diferentes, o manifestarse ellas como réplicas virtuales en almacenes que no son WinFS. La sincronización WinFS no prescribe o manda topología específica alguna para la comunidad, especialmente si sólo las operaciones de sincronización de la comunidad son a través del servicio de sincronización WinFS (adaptador WinFS). Los adaptadores de sincronización (que se definen más adelante) pueden introducir sus propias restricciones de topología. Rastreo de Cambios, Unidades de Cambio y Versiones: Cada almacén WinFS rastrea los cambios para todas las Partidas WinFS, Extensiones y Relaciones locales. Los cambios son rastreados en el nivel de la granularidad de la unidad de cambio definida en el esquema. Los cambios de nivel alto de cualquier Partida, Extensión y Tipo de Relación pueden ser subdivididos por el diseñador del esquema en unidades de cambio, siendo la granularidad más pequeña una en el campo de nivel superior. Para propósitos del rastreo de cambios, cada unidad de cambio tiene asignada una Versión, en donde una versión es un par de identificaciones de asociados de sincronización y un número de versión (el número de versión es un número creciente monotónicamente específico del asociado). Las versiones son actualizadas conforme ocurren los cambios en el almacén localmente, o conforme son obtenidas de otras réplicas. Conocimiento de Sincronización: El conocimiento representa la condición de una réplica de sincronización determinada en cualquier momento, es decir, encapsula los metadatos acerca de todos los cambios de que está advertida una réplica determinada, ya sea locales o provenientes de otras réplicas. La sincronización WinFS mantiene y actualiza el conocimiento para las réplicas de sincronización en las operaciones de sincronización. Una cosa importante que se debe observar, es que la representación del conocimiento permite que sea interpretado con respecto a la comunidad completa y no solamente en relación con la réplica particular en donde está almacenado el conocimiento. Adaptadores de Sincronización: Un adaptador de sincronización es una aplicación de código administrada que tiene acceso a los servicios de Sincronización WinFS a través de la API del Tiempo de Ejecución de Sincronización y hace posible la sintonización de los datos WinFS, en almacenes de datos que no son WinFS. Dependiendo de los requerimientos del escenario, el desarrollador del adaptador es el que decide qué subconjunto de datos WinFS y qué tipos de datos WinFS sincronizar. El adaptador es responsable de la comunicación con los EDS, transformando los esquemas WinFS a y para esquemas soportados por EDS, y definiendo y administrando su propia configuración y metadatos. Los adaptadores son alentados fuertemente para implementar la API del adaptador de sincronización WinFS para aprovechar la configuración común y la infraestructura de control para los adaptadores, proporcionada por el equipo de sincronización WinFS. Para más detalles, favor de referirse a la especificación de la API del Adaptador de Sincronización WinFS [SADP], y a la especificación de la API del Controlador de Sincronización [SCT L]. Para los adaptadores que sincronizan los datos WinFS para almacenes externos que no son WinFS y no pueden producir o mantener el conocimiento en el formato WinFS, la sincronización WinFS proporciona servicios para obtener el conocimiento remoto que puede ser utilizado para la enumeración de cambios o operaciones posteriores de la aplicación. Dependiendo de las capacidades del almacenamiento de extremo posterior, el adaptador puede desear almacenar este conocimiento remoto en el extremo posterior o en el almacén WinFS local. Por razones de simplicidad, una "réplica" de sincronización es una estructura que representa el conjunto de datos en un almacén "WinFS" que existe en una sola localización lógica, mientras que los datos en un almacén que no es "WinFS", es denominada una "fuente de datos" y generalmente requiere el uso de un adaptador. Conocimiento Remoto: Cuando una réplica de sincronización determinada desea tener cambios de otra réplica proporciona su propio conocimiento como una línea base contra la cual enumera los cambios la otra réplica. De un modo similar, cuando una réplica determinada desea enviar cambios a otra réplica, proporciona su propio conocimiento como una línea básica, la cual puede ser utilizada por la réplica remota para detectar conflictos. Este conocimiento acerca de la otra réplica que es proporcionado durante la enumeración de cambio de sincronización y la aplicación, es denominada un conocimiento remoto. 2. Conceptos Principales de la API de Sincronización Para ciertas modalidades, la API de sincronización se separa en dos partes: la API de configuración de sincronización y la API del controlador de sincronización. La API de configuración de sincronización hace posible que las aplicaciones configuren la sincronización, y que especifiquen parámetros para una sesión particular de sincronización entre dos réplicas. Para una sesión de sincronización determinada, los parámetros de configuración incluyen el conjunto de Partidas que va a ser sincronizado, el tipo de sincronización (de una vía o de dos vías), la información acerca de la fuente de datos remota y la política de solución de conflictos. La API del controlador de sincronización inicia una sesión de sincronización, cancela la sincronización y recibe información de progreso y error acerca de la sincronización en marcha. Además, para modalidades específicas en donde la sincronización necesita ser realizada en un programa previamente determinado, dichos sistemas pueden incluir un mecanismo de programación para personalizar la programación. Varias modalidades de la presente invención, emplean adaptadores de sincronización para sincronizar la información entre las fuentes de datos "WinFS" y que no son "WinFS". Los ejemplos de los adaptadores incluyen un adaptador que sincroniza la información del libro de direcciones entre una carpeta de contacto "WinFS" y un buzón que no es WinFS. En estos casos, los desabolladores del adaptador podrían utilizar la API de servicios del núcleo de sincronización "WinFS" aquí descrito, para tener acceso a los servicios proporcionados por la plataforma de sincronización "WinFS", con el objeto de desarrollar el código de transformación de esquema entre el esquema " WinFS" y el esquema de la fuente de datos que no es "WinFS". Adicionalmente, el desarrollador del adaptador proporciona un soporte de protocolo para comunicar los cambios a la fuente de datos que no son WinFS". Un adaptador de sincronización es invocado y controlado mediante el uso de la API del controlador de sincronización y reporta el progreso y los errores utilizando esta API. Sin embargo, para ciertas modalidades de la presente invención, cuando se efectúa la sincronización del almacén de datos de sincronización "WinFS" con otro almacén de datos "WinFS", puede ser innecesario un adaptador de sincronización, si los servicios de sincronización de "WinFS" a "WinFS" están integrados dentro del sistema de interfase de hardware/software. En cualquier caso, varias de dichas modalidades proporcionan un conjunto de servicios de sincronización, tanto para la sincronización de "WinFS" a "WinFS", como para las soluciones del adaptador de sincronización que incluyen: • El rastreo de cambios para las partidas, extensiones y relaciones "WinFS".

• El soporte para la enumeración de cambios crecientemente incremental eficiente desde una condición pasada determinada. • La aplicación de cambios externos a "WinFS". · El manejo de conflictos durante la aplicación del cambio. Haciendo referencia a la figura 36, la cual ilustra tres casos de un almacén de datos común y los componentes para sincronizarlos. Un primer sistema 3602 tiene un almacén de datos WinFS 3612 que comprende servicios de sincronización de WinFS a WinFS 3622 y Servicio de Sincronización del Núcleo 3624, para la sincronización de WinFS con los que no son WinFS, el cual expone 3646 una API de Sincronización 3652 para su utilización. Similar al primer sistema 3602, el segundo sistema 3604 tiene un almacén de datos WinFS 3614 que comprende servicios de sincronización de WinFS a WinFS 3632, y Servicio de Sincronización del Núcleo 3634, para la sincronización de WinFS a una que no es WinFS, la cual expone 3646, una API de Sincronización 3652 para la utilización. El primer sistema 3602 y el segundo sistema 3604 sincronizan 3642 por medio de sus servicios de sincronización de WinFS a WinFS respectivos 3622 y 3632. Un tercer sistema 3606, el cual no es un sistema WinFS tiene una aplicación para utilizar la sincronización WinFS 3666 para mantener la fuente de datos en una comunidad de sincronización con la réplica de WinFS. Esta aplicación puede utilizar, ya sea el servicio de Control/Configuración de Sincronización WinFS 3664 para hacer interfase directamente con el 3644 con el almacén de datos WinFS 3612 por medio de los servicios de sincronización de WinFS a WinFS 3622, (si tiene la capacidad de virtualizarse ella misma como un almacén de datos WinFS) o por medio de un adaptador de sincronización 3662 que hace interfase 3648 con la API de sincronización 3652. Como se ilustra en esta figura, el primer sistema 3602 está advertido de y se sincroniza directamente con ambos el segundo sistema 3604 y el tercer sistema 3606. Sin embargo, ni el segundo sistema 3604 ni el tercer sistema 3606 están advertidos entre ellos, y por lo tanto, no sincronizan sus cambios directamente entre ellos, sino en vez de eso, los cambios que ocurren en un sistema deben de propagarse a través del primer sistema 3602. C. SERVICIOS DE LA API DE SINCRO IZACIÓN Varias modalidades de la presente invención están enfocadas hacia los servicios de sincronización que comprenden dos servicios fundamentales: la enumeración de cambios y la aplicación de cambios. 1. Enumeración de Cambios Como se describió anteriormente en este documento, la enumeración de cambios permite que los adaptadores de sincronización enumeren fácilmente los cambios que han ocurrido a la Carpeta del almacén de datos desde el último momento que se intentó la sincronización con este asociado, basada en los datos de rastreo de cambios mantenidos por el servicio de sincronización. Con respecto a la enumeración de cambios, varias modalidades de la presente invención están enfocadas en: • la enumeración eficiente de los cambios a las Partidas, Extensiones y Relaciones en una réplica determinada, en relación con un caso de conocimiento especificado. • la enumeración de cambios en el nivel de la granularidad de la unidad de cambios especificada en los esquemas WinFS. • el agrupamiento de cambios enumerados en términos de partidas compuestas. Una partida compuesta consiste de una partida, todas sus extensiones, todas sus relaciones de posesión para las partidas y todas las partidas compuestas que corresponden a sus partidas incrustadas. Los cambios a las relaciones de referencia entre las partidas son enumerados por separado. • la formación de lotes en la enumeración de cambio. La granularidad del lote es una partida compuesta o un cambio de relación (para relaciones de referencia). • la especificación de filtros sobre las partidas en las réplicas durante la enumeración de cambios, es decir, la réplica consiste de todas las partidas de una carpeta determinada, pero para esta enumeración de cambio en particular, a la aplicación le gustaría no solamente enumerar los cambios a todas las partidas de Contacto en donde el primer nombre inicia con una 'A' (este soporte debe de ser agregado posterior al evento importante B). • el uso del conocimiento remoto para los cambios enumerados, con la capacidad para registrar unidades de cambio individuales (para partidas completas, extensiones o relaciones), como la sincronización que ha fallado en el conocimiento, como para hacer que se vuelvan a enumerar en la siguiente oportunidad. • el uso de adaptadores avanzados que pueden tener la capacidad para entender los metadatos de sincronización WinFS, regresando los metadatos junto con los cambios durante la enumeración del cambio. 2. Aplicación de Cambios Como se explicó anteriormente en este documento, la aplicación de cambios permite que los Adaptadores de Sincronización apliquen los cambios recibidos de su extremo posterior a la plataforma de almacenamiento local, ya que se espera que los adaptadores transformen los cambios en el esquema de la plataforma de almacenamiento. Con respecto a la aplicación de cambios, varias modalidades de la presente invención están enfocadas en: • la aplicación de cambios increméntales de otras réplicas (o almacenes que no son WinFS), con las actualizaciones correspondientes a los metadatos de cambio WinFS. • la detección de conflictos en la aplicación de cambios en la granularidad de la unidad de cambio. • el reporte del éxito, falla y conflicto en el nivel de unidad de cambio individual en la aplicación de cambios, de modo que las aplicaciones (incluyendo los adaptadores y las aplicaciones del control de sincronización) pueden utilizar esta información para el reporte del progreso, error y condición y para actualizar su condición del extremo posterior, si existe. • la actualización del conocimiento remoto durante la aplicación de cambio como para prevenir el "reflejo" en la aplicación que suministró los cambios durante la siguiente operación de enumeración de cambios. • el uso de adaptadores avanzados que tienen la capacidad para entender y proporcionar metadatos de Sincronización WinFS junto con los cambios. 3. Código de Muestra El siguiente es un código de muestra de la forma en que un adaptador de sincronización FOO podría interactuar con el tiempo de ejecución de sincronización (en donde todas las funciones específicas del adaptador tienen el prefijo FOO): ItemContext ctx = nuevo ItemContext (\\Svstem\UserData\dshah\Mv Contacts". verdadero); // Obtener la id de la partida de réplica y la id del asociado remoto del perfil. // La mayor parte de los adaptadores obtendrían esta información del perfil de sincronización Guid replicaltemld = FOO_GetReplicald(); Guid remotePartnerld = FOO_Get_RemotePartnerld(); // // Consultar el conocimiento almacenado en el almacén utilizando storedKnowledgeld igual que en el anterior. // ReplicaKnowledge remoteKnowledge = . . . .; // // Inicializar ReplicaSynchronizer; // ctx.RepIicaSynchronizer = nuevas ReplicaSynchronizer( re plica Item Id, remotePartnerld; ctx.RepIicaSynchronizer. RemoteKnowledge = remoteKnowledge; ChangeRander reader = ctx. ReplicaSynchronizer.GetChangeReader(); // // Enumera los cambios y los procesa. // bool bChangesToRead = verdadero; mientras (bChangesToRead). { Cambios en la Collection<object> changes = nulos; bChangesToRead = reader. ReadChanges(10 cambios fuera); por cada (cambio de objeto en los cambios) { // Se procesa el objeto enumerado, el adaptador hace su propio esquema de transformación // y se mapea la ID. Y todavía se pueden recuperar objetos adicionales de // Ctx para este propósito y el adaptador modifica los metadatos después que un cambio // ha sido aplicado al almacén remoto.

Condición ChangeStatus status = FOOProcessAndApplyToRemoteStore(change); // Actualiza el conocimiento aprendido por la condición reader.AcknowledgeChange (changeStatus); } } remoteKnowledge -ctx. Repl i caSynchronizer. GetUpdateRemoteKnowledgeO; reader.Close(); // // Guarda el conocimiento actualizado y los metadatos del adaptador, si los hay //existen // //ctx.Update( ); // // Muestra de la aplicación de cambio, primero se inicializa el conocimiento remoto utilizando // storedKnowledgeld igual que antes. // remoteKnowledge = . . . ; ctx.ReplicaSynchronizer.ConflictPolicy = conflictPolicy; ctx.ReplicaSynchronizer. RemotePartnerld = remotePartnerld; ctx. Repl i caSynchronizer. RemoteKnowledge = remoteKnowledge; ctx.ReplicaSynchronizer.C ha ng eStatusEvent + = FOO_OnCh a ng eStatusEvent; // // Obtiene los cambios del almacén remoto. El adaptador es responsable de recuperar // los metadatos específicos del extremo posterior del almacén. Esto puede ser una extensión // en la réplica. // object remoteAnchor = FOO_GetRemoteAnchorFromStore(); FOOD_RemoteChangeCollection remcteChanges = FOO_GetRemoteChanges( RemoteAnchor); // // Se llena en la colección de cambios // foreach(FOO_RemoteChange change in remoteChanges { // El adaptador es el responsable de hacer el mapeo de la ID Guide localld = FOO_MapRemoteld (cambio); // digamos que estamos sincronizando objetos de Personas buscador ItemSearcher = Person.GetSearcher(ctx); searcher.Filters.Add(Personald = (5)localld'); searcher.Parameters["Personld"] = localld; Persona a persona = searcher.FindOneQ; // // El adaptador transforma los cambios remotos en modificaciones en un objeto de Persona // Como parte de este adaptador puede también hacer cambios en el extremo posterior del nivel de partida // los metadatos específicos para el objeto remoto. // FOO__TransformRemoteToLocaI (remoteChange, person); } ctx.Update(); // // Guarda la nueva ancla remota (esta puede ser una extensión de la réplica) // FOO_SaveRemoteAnchor(); // // Esto es un guardado de la API WinFS regular ya que el conocimiento remoto no está sincronizado. // remoteKnowledge = ctx.Repl¡caSynchronizer.GetUpdateRemoteKnowledge(); ctx.UpdateQ; // // Recordatorio del adaptador para los recordatorios de la condición de aplicación en procesamiento // void FOO_OnEntitySaved(object sender, ChangeStatusEventArgs args) { remoteAn chor.AcceptCh a n ge (args. Cha ng estatus); } 4. Método de Sincronización de la API En una modalidad de la presente invención, es posible llevar a cabo la sincronización entre un almacén WinFS y un almacén que no es WinFS, por medio de las APIs de Sincronización expuestas por el sistema de interfase de hardware/software basado en WinFS. En una modalidad, todos los adaptadores de sincronización son requeridos para implementar la API del adaptador de sincronización, una API administrada (CLR) del tiempo de ejecución del lenguaje común, de modo que puedan ser desplegadas en pantalla, inicializadas y controladas de manera consistente. La API del adaptador proporciona: • Un mecanismo estándar para registrar los adaptadores con el sistema de sincronización del sistema de interfase de hardware/software. • Un mecanismo estándar para que los adaptadores declaren sus capacidades y el tipo de información de configuración necesaria para inicializar el adaptador.

• Un mecanismo estándar para pasar la información de inicialización al adaptador. • Un mecanismo para que los adaptadores reporten de regreso la condición del progreso a las aplicaciones que invocan la sincronización. • Un mecanismo para reportar cualesquiera errores que ocurren durante la sincronización. • Un mecanismo para solicitar la cancelación de una operación de sincronización en marcha. Existen dos modelos de proceso potenciales para los adaptadores, dependiendo de los requerimientos del escenario. El adaptador puede ejecutar en el mismo espacio del proceso conforme se invocan las aplicaciones o procesar por separado todas por ellas mismas. Para ejecutar su propio proceso separado, el adaptador define su propia clase de fábrica, la cual es utilizada para ejemplificar el adaptador. La fábrica puede regresar un campo del adaptador en el mismo proceso que la aplicación que se está invocando, o regresar un caso remoto del adaptador en un campo o proceso de aplicación de tiempo de ejecución de lenguaje común diferente al de Microsoft. Se proporciona una implementación de la fábrica por omisión (default), el cual ejemplifica el adaptador del mismo proceso. En la práctica, muchos adaptadores se ejecutarán en el mismo proceso que la aplicación que se está invocando. El modelo fuera del proceso es generalmente requerido por una o ambas de las siguientes razones: • Propósitos de seguridad. El adaptador debe de ejecutar en el espacio de proceso de un cierto proceso o servicio. • El adaptador tiene que procesar solicitudes de otras fuentes - por ejemplo, solicitudes de red entrantes - además de procesar las solicitudes de las aplicaciones que se invocan. Haciendo referencia a la figura 37, una modalidad de la presente invención presume un adaptador simple que no está advertido de la forma en que es calculada la condición, o que están intercambiados sus metadatos asociados. En esta modalidad, la sincronización es lograda por la réplica, con respecto a la fuente de datos con la cual se quiere sincronizar, primero, en el paso 3702, determinando qué cambios han ocurrido desde la última vez que se sincronizó con dichas fuentes de datos, y luego la réplica transmite los cambios increméntales que han ocurrido desde esta última sincronización basada en su información de condición actual, y esta información de condición actual y los cambios increméntales son enviados a la fuente de datos por medio del adaptador. En el paso 3704 el adaptador, al recibir los datos de cambio de la réplica en el paso anterior, implementa tantos cambios como sean posibles a la fuente de datos, rastrea qué cambios son exitosos y cuales fallaron, y transmite la información del éxito y fracaso de vuelta al WinFS (de la réplica). El sistema de inferíase de hardware/software de la réplica (WinFS), en el paso 3706, al recibir la información de éxito y fracaso de la réplica, calcula entonces la nueva condición de información para la fuente de datos, almacena esta información para uso futuro por su réplica y transmite esta nueva información de la condición de vuelta a la fuente de datos, es decir, al adaptador para el almacenamiento y el uso posterior por parte del adaptador. D. ASPECTOS ADICIONALES DEL ESQUEMA DE SINCRONIZACIÓN Los siguientes son aspectos adicionales (o más específicos) del esquema de sincronización para varias modalidades de la presente invención. • Cada réplica es un subconjunto de datos definido de sincronización de la totalidad de un almacén de datos -- una división de datos que tiene casos múltiples. • Una política de solución de conflictos es manejada por cada réplica (una combinación de adaptador/fuente de datos) individualmente - es decir, cada réplica puede solucionar los conflictos basados en sus propios criterios y el esquema de solución de conflictos. Además, aunque las diferencias en cada caso del almacén de datos puedan resultar y conducir a conflictos futuros adicionales, la enumeración consecutiva e incremental de los conflictos es reflejada en la información de condición actualizada y es invisible para las otras réplicas que reciben esa información de condición actualizada. En la raíz del sistema de sincronización se encuentra la réplica la cual tiene un tipo básico para definir una carpeta raíz (de hecho, una partida de raíz), que tiene una ID única, una ID para la comunidad de sincronización de la cual es un miembro, y cuales filtros u otros elementos son necesarios o deseables para la réplica específica. Cada "mapeo" de la réplica es mantenido dentro de la réplica, y como tal, el mapeo para cualquier réplica particular está limitado a otras de dichas réplicas que conoce. Aunque este mapeo puede comprender solamente un subconjunto de la comunidad completa de sincronización, los cambios a dicha réplica todavía se propagarán a la comunidad completa de sincronización por medio de las réplicas compartidas comúnmente (aunque cualquier réplica particular no esté advertida de cuales otras réplicas está compartiendo generalmente con una réplica desconocida). El esquema de sincronización incluye ambas una pluralidad de manejadores de conflictos previamente definidos disponible para toda las réplicas, así como la capacidad de personalización para los manejadores de conflictos definidos por el usuario/desarrollador. Este esquema también puede incluir tres "solucionadores de conflictos" especiales: (a) un "filtro" de conflictos el cual soluciona diferentes conflictos de diferentes maneras basado, por ejemplo en, (i) como manejarlos con la misma unidad de cambio cambiada en dos lugares, (ii) la forma de manejarlos cuando una unidad de cambio es cambiada en un lugar pero eliminada en otro; y (iii) la forma como manejarla cuando dos unidades de cambio diferentes tienen el mismo nombre en dos localizaciones diferentes; (b) una "lista del manejador" de conflictos en donde cada elemento de la lista especifica una serie de acciones para intentar en orden hasta que el conflicto es solucionado exitosamente; y (c) un registro de "no hacer nada" que rastrea el conflicto pero no toma una acción adicional sin la intervención del usuario.

• El esquema de la sincronización y el uso de las réplicas se hacen posibles en una comunidad de sincronización de maestros múltiples distribuidos de semejante-a-semejante. Además, no existe un tipo de comunidad de sincronización, sino que la comunidad de sincronización existe simplemente como un valor en el campo de comunidad de las réplicas mismas. • Cada réplica tiene sus propios metadatos para el rastreo de la enumeración ¡ncremental de cambios y el almacenamiento de información de condición para las otras réplicas que son conocidas en la comunidad de sincronización. • Las unidades de cambio tienen sus propios metadatos que comprenden: una versión que comprende una clave asociada más un número de cambio del socio; una elaboración de versión de Partida/Extensión/Relación para cada unidad de cambio; el Conocimiento con respecto a los cambios que una réplica ha visto/recibido de la comunidad de sincronización; una configuración ID Local; una GUID almacenada en la relación de referencia para la eliminación. CONCLUSIÓN Como lo ilustra lo anterior, la presente invención se relaciona con a una plataforma de almacenamiento para organizar, buscar y compartir datos. La plataforma de almacenamiento de la presente invención extiende y amplia el aspecto de almacenamiento de datos más allá de los sistemas de archivo y sistemas de base de datos existentes, está diseñada para que sea el almacén de todos los tipos de datos, incluyendo datos estructurados, no estructurados o semi-estructurados tales como los datos de relación (tabulares), XML o una nueva forma de datos denominada Partidas. A través de la fundación del almacenamiento común y los datos esquematizados, la plataforma de almacenamiento de la presente invención hace posible un desarrollo de la aplicación más eficiente para los consumidores, los trabajadores del conocimiento y empresas. Ofrece una interfase de programación de aplicación rica y que se puede extender que no solamente pone a la disposición las capacidades inherentes en su modelo de datos, sino también comprende y se extiende a los sistemas de archivo y métodos de acceso de bases de datos existentes. Deberá quedar entendido que se pueden hacer cambios a las modalidades aquí descritas, sin salirse de los conceptos amplios de la invención de la misma. Por consiguiente, la presente invención no está limitada a las modalidades particulares descritas, sino que pretende cubrir todas las modificaciones que se encuentran dentro del espíritu y alcance de la presente invención, tal y como lo definen las reivindicaciones adjuntas. Como se puede apreciar por lo anterior, todo o las porciones de los diferentes sistemas, métodos y aspectos de la presente invención, pueden ser incorporados en la forma de códigos de programa (es decir, instrucciones). Este código de programas puede ser almacenado en un medio legible por computadora, tal como un medio magnético, eléctrico y óptico, incluyendo sin limitación, un disco flexible, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, cinta magnética, memoria instantánea, unidad de disco duro o cualquier otro medio de almacenamiento legible por la máquina, en donde cuando el código de programa es cargado y ejecutado por una máquina tal como una computadora de servidor, la máquina se convierte en un aparato para practicar la presente invención. La presente invención puede ser incorporada también en la forma de un código de programas que es transmitido por un medio de transmisión, tal como por un cableado eléctrico, a través de fibras ópticas, por una red, incluyendo la Internet o una intranet, o por medio de cualquier otra forma de transmisión, en donde, cuando es recibido el código de programa y cargado en y es ejecutado por una máquina, tal como una computadora, la máquina se convierte en un aparato para practicar la presente invención. Cuando es implementada en un procesador de uso general, el código de programa se combina con el procesador para proporcionar un aparato único que opera de manera análoga a los circuitos lógicos específicos.

Claims

REIVINDICACIONES 1. - Un sistema de plataforma de almacenamiento para un sistema de interfase de hardware/software (por ejemplo, WinFS), comprendiendo el sistema de almacenamiento: casos múltiples de una plataforma de almacenamiento; un subsistema de sincronización de origen para el sistema de interfase de hardware/software que hace posible que ei sistema sincronice los casos múltiples de la plataforma de almacenamiento.
2. - El sistema tal y como se describe en la reivindicación 1, caracterizado porque el subsistema de sincronización sincroniza solamente un subconjunto de datos, de entre la totalidad de datos del almacén de datos, durante una operación de sincronización.
3. - El sistema tal y como se describe en la reivindicación 1, caracterizado porque un primer caso de la plataforma de almacenamiento es una réplica, es decir, que se ejecuta en un sistema de interfase de hardware/software que tiene en su sistema de sincronización (por ejemplo WinFS) y un segundo caso de la plataforma de almacenamiento es una fuente de datos, eso es, que se ejecuta en un sistema de interfase de hardware/software que no tiene en su sistema de sincronización (por ejemplo, un sistema que no es WinFS).
4. - El sistema tal y como se describe en la reivindicación 3, en donde la sincronización entre la réplica y la fuente de datos es facilitada por un adaptador de sincronización que virtualiza la fuente de datos haciendo inferíase con una interfase de programación de aplicación (API) del sistema de inferíase de hardware/software de la réplica.
5. - El sistema tal y como se describe en la reivindicación 1, caracterizado porque el primer de par de objetos específicos sincroniza los cambios independientemente del segundo par de objetos específicos, y en donde ambos el primer par de objetos específicos y el segundo par de objetos específicos son parte de la comunidad común de sincronización.
6.- El sistema tal y como se describe en la reivindicación 1, caracterizado porque los conflictos en la sincronización, son detectados y solucionados automáticamente basados en criterios que se pueden determinar previamente definidos.
7.- El sistema tal y como se describe en la reivindicación 6, caracterizado porque ciertos de dichos conflictos son solucionados siendo registrados para la solución manual por el usuario final.
8.- El sistema tal y como se describe en la reivindicación 1, caracterizado porque el subsistema de sincronización rastrea la condición de las sincronizaciones previas con un asociado de sincronización, por medio del cual solamente sincroniza las unidades de cambio con ese asociado que ha cambiado desde la última sincronización (es decir, "cambios netos").
9. - Un método para sincronizar objetos específicos múltiples de una plataforma de almacenamiento para un sistema de interfase de hardware/software (por ejemplo, WinFS), comprendiendo dicho método: la división de la plataforma de almacenamiento en unidades básicas de granularidad (por ejemplo, unidades de cambio); enumerar consecutivamente los cambios y rastrear los cambios basado en una unidad por unidad de cambio; por cada objeto específico, rastrear la condición de los cambios para esos objetos específicos, así como la condición de los cambios para una pluralidad de otros objetos específicos conocidos en la unidad de sincronización (asociados de sincronización); y para la sincronización, identificar los cambios nuevos comparando los cambios enumerados para un objeto específico particular con la condición de los cambios para ese objeto específico.
10. - El método tal y como se describe en la reivindicación 9, caracterizado porque en el primer objeto específico, se ejemplifica una réplica en un sistema de interfase de hardware/software que soporta directamente la sincronización basada en las Partidas (WinFS), y en donde el segundo objeto específico, una fuente de datos, es ejemplificado en un sistema de interfase de hardware/software que no soporta directamente la sincronización basada en las Partidas (que no es WinFS), comprendiendo además el método el uso de un adaptador para virtualizar el objeto específico que no es WinFS por medio de una interfase de programación de aplicación de sincronización.
11. - El método tal y como se describe en la reivindicación 10, el cual comprende además la detección de conflictos de sincronización en el nivel de granularidad de la unidad de cambio.
12. - El método tal y como se describe en la reivindicación 10, el cual comprende además: objetos específicos para reportar el éxito, fracaso y/o conflictos en el nivel de unidad de cambio individual en la aplicación de cambios (datos de sincronización); y aplicaciones (incluyendo pero sin limitarse a adaptadores y otras aplicaciones de control de sincronización) que utilizan los datos de sincronización para la actualización de la condición del extremo posterior.
13.- Un método para sincronizar una réplica con una fuente de datos (cada uno un asociado de datos), en donde tanto la réplica como la fuente de datos tienen información de condición de cambios que es mantenida por cada asociado de sincronización, y en donde la fuente de datos (que no es WinFS) utiliza un adaptador para hacer inferíase con un sistema de ¡nterfase de hardware/software de la réplica (WinFS) comprendiendo dicho método: una réplica que envía al adaptador una condición de información actualizada para la réplica que, basada en la última información de condición para la fuente de datos, refleja los cambios que han sido hechos desde la última sincronización como se reflejaron en la información de la última condición para la fuente de datos ("cambios nuevos"); y recibiendo dicho adaptador la información de condición actualizada para la réplica y los cambios nuevos, implementando tantos cambios como sean posibles a la fuente de datos, y rastreando el éxito o fracaso por cada cambio en una unidad de cambio basado en la unidad de cambio.
14.- El método tal y como se describe en la reivindicación 13, el cual comprende además: que el adaptador calcule la nueva condición de la fuente de datos basado en el éxito o fracaso de cada cambio en una unidad de cambio en una base de unidad de cambio, almacenando esta nueva información de condición nueva, y transmitiendo esta información de condición nueva al sistema de ¡nterfase de hardware/software de la réplica (WinFS), el sistema de interfase de hardware/software de la réplica (WinFS), almacena la información de condición nueva para esa fuente de datos para el uso futuro por parte de la réplica.
15.- El método tal y como se describe en la reivindicación 13, el cual comprende además: la transmisión del adaptador al sistema de interfase de hardware/software de la réplica (WinFS) el éxito o fracaso de cada cambio a la fuente de datos en una unidad de cambio en basada en la unidad de cambio; calculando el sistema de interfase de hardware/software de la réplica (WinFS) la información de condición nueva para la fuente de datos basado en el éxito o fracaso de cada cambio para la fuente de datos en una unidad de cambio basada en la unidad de cambio; transmitiendo el sistema de interfase de hardware/software de la réplica (WinFS) la información de nueva condición al adaptador y almacenando la información de nueva condición nueva para un uso futuro por parte de la réplica; y recibiendo y almacenando el adaptador la información de condición nueva.
16. - Un medio legible por computadora que comprende instrucciones legibles por computadora para un sistema de plataforma de almacenamiento en un sistema de interfase de hardware/software (por ejemplo, WinFS), comprendiendo dicho sistema de almacenamiento de instrucciones para la sincronización del objeto específico local de entre múltiples objetos específicos de una plataforma de almacenamiento.
17. - El sistema tal y como se describe en la reivindicación 16, caracterizado porque el subsistema de sincronización sincroniza solamente un subconjunto de datos, de entre la totalidad de datos del almacén de datos durante una operación de sincronización.
18. - Las instrucciones legibles por computadora tal y como se describen en la reivindicación 16, caracterizadas porque el primer objeto específico de la plataforma de almacenamiento es una réplica, es decir, que se ejecuta en un sistema de interfase de hardware/software que tiene el subsistema de sincronización (por ejemplo, WinFS), y un segundo objeto específico de plataforma de almacenamiento es una fuente de datos, es decir, que se ejecuta en un sistema de interfase de hardware/software que no tiene el subsistema de sincronización (por ejemplo, que no es WinFS).
19. - Las instrucciones legibles por computadora tal y como se describen en la reivindicación 18, caracterizadas porque la sincronización entre la réplica y la fuente de datos es facilitada por un adaptador de sincronización que virtualiza el segundo objeto específico haciendo interfase con una interfase de programación de aplicación (API) del sistema de interfase de hardware/software del primer objeto específico.
20. - Las instrucciones legibles por computadora tal y como se describen en la reivindicación 16, caracterizadas porque el primer par de objetos específicos sincroniza los cambios independientemente del segundo par de objetos específicos, y en donde ambos el primer par de objetos específicos y el segundo par de objetos específicos son parte de una comunidad común de sincronización.
21. - Las instrucciones legibles por computadora tal y como se describen en la reivindicación 16, caracterizadas porque los conflictos de la sincronización son detectados y solucionados automáticamente basados en criterios previamente definidos que se pueden determinar.
22. - Las instrucciones legibles por computadora tal y como se describen en la reivindicación 21, caracterizadas porque ciertos de dichos conflictos son solucionados siendo registrados para la solución manual por un usuario final.
23. - Las instrucciones legibles por computadora tal y como se describen en la reivindicación 16, caracterizadas porque el subsistema de sincronización rastrea la condición de las condiciones previas con un asociado de sincronización, y de este modo, solamente sincroniza las unidades de cambio con ese asociado que han cambiado desde la última sincronización (por ejemplo, "cambios netos").
24. - Un medio legible por computadora que comprende instrucciones legibles por computadora para sincronizar objetos específicos múltiples de una plataforma de almacenamiento para sistemas de interfase de hardware/software (por ejemplo, WinFS), comprendiendo las instrucciones legibles por computadora instrucciones para: dividir la plataforma de almacenamiento en unidades básicas de granularidad (por ejemplo, unidades de cambio); enumerar consecutivamente los cambios y rastrear los cambios en una base por unidad de cambio; por cada objeto específico, rastrear la condición de los cambios para esos objetos específicos, así como la condición de los cambios para una pluralidad de otros objetos específicos conocidos en la comunidad de sincronización (asociados de sincronización); y para la sincronización, identificar los cambios nuevos comparando los cambios enumerados para un objeto específico particular con la condición de los cambios para ese objeto específico.
25. - Las instrucciones legibles por computadora tal y como se describen en la reivindicación 24, caracterizadas porque comprenden además instrucciones por medio de las cuales un primer objeto específico, una réplica, es ejemplificado en un sistema de interfase de hardware/software que soporta directamente la sincronización basada en las Partidas (WinFS), y en donde el segundo objeto específico, una fuente de datos, es ejemplificada en un sistema de interfase de hardware/software que no soporta directamente la sincronización basada en las Partidas (que no es WinFS), comprendiendo dicho método el uso de un adaptador para virtualizar los objetos específicos que no son WinFS por medio de una interfase de programación de aplicación de sincronización.
26. - Las instrucciones legibles por computadora tal y como se describen en la reivindicación 25, las cuales comprenden además detectar los conflictos de sincronización en el nivel de la granularidad de la unidad de cambio.
27. - Las instrucciones legibles, por computadora tal y como se describen en la reivindicación 25, las cuales comprenden además: objetos específicos de reporte de éxito, fracaso y/o conflictos en el nivel de unidad de cambios individual en la aplicación de cambios (datos de sincronización); y aplicaciones (incluyendo pero sin limitarse a, adaptadores y otras aplicaciones del control de sincronización) que utilizan los datos de sincronización para actualizar la condición del extremo posterior.
28. - Un medio legible por computadora que comprende instrucciones legibles por computadora para sincronizar una réplica con una fuente de datos (cada uno un asociado de sincronización) caracterizado porque tanto la réplica como la fuente de datos tienen información de condición de cambios que es mantenida por cada asociado de sincronización, y en donde la fuente de datos (que no es WinFS), utiliza un adaptador para hacer interfase con un sistema de interfase de hardware/software de la réplica (WinFS), comprendiendo las instrucciones legibles por computadora, instrucciones para que dicha réplica envíe al adaptador la información de condición actualizada para la réplica que, basada en la última información de condición para la fuente de datos, refleja los cambios que han sido hechos desde la última sincronización como son reflejados en dicha última información de condición para la fuente de datos ("cambios nuevos"), de modo que el adaptador que recibe dicha información de condición actualizada para la réplica y los nuevos cambios, puede implementar tantos cambios a la fuente de datos como sean posibles y rastrea el éxito o fracaso por cada cambio en una unidad de cambio en base a las unidades de cambio.
29. - Las instrucciones legibles por computadora tal y como se describe en la reivindicación 28, las cuales comprenden además instrucciones para que el sistema de interfase de hardware/software de la réplica (WinFS), que almacena la información de condición nueva para la fuente de datos para uso futuro por la réplica, siempre que el adaptador haya calculado la nueva condición de la fuente de datos basado en el éxito o fracaso de cada cambio en una base por unidad de cambio y tenga esta información de nueva condición y sea transmitida esta información de nueva condición al sistema de interfase de hardware/software de la réplica (WinFS).
30.- Las instrucciones legibles por computadora tal y como se describen en la reivindicación 28, caracterizadas porque el adaptador trasmite al sistema de interfase de hardware/software de la réplica (WinFS) el éxito o fracaso por cada cambio de la unidad de cambios en una base por unidad de cambio, comprendiendo además instrucciones para; que el sistema de interfase de hardware/software de la réplica (WinFS) calcule una información de condición nueva para la fuente de datos basada en el éxito o fracaso por cada cambio a la fuente de datos en una unidad de cambio, en una base de unidad de cambio; que el sistema de interfase de hardware/software de la réplica (WinFS) transmita la información de condición nueva al adaptador y almacene la información de condición nueva para su uso futuro por dicha réplica de modo que el adaptador pueda recibir y almacenar la información de condición nueva.