MXPA06001208A

MXPA06001208A - Plataforma para servicios de datos a traves de diferentes estructuras de trabajo de aplicacion.

Info

Publication number: MXPA06001208A
Application number: MXPA06001208A
Authority: MX
Inventors: Soner Terek
Original assignee: Microsoft Corp
Priority date: 2005-02-28
Filing date: 2006-01-30
Publication date: 2006-09-19
Also published as: AU2006200230A1; CO5790183A1; US7853961B2; KR101224670B1; NO20060072L; EP1696352A2; CN1828527A; AU2006200230B2; NZ544991A; JP2006244488A; EP1696352A3; IL173430A0; RU2425417C2; CA2533942A1; CN1828527B; SG125173A1; MY149824A; TWI405091B; KR20060095447A; ZA200600754B

Abstract

Manejo de datos entre un almacenamiento de datos comun y multiples aplicaciones de multiples estructuras de trabajo de aplicacion diferentes. Se proporciona un componente de almacenamiento de datos para facilitar el almacenamiento de datos, dichos datos incluyen datos estructurados, semi-estructurados, y no estructurados. Una plataforma de datos comun se conecta al componente de almacenamiento de datos para proporcionar servicios de datos accesibles a traves de una pluralidad de diferentes estructuras de trabajo de aplicacion, dichos servicios de datos permiten a una aplicacion correspondiente de las diferentes estructuras de trabajo acceder a los datos.

Description

PLATAFORMA PARA SERVICIOS DE DATOS A TRAVÉS DE DIFERENTES ESTRUCTURAS DE TRABAJO DE APLICACIÓN REFERENCIA CRUZADA A SOLICITUDES RELACIONADAS Esta solicitud reclama el beneficio de la Solicitud de Patente Provisional de E. U. A. Serie No. 60/657,556 intitulada "Plataforma para Servicios de Datos a Través de Diferentes Estructuras de Trabajo de Aplicación" y presentada el 28 de febrero, 2005. Esta solicitud también se refiere a las siguientes solicitudes de E. U. A.: Solicitud de Patente Provisional Serie No. 60/657,295 intitulada "Modelo de Datos para Datos de Relación de Objeto" presentada el 28 de febrero, 2005, Solicitud de Patente en Serie No. intitulada "Modelo de Datos para Datos de Relación de Objeto" presentada el , Solicitud de Patente Provisional Serie No. intitulada "API de Almacenamiento para una Plataforma de Datos Común" presentada el 28 de febrero, 2005, y Solicitud de Patente en Serie No. intitulada "API de Almacenamiento para una Plataforma de Datos Común" presentada ei . La totalidad de estas solicitudes se incorporan aquí por referencia.

ANTECEDENTES Los datos se han convertido en una propiedad importante en casi todas las aplicaciones, si es una solicitud de Línea de Negocio (LOB) utilizada para navegar productos y generar órdenes, o una aplicación de Manejo de Información Personal (PIM) utilizada para programar una reunión entre gente. Las aplicaciones realizan tanto acceso de datos/manipulación como operaciones de manejo de datos en los datos de aplicación. Las operaciones de aplicación típicas consultan a una colección de datos, buscar el grupo de resultado, ejecutar alguna lógica de aplicación que cambia el estado de los datos, y finalmente persistir los datos al medio de almacenamiento. Tradicionalmente, las aplicaciones de cliente/servidor relegadas y la consulta y las acciones de persistencia para los sistemas de manejo de base de datos (DBMS), desplegadas en la unión de datos. Si existe una lógica céntrica de datos, está codificada como procedimientos almacenados en el sistema de base de datos. El sistema de base de datos operado en datos en términos de tablas y flechas, y la aplicación, en la unión de aplicación, operada en los datos en términos de objetos de lenguaje de programación (por ejemplo, Clases y Estructuras). Esta falta de concordancia en los servicios de manipulación de datos (y mecanismos) en la aplicación y las uniones de datos era tolerable en los sistemas de cliente/servidor. Sin embargo, con la llegada de la tecnología web (y Arquitecturas Orientadas al Servicio) y con aceptación más amplia de servidores de aplicación, las aplicaciones se están convirtiendo en una unión múltiple, y de forma más importante, los datos ahora están presentes en toda unión.

En tales arquitecturas de aplicación unidas, los datos son manipulados en múltiples uniones. Además, con los avances de hardware al dirigir y agrandar memorias, los datos se están convirtiendo en residente de memoria. Las aplicaciones también están tratando con diferentes tipos de datos tal como objetos, archivos, y datos de XML (Lenguaje de Marcación Extensible), por ejemplo. En ambientes de hardware y software, la necesidad de acceso de datos ricos y servicios de manipulación bien integrados con los ambientes de programación está en aumento. Una implementación convencional introducida para dirigir los problemas antes mencionados es una plataforma de datos. La plataforma de datos proporciona una colección de servicios (mecanismos) para que las aplicaciones accedan, manipulen, y manejen datos que están bien integrados con el ambiente de programación de aplicación. Sin embargo, tal arquitectura convencional resulta insuficiente en muchos aspectos. Algunos requerimientos claves para tales plataformas de datos incluyen modelación de objeto compleja, relaciones ricas, la separación de abstracciones de datos lógicas y físicas, conceptos de modelos de datos ricos de consulta, notificaciones activas, mejor integración con infraestructura de unión media.

COMPENDIO DE LA INVENCIÓN Lo siguiente presenta un compendio simplificado de la innovación con el fin de proporcionar un entendimiento básico de algunos aspectos de la arquitectura. Este compendio no es una revisión extensiva de la arquitectura. No pretende identificar elementos clave/críticos de la innovación o delinear el alcance de la innovación. Su único propósito es presentar algunos conceptos de la innovación en una forma simplificada como un preludio a la descripción más detalla que es presentada más adelante. La innovación aquí mencionada y reclamada, en un aspecto del mismo, comprende una arquitectura que facilita el manejo de datos entre un almacenamiento de datos común y aplicaciones múltiples de estructuras de trabado de aplicación separada múltiple. Formaliza un diseño de delineado lejos de aplicaciones para delinear tablas para objetos. La arquitectura une el espacio entre aplicaciones de escritorio y estructuras de trabajo de aplicación de Línea de Negocio (LOB) para permitir a las aplicaciones controlar datos en el nivel de objeto de aplicación más que tabla. Adicionalmente, la arquitectura permite la participación de estos datos a través de todas las estructuras de trabajo tal para que una entidad de datos que es definida por una aplicación de usuario final pueda ser utilizada por la aplicación de LOB, y viceversa. La arquitectura incluye un componente de almacenamiento de datos que facilita el almacenamiento de datos, que datos incluyen datos estructurados, semi-estructurados, y no estructurados. Una plataforma de datos comunes se interpone al componente de almacenamiento de datos para proporcionar servicios de datos accesible por una pluralidad de diferentes estructuras de trabajo de aplicación, que servicios de datos permite a una aplicación correspondiente de las diferentes estructuras de trabajo acceder a los datos. La plataforma de datos además comprende una API (Interfase de Programa de Aplicación) que facilita comunicar las aplicaciones en la forma de clases públicas, interfases, y funciones de adelanto estático, un componente de tiempo de funcionamiento que se interpone a la API y proporciona delineado de relación de objeto, delineado de consulta, y aumenta las coacciones, y una máquina de coacción/seguridad que facilita la creación declarativa de coacciones, y controla el acceso para entidades de la plataforma de datos. En otro aspecto de la innovación sujeta, una plataforma de datos común (CDP) proporciona servicios de datos que son comunes a través de una variedad de estructuras de trabajo de aplicación de usuario final (por ejemplo, Estructura de Trabajo de PIM (Administrador de Información Personal) para estructuras de trabajo de aplicación de LOB (Línea de Negocio). El rango de aplicaciones incluye aplicaciones de usuario final tal como explorador, correo, y aplicaciones de medios; aplicaciones de trabajador de conocimiento tal como aplicaciones de Manejo de Documento y Colaboración; aplicaciones de LOB tal como ERP (Planeación de Recurso de Empresa) y CRM (Manejo de Relación de Costumbre); Aplicaciones de Web y Aplicaciones de Manejo de Sistema. Incluso en otro aspecto de lo mismo, el CDP proporciona beneficios para las aplicaciones que incluyen un almacenamiento rico que proporciona la capacidad para modelar y almacenar datos estructurados, semi-estructurados, y no estructurados, organización flexible, consulta/búsqueda rica, comportamientos ricos, administración flexible, sincronización de datos, participación, esquemas, y un despliegue flexible en ambientes de unión múltiple. Para la realización de lo anterior y fines relacionados, ciertos aspectos ilustrativos de la arquitectura son descritos aquí en conexión con la siguiente descripción y los dibujos anexos. Estos aspectos son indicativos, sin embargo, una cuantas formas diferentes en las cuales los principios de la arquitectura pueden ser empleados y la innovación sujeta pretende incluir todos tales aspectos y sus equivalentes. Otras ventajas , y nuevas características de la arquitectura se harán evidentes a partir de la siguiente descripción detallada de la innovación cuando se consideran en conjunto con los dibujos.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 ilustra un sistema que emplea una plataforma de datos común (CDP) de acuerdo con la arquitectura sujeta. La Figura 2 ilustra un sistema de CDP más detallado de acuerdo con la arquitectura descrita. La Figura 3 ilustra una metodología para implementar una plataforma de datos común que facilita el manejo de datos. La Figura 4 ilustra un diagrama esquemático de componentes de CDP en relación con la arquitectura de la presente innovación. La Figura 5 ilustra el flujo de datos dentro de los varios componentes del CDP. La Figura 6 ilustra varias estructuras de trabajo que pueden ser implementadas con un CDP. La Figura 7 ilustra un escenario de sistema de almacenamiento de archivo a base de una base de datos común que permite múltiples aplicaciones compartir datos. La Figura 8 ilustra una aplicación individual que utiliza múltiples estructuras de trabajo de acuerdo con el CDP y arquitectura asociada. La Figura 9 ilustra los datos de participación de CDP con múltiples aplicaciones asociadas con una pluralidad de diferentes estructuras de trabajo. La Figura 10 ¡lustra un despliegue de dos uniones del CDP para facilitar el manejo de datos. La Figura 11 ilustra- un despliegue de dos uniones con datos compartidos para facilitar el manejo de datos. La Figura 12 ilustra una segunda configuración para que una aplicación tenga datos privados que no desean ser vistos y/o utilizados por otras aplicaciones.

La Figura 13 ilustra una tercera configuración de interés para que otra aplicación acceda al almacenamiento directamente. La Figura 14 ¡lustra una configuración de despliegue de tres uniones de los componentes de CDP. La Figura 15 ilustra una configuración de despliegue de tres uniones de los componentes de CDP. La Figura 16 ilustra un diagrama de la lógica de aplicación que corre tanto en la unión de cliente como en la unión media. La Figura 17 ¡lustra un diagrama de ¡a lógica de aplicación que corre tanto en la unión de cliente como en el cliente medio. La Figura 18 ilustra artículos de moldeo que utilizan al menos una entidad. La Figura 19 ilustra mecanismos extensibles para implementar varias funcionales al incorporar la UAF en la parte superior del CDP. La Figura 20 ilustra el ejemplo de una aplicación de LOB siendo implementada en el CDP. La Figura 21 ilustra una metodología que facilita el manejo del flujo de datos dentro de varios componentes de CDP. La Figura 22 ilustra una metodología que facilita desplegar un CDP a través de múltiples estructuras de trabajo diferentes, en donde las diferentes aplicaciones pueden estar relacionadas con cada estructura de trabajo. La Figura 23 ilustra un diagrama de bloque de una computadora operable para ejecutar la arquitectura descrita. La Figura 24 ilustra un diagrama de bloque esquemático de un ambiente de cómputo ilustrativo de acuerdo' con la presente innovación.

DESCRIPCIÓN DETALLADA La arquitectura ahora es descrita con referencia a los dibujos, en donde números de referencia similares son utilizados para referirse a los elementos similares del todo. En la siguiente descripción, para propósitos de explicación, numerosos detalles específicos son mencionados con el fin de proporcionar un entendimiento completo de la innovación sujeta. Puede ser evidente, sin embargo, que la arquitectura puede ser practicada sin estos detalles específicos. En otros casos, las estructuras y dispositivos bien conocidos son mostrados en forma de diagrama de bloque con el fin de facilitar la descripción de la arquitectura. Como se utiliza en esta aplicación, los términos "componente" y "sistema" pretenden referirse a una entidad relacionada con computadora, ya sea hardware, una combinación de hardware y software, software, o software en ejecución. Por ejemplo, un componente puede ser, pero no está limitado a ser, un procedimiento que corre en un procesador, un procesador, un objeto, un ejecutable, un argumento de ejecución, un programa, y/o una computadora. A manera de ilustración, tanto una aplicación que corre en un servidor, como el servidor pueden ser un componente. Uno o más componentes pueden residir dentro de un procedimiento y/o argumento de ejecución, y un componente puede estar localizado en una computadora y/o distribuido entre dos o más computadoras. Una plataforma de datos es una plataforma que proporciona una colección de servicios (o mecanismos) para que las aplicaciones accedan, manipulen, y manejen datos que están bien integrados con el ambiente de programación de aplicación. La innovación sujeta es una mejora de la plataforma de datos convencional. La arquitectura es una plataforma de datos común (CDP) que proporciona servicios de datos que son comunes a través de una variedad de estructuras de trabajo de aplicación (por ejemplo, estructura de trabajo de PIM (Administrador de Información Personal), y estructura de trabajo de LOB (Línea del Negocio). El rango de aplicaciones incluye aplicaciones de usuario final tal como Explorador, Correo, Aplicaciones de Medios; aplicaciones de trabajador de conocimiento tal como manejo de documento y aplicaciones de colaboración; aplicaciones de LOB tal como ERP (Planeación de Recurso de Empresa) y CRM (Manejo de Relación de Cliente); las Aplicaciones Web y Aplicaciones de Manejo de Sistema. La CDP proporciona al menos los siguientes beneficios a aplicaciones: 1. Almacenamiento rico - la capacidad de molear y almacenar todos los tipos de datos (estructurados, semi- estructurados, y no estructurado), a. Modelos y acceso de datos de relación. b. Abstracción de objeto rico y ambiente de programación. c. Modelo de datos semi-estructurados a través de almacenamiento y consulta de XML. d. Datos no estructurados como archivos. Organización flexible, la capacidad de organizar colecciones arbitrarias de objetos y no estáticamente, como una tabla. a. Soportar el espacio de nombre y organización de sistema de archivo. Consulta/búsqueda rica, la capacidad de consultar todos los datos. a. Soportar la consulta rica (por ejemplo, SQL, OSQL (SQL orientada o objetos), consulta de XML, Secuencias de C#). La OSQL es un lenguaje funcional que es un supergrupo de SQL. Comportamientos ricos, soportar los comportamientos de datos ricos. No es un reemplazo para lógica de procedimiento de aplicación/negocio. Administración flexible, la administración en diferentes granularidades (por ejemplo, operaciones de nivel de artículo tal como copiar, mover, y serializar). Sincronización de datos, sincronización par a par y maestro a esclavo de colecciones arbitrarias de datos. Participación, la capacidad de participar datos a través de múltiples aplicaciones y múltiples estructuras de trabajo de aplicación. Por ejemplo, participar contactos a través de Outlook y aplicaciones de CRM. 8. Esquemas, ricos, fuera de los esquemas de cuadro para que el usuario y aplicaciones de ISV (Vendedor de Soporte Independiente) para facilitar la colaboración con cada uno de los otros. 9. Despliegue flexible, desplegable en ambientes de dos y tres uniones. La CDP y arquitectura asociada permiten todos los beneficios descritos anteriormente. Las innovaciones clave incluyen una arquitectura diseñada, un modelo de datos común que factoriza los conceptos de modelo comunes a través de múltiples estructuras de trabajo de aplicación, y una arquitectura de componente de CDP (funcional). Haciendo referencia inicialmente a los dibujos, la Figura 1 ilustra un sistema 100 que emplea una CDP 102. La CDP 102 es empleada para proporcionar manejo de datos entre aplicaciones de datos y estructuras de trabajo de aplicación 104 y datos en un almacenamiento de datos 106. El almacenamiento de datos 106 puede almacenar, por ejemplo, tipo de datos estructurados, semi-estructurados y no estructurados. Como se indicó anteriormente, la CDP 102 proporciona servicios de datos que son comunes a través de las estructuras de trabajo de aplicación y aplicaciones de usuario final asociadas con ellos. La CDP 102 además incluye una API 108 que facilita el enfrentamiento con las aplicaciones y estructuras de trabajo de aplicación 104, un componente de tiempo de funcionamiento 110, y un componente de máquina de coacción/seguridad 112. La API 108 proporciona la interfase de programación para aplicaciones que utilizan CDP en la forma de clases públicas, interfases, y funciones de ayudante estático. Los ejemplos incluyen Contexto de Almacenamiento, Buscador de Almacenamiento, Entidad, Grupo de Tabla, Tabla, Referencia de Entidad, y Referencia de Tabla. Se debe apreciar que la integración de lenguaje de programación de base de datos (por ejemplo, operadores de secuencia de C# pueden ser parte de la API 108. El componente de tiempo de funcionamiento de CDP 110 es un diseño que implementa varias características expuestas en el diseño de API público 108. Implementa el modelo de datos común al proporcionar delineado de relación de objeto y delineado de consulta, mejorando las coacciones de modelo de datos, etc. Más específicamente, el tiempo de funcionamiento de CDP 110 incluye: la implementación de componente de modelos de datos común; un componente de procesador de consulta; sesiones y componente de transacciones; una memoria caché de objeto, que puede incluir una memoria caché de sesión y una memoria caché explícita; un componente de servicios que incluye rastrear cambio, detección de conflicto y evento; un componente de cursores y reglas; un componente que aloja lógica del negocio; y una máquina de persistencia y consulta, que proporciona la persistencia central y servicios de consulta. Interno a la persistencia y servicios de consulta son los delineados de relación de objeto, incluyendo delineado de consulta/actualización. La CDP 102 también incluye la máquina de coacción/seguridad 112 que proporciona aplicar coacciones contra el almacenamiento de datos 106 y política de seguridad, por ejemplo, seguridad a base de papel. La Figura 2 ilustra un sistema de CDP más detallado 200 que puede incluir la CDP 102, que se interpone a un componente de manejo de almacenamiento 202 de un almacenamiento de datos separado (no mostrado). Alternativamente, el componente de manejo de almacenamiento 202 puede Incluir el almacenamiento de datos, para que pueda estar asociado con una implementación de servidor de SQL. Se debe apreciar que el almacenamiento de datos puede almacenar tipos de datos estructurados, semi-estructurados y no estructurados. Un objeto de la CDP es soportar el desarrollo de aplicación rápido, al permitir el soporte de una variedad de estructuras de trabajo de aplicación 204 (denotado AF^ AF2, ..., AFZ). Las estructuras de trabajo 204 pueden incluir LOB, usuario final, y estructuras de trabajo de aplicación de manejo de sistema, por ejemplo. Las aplicaciones 206 (denotadas APP^ ..., APPS; APP-i, ..., APP-r) asociadas con las estructuras de trabajo de aplicación 204 AFL AF2, y ..., AF2, respectivamente) pueden apalancar las estructuras de trabajo de aplicación respectivas 204, la CDP 102, y los almacenamientos importantes 202 para desarrollar aplicaciones ricas. Los beneficios de un acercamiento diseñado son descritos más adelante. El diseño de manejo de almacenamiento 202 proporciona soporte para capacidades de manejo de datos centrales (por ejemplo, clasificación, capacidad, disponibilidad y seguridad); el diseño de CDP 102 soporta un modelo de datos rico, delineado, consulta, y mecanismos de acceso de datos para las estructuras de trabajo de aplicación 204. Los mecanismos de CDP son extensibles para que múltiples estructuras de trabajo de aplicación 204 puedan ser construidas en la plataforma de datos. Las estructuras de trabajo de aplicación 204 son modelos adicionales y mecanismos específicos para dominios de aplicación (por ejemplo, aplicaciones de usuario final y aplicaciones de LOB). El acercamiento de arquitectura diseñado tiene diferentes ventajas. Permite a cada diseño innovar y desplegarse independiente y rápidamente. El diseño de CDP 102 puede ser más activo, tiene más libertad para innovación, y puede innovar más frecuentemente que el diseño de almacenamiento 202. El acercamiento diseñado alinea el diseño de CDP 102 con la estrategia de la compañía. Finalmente, el diseño de almacenamiento 202 puede enfocarse en las capacidades de manejo de datos centrales, consistentes con la estrategia. Haciendo referencia a la Figura 3, se ilustra una metodología para implementar una plataforma de datos común. Mientras, para propósitos de simplicidad de explicación, una o más metodologías mostradas aquí, por ejemplo, en la forma de un cuadro de flujo, son mostradas y descritas como una serie de actos, se debe entender y apreciar que la arquitectura sujeta no está limitada por el orden de actos, mientras algunos actos, de acuerdo con la innovación, pueden ocurrir en un orden diferente y/o concurrentemente con otros actos de esos mostrados y descritos aquí. Por ejemplo, aquellos expertos en la técnica entenderán y apreciarán que una metodología alternativamente podría ser representada como una serie estados o eventos interrelacionados, tal como en un diagrama de estado. Además, no todos los actos ilustrados pueden ser requeridos para implementar una metodología de acuerdo con la arquitectura. En 300, se proporciona un diseño de manejo de datos central que modela y almacena tipos de datos estructurados, semi-estructurados y no estructurados en un almacenamiento de datos. En 302, un diseño de CDP 110 es aplicado en el diseño de manejo de datos central para proporcionar servicios de datos que soportan un modelo de datos rico, delineado, consulta, y mecanismos de acceso de datos para estructuras de trabajo de aplicación. En 304, una o más estructuras de trabajo de aplicación se traslapan con la CDP. En 306, se proporciona una o más aplicaciones dentro de cada una de las estructuras de trabajo de aplicación que ahora pueden acceder a datos del almacenamiento de datos a través de los servicios de datos proporcionados por la CDP. La Figura 4 ilustra un diagrama esquemático de componentes de CDP de la arquitectura sujeta. Se debe apreciar que la colocación de cualquiera de los componentes y/o cuadros en este esquema no implica (o necesariamente previene a ningún despliegue a través de límites de procedimiento/máquina. La CDP utiliza el modelo de concurrencia optimista para que si cambia sea guardado, y otros cambios que ya han sido hechos a los datos importantes, la detección de conflicto resuelve esto en una forma específica de aplicación. Para hacer una plataforma de datos efectiva, la CDP incluye características tal como integración de lenguaje de programación, modelo de datos rico, estructura de trabajo de persistencia, servicios, y así sucesivamente. La API 108 facilita integración de lenguaje y acceso de datos por una aplicación 400 a través del tiempo de funcionamiento de CDP 110 para el almacenamiento 202. Siendo el diagnóstico de dominio implica que la CDP hace el mínimo más vacío de suposiciones sobre el origen y forma de datos y las coacciones semánticas requeridas en ellos. Hasta este punto, la CDP proporciona las siguientes características (descrito en más detalle más adelante): El Modelo de Datos Común (CDM): En el centro de tiempo de funcionamiento de CDP 110 es un CDM 402. La intención del CDM 402 es factorizar" los conceptos de modelado comunes a través de múltiples dominios de aplicación, de aplicaciones que trabajan principalmente con datos de usuario (PIM, documentos, etc.) para LOB y datos de empresa. Además de proporcionar objetos ricos y abstracción de relación, el CDM 402 proporciona soportes para datos estructurados, no estructurados y semi-estructurados. Datos en bruto/de entidad - La CDM 402 soporta un modelo de Entidad-Relación ricos para capturar la estructura y el comportamiento de datos estructurados (por ejemplo, datos de negocio). La CDM 402 es un supergrupo del modelo de relación central, con extensiones para la abstracción de objeto rico y modelo de relación (por ejemplo, una relación de autor entre documentos y contactos; una relación de líneas entre órdenes de compra y líneas de orden). Datos de Archivo - La CDM 402 soporta el tipo de datos de "corriente de archivo" para almacenar y manipular datos no estructurados (archivos). El tipo de datos de corriente de archivo puede almacenar los datos como un archivo y soporta las APIs de acceso de archivo. El tipo de datos de corriente de archivo originalmente es soportado en el servidor de SQL, delineado para una corriente de archivo de NTFS, y soporta todas las operaciones a base de control/corriente de archivo. Además de modelar el contenido no estructurado como una corriente de archivo en la CDM 402, utilizando los tipos de entidad, el contenido útil puede ser promovido como propiedades estructuradas. Los sistemas de almacenamiento de archivo a base de base de datos definen la noción de un artículo regresado de archivo, que es una entidad que modela las propiedades estructuradas junto con la corriente de archivo de contenido no estructurado. Los artículos regresados de archivo proporcionan la consulta, rica junto con operaciones a base de corriente en la corriente de archivo asociado. Los datos de XML - Documentos de XML pueden ser moldeados para dos formas primarias en la CDM 402: (1) el almacenamiento es como un tipo de datos de XML; (2) delinear el documento de XML a una o más entidades (por ejemplo, similar a contratos de datos). La CDM 402 soporta el tipo de datos de XML como soportado en el servidor de SQL. El tipo de datos de XML puede ser el tipo de cualquier propiedad de entidad; el tipo de datos de XML permite que se almacenen los documentos de XML sin tipo o con tipo. El tipo fuerte es proporcionado al asociar uno o más esquemas de XML con las propiedades de documento de XML. La integración de lenguaje de programación, incluyendo Consulta, en la API 108: Los componentes de característica de CDP centrales, sesiones y transacciones 404, consulta 406, persistencia 408, cursores 410, servicios 412, memoria caché de objeto 414 y alojamiento de lógica del negocio 416 están encapsulados en diferentes clases de "tiempo de funcionamiento" disponibles en la API de CDP 108 (por ejemplo, contexto de almacenamiento). Basándose en los tipos creados en la CDM 402, las herramientas de tiempo de diseño de CDP generan clases de CLR (Tiempo de Funcionamiento de Lenguaje Común) fuertemente con tipos. La CDP requiere un lenguaje de consulta en el sistema de tipo definido por la CDM 402. La CDP pueden soportar operadores de secuencia de C# y OPATH como su lenguaje de consulta. Para el propósito de la aplicación sujeta, los lenguajes de consulta soportados por la CDP generalmente son denominados como Lenguaje de Consulta Común (CQL). El CQL es imaginado para incluir el álgebra de relación central (por ejemplo, seleccionar, unir, y proyectar operadores).

Mientras la sintaxis puede no ser idéntica a SQL, el SQL puede ser delineado para el SQL en una forma directa. El CQL permite consultas ricas contra las estructuras de objeto con las que trabaja el programador. La meta es alinear el CQL con los Operadores de Secuencia que trabajan siendo hechos por el grupo de C#. Estas características proporcionan efectivamente una abstracción a base de objeto de tipo fuerte contra datos almacenados en un sistema de manejo de base de datos de relación (RDBMS) (o cualquier otro almacenamiento permitido de CDP). Además, la estructura de trabajo de persistencia de CDP puede ser utilizada para resistir durablemente y consultar objetos de CLR antiguos de plano (POCO).

Máquina de Persistencia - una máquina de persistencia proporciona definiciones de delineado declarativas que describen exactamente como los objetos son ensamblados fuera de las piezas de componente o vienen de los almacenamientos de relación. La máquina incluye un componente de generación de consulta (no mostrado) que toma una expresión definida por el procesador de consulta, en términos de una expresión de consulta de objeto, y después lo combina con el delineado declarativo. Esto cambia las expresiones de consulta equivalentes que acceden a las tablas importantes en la base de datos. Un componente de generación de actualización (no mostrado) observa los servicios de rastreo de cambio, y con la ayuda de metadatos de delineado, describe como traducir esos cambios en el mundo de objetos a cambios en el mundo de tablas.

Archivo de consulta/búsqueda y datos de XML - Como se explicó anteriormente, el CDM 402 almacena los datos no estructurados y semi-estructurados que utilizan la corriente de archivo y tipos de datos de XML, respectivamente. El CQL es capaz de consultar estos tipos de datos. Para el contenido de archivos promovidos para entidades estructuradas (por ejemplo, artículos regresados de archivo de WinFS), los operadores de relación de CQL pueden consultar estas entidades. Los datos no estructurados almacenados como corriente de archivo pueden ser consultados utilizando búsqueda de texto completo. El contenido de XML puede ser consultado utilizando XRuta o XConsulta. Los delineados de relación/Objeto: ya que la CDP proporciona una abstracción a base objetos en la parte superior del almacenamiento de relación (tabular), necesita proporcionar un componente de delineado de O-R. La CDP soporta tanto delineados prescriptivo (la CDP decide como ocurre el delineado) y delineados no preescriptivos (el diseñador de tipo tiene alguna flexibilidad en delineados específicos). Se debe notar que una implementación de sistema de almacenamiento de archivo a base de base de datos hoy en día utiliza delineados preescriptivos mientras las estructuras de trabajo de persistencia de O-R más generales necesitan delineados no preescriptivos. Memoria caché: El tiempo de funcionamiento de CDP mantiene una memoria caché de resultados de consulta (por ejemplo, cursores) y actualizaciones no comprometidas. Esto es llamado la memoria caché de sesión. La CDP también proporciona una memoria caché explícita, que permite a la aplicación trabajar en un modo desconectado. La CDP proporciona varias garantías de consistencia para datos en la memoria caché explícita. La memoria caché realiza manejos de identidad al correlacionar .identidad en disco de datos con los objetos en memoria. Procesador de consulta: cuando se consulta contra el almacenamiento, las consultas de CQL son delineadas a SQL; sin embargo,' cuando van contra de la memoria caché explícita, las consultas de CQL son procesadas por el componente de QP. El acceso de base de datos es a través del procesador de consulta. El procesador de consulta permite a múltiples extremos frontales para controlar múltiples lenguajes de consulta para ser expresados, y después delineados a un formato canónico interno. Esto es hecho en términos del modelo de dominio y objetos de la aplicación que está trabajando. Las consultas después se pasan al procesador, que es una línea de tubería, y después se convierten en consultas específicas de extremo trasero. Cursores: CDP proporciona tanto cursores solo hacia delante como desplazable. Las notificaciones de soporte de cursores, agrupaciones del nivel múltiple con estado expandido/colapsado, clasificación y filtrado dinámicos. Alojamiento de lógica del negocio: CDP proporciona un ambiente de tiempos de funcionamiento para alojar lógica céntrica de datos en tipos/casos y en operaciones. Tal lógica del negocio céntrica de datos es diferente de la lógica de procedimiento de aplicación/negocio, que puede estar alojado en el servidor de aplicación. Los objetos no solo son filas en una base de datos. Cuando los objetos se materializan en ia memoria, realmente son objetos que tienen comportamientos que la aplicación puede invocar. Existen puntos de extensión en el sistema que son principalmente eventos y recordatorios que operan todos para extender la CDP en el tiempo, de funcionamiento. Estos objetos no solo son objetos, sino objetos de CLR, objetos de .NET, etc. El CDP permite la capacidad para interceptar propiedad u otro llamado de métodos en aquellos objetos. Las aplicaciones pueden adaptar el comportamiento de estos objetos. Servicios: CDP proporciona un grupo central de servicios que está disponibles para todos los clientes de CDP. Esto servicios incluyen reglas, rastreo de cambio, detección de conflicto, evento, y notificaciones. El evento se extiende al tiempo de funcionamiento de CDP 110 desde los servicios de nivel de estructura de trabajo o para las aplicaciones para que agreguen comportamientos adicionales, y también es utilizado para unir datos en la interfase de usuario. Coacciones: El CDP proporciona el componente de coacciones/seguridad 112 para al menos uno de diseñador de tipo para coacciones de autor declarativamente. Estas coacciones son ejecutadas en el almacenamiento. Típicamente, el alcance de coacciones de CDP abarca nociones tal como longitud, precisión, clasificación, predeterminado, revisión, y así sucesivamente. Estas coacciones son impuestas por la máquina de coacción de CDP en el tiempo de funcionamiento. Seguridad: CDP proporciona un modelo de seguridad a base de papel, las credenciales de usuario determinan su "papel" (tal como administrador, usuario de energía, aprobador, etc.). Cada papel es asignado a un grupo de permisos de acceso. La máquina de seguridad de CDP impone estas políticas de seguridad. Además, el CDP proporciona un modelo de seguridad para controlar el acceso a entidades en el CDP. El modelo de seguridad puede soportar la autentificación de un usuario de sistema operativo, nivel de autorización de entidades (por ejemplo, con permisos separados para leer y actualizar), etc. Se debe notar que el componente de coacciones/seguridad 112 es ilustrado de forma separada del componente de tiempo de funcionamiento de CDP 110, ya que puede operar como una entidad separada del mismo. Alternativamente, y tal vez más eficientemente, el componente de coacciones/seguridad 112 es combinado con el componente de almacenamiento 202, que puede ser el sistema de base de datos. Tomados en conjunto, estas características proporcionan una plataforma poderosa para desarrollar aplicaciones céntricas de datos y lógica que puede ser sensiblemente desplegada a través de diferentes uniones. Se debe notar que la colocación de los componentes de tiempo de funcionamiento (o cuadros) en este diagrama no implica (o necesariamente previene) cualquier despliegue específico a través de límites de procedimiento/máquina. Es un diagrama esquemático utilizado para mostrar componentes funcionales. Una de las ventajas claves de la arquitectura de CDP es que proporciona flexibilidad en la implementación. Esto significa dos cosas: 1) Algunos de los componentes mostrados en la Figura 4 son "móviles" en el sentido que pueden vivir en diferentes procedimientos/uniones. Específicamente, la máquina de coacciones/seguridad 112 implica que vive en el procedimiento de almacenamiento 202 de la Figura 2. 2) No todos los componentes mostrados en la Figura 4 necesitar ser implementados con el fin de tener una plataforma de datos de funcionamiento completo. Específicamente, la memoria caché de objeto 414 puede consistir de solo una memoria caché de sesión. En otra implementación, la memoria caché 414 puede incluir una memoria caché explícita que estará sincronizada con el almacenamiento. El procesador de consulta 406 opera en objetos en la memoria caché de objeto 414. Varias características y/o componentes de CDP son descritos en más detalle aquí más adelante. Como se mencionó anteriormente, el centro del CDP es un modelo de datos común (CDM) 402, en donde el intento del CDM 402 es dividir los conceptos de modelo comunes a través de múltiples dominios de aplicación, de aplicaciones que trabajan principalmente con datos de usuario (por ejemplo, PIM, documentos, etc.) para LOB y datos de empresa. En general, existen dos técnicas posibles que pueden ser utilizadas para implementar tal funcionalidad: 1) conceptos de modelos específicos para todo dominio concebible (o concebiblemente importante). Por ejemplo, definir precisamente que significa un "cliente" (del dominio de LOB) y que significa una "persona" (del dominio de usuario) y así sucesivamente; y 2) proporciona una base flexible en la cual los diseñadores de aplicación pueden crear sus propios tipos específicos del dominio, coacciones, relaciones. El CDM 402 utiliza el segundo acercamiento para que proporcione un grupo básico de tipos y defina una estructura de trabajo flexible para crear nuevos tipos. En este sentido, el CDM 402 puede ser tanto un modelo de datos (por ejemplo, realmente define ciertos tipos y sus semánticos) y también un meta-modelo de datos (por ejemplo, permite la especificación de otros métodos). Algunas de las características del CDM 402 son discutidas más adelante pero no se ven en un sentido limitante en aplicación sujeta. El modelo de datos puede subsumir el modelo de datos relacional. En otras palabras, ios conceptos de tablas, filas, consultas, y actualizaciones en tablas son expuestos por el CDM 402. El CDM 402 puede definir una abstracción de objeto más rica para datos que en las tablas y filas. En particular, esto permite el modelo de artefactos de mundo real que utilizan conceptos tal como entidades, relaciones entre entidades, herencia, contenido, y colecciones de tales.

Además, el CDM 402 puede minimizar la falta de concordancia de impedancia entre estructuras de aplicación y estructuras de almacenamiento al alinear el sistema de tipo de lenguaje de programación cercanamente con abstracciones de aplicación modeladas en él. Además, el soporte para comportamientos de aplicación (por ejemplo, métodos, funciones) y un despliegue flexible de comportamientos para permitir que se proporciones aplicaciones de dos uniones y de múltiples uniones. El CDM 402 también puede capturar los semánticos de persistencia independientemente del almacenamiento físico importante, permitiendo la capacidad para que el CDM 402 sea implementado en una amplia variedad de almacenamientos. El CDM 402 puede invocar una pluralidad de conceptos. Los siguientes conceptos pueden ser utilizados por el meta-modelo para ser implementado para diseñar modelos de datos específicos de dominio. En particular los siguientes conceptos pueden ser considerados del centro del CDM 402: 1) el tipo de entidad puede ser una especificación de diseñador de aplicación para una agrupación de propiedades y métodos, en donde una entidad es un caso de un tipo de entidad. Se debe apreciar que un tipo de entidad puede estar organizado a través de jerarquías de herencia; 2) una tabla es una colección de entidades que pueden ser propiedades de otras entidades. Al utilizar las entidades, herencia, y tablas, las aplicaciones recursivamente pueden definir jerarquías de datos. La tabla puede ser fuertemente con tipo en el sentido que una tabla dada solo puede contener entidades de un tipo dado o sus subtipos; 3) un grupo de tabla puede ser una entidad cuyas propiedades son tablas. Este es el caso base para la jerarquía de datos recursiva definida utilizando tablas y entidades. Puede ser sustancialmente similar al concepto de una base de datos; y 4) una relación puede expresar conexiones semánticas entre entidades. Se debe apreciar que la relación puede ser extendida para definir asociaciones, contenido, etc. Una entidad, relación, y/o definición de grupo de tabla puede ocurrir en el contexto de, por ejemplo, un esquema. Para el propósito de esta aplicación sujeta, el propósito primario del esquema es definir un espacio de nombre para alcanzar los nombres de los elementos definidos en el esquema. Un grupo de tabla puede formar el "nivel superior" del CDM 402. El almacenamiento puede ser distribuido directamente y/o indirectamente al crear un grupo de tablas. Por ejemplo, el pseudo código siguiente ilustra un ejemplo de un grupo de tabla: <Espaciodenombre de esquema = "MisEsquemas.MiLOB"> <NombredeTipodeGrupodeTabla = "DatosdeLOB"> <Nombre de Propiedad = "Ordenes" Tipo = "Tabla(Orden)"/> <Nombre de Propiedad = "Clientes" Tipo = "Tabla(Cliente)"/> <Nombre de Propiedad = "Productos" Tipo = "Tabla(Producto)"/> <Nombre de Propiedad = "Proveedores" Tipo = "Tabla(Proveedor) > <Nombre de Propiedad = "EnlacesPS" Tipo = "Tabla(Enlace de Proveedor de Producto)"/> </TipodeGrupodeTabla> <Nombre de GrupodeTabla = "LOB" Tipo = "TipodeGrupodeTabla"/> </Esquema> Un tipo de entidad puede tener propiedades y métodos asociados con él. Para especificar los tipos para propiedades, los parámetros de métodos y valores de regreso de método, el CDM 402 proporciona diferentes tipos de construcción: 1) tipos simples: Int32, fila, otro tipo de valor de CLR; 2) tipos de enumeración: equivalente para enumeraciones de CLR; 3) tipos de referencia (discutidos más adelante); y 4) tipos de orden: colección ordenada de tipos en línea (discutidos más adelante). Las propiedades de estos tipos de construcción pueden estar agrupadas para formar un Tipo en Línea, en donde el tipo en línea puede tener miembros de otros tipos en línea. Más adelante se encuentra un ejemplo de lo anterior: <Nombre de Tipo en Línea = "Dirección"> <Nombre de Propiedad = "Lineal" Tipo = "Fila" Anulable = "falso"> <Máximo de Longitud = "100"/> </Propiedad> <Nombre de Propiedad = "Línea2" Tipo = "Fila" Anulable "verdadero"> <Máximo de Longitud = "100 > </Propiedad> <Nombre de Propiedad = "Ciudad" Tipo = "Fila" Anulable = "falso"> <Máximo de Longitud = "50"/> </Propiedad> <Nombre de Propiedad = "Estado" Tipo = "Fila" Anulable = "falso"> <Mínimo de Longitud = "2" Máximo = "27> </Propiedad> <Nombre de Propiedad = "Código Postal" Tipo = "Fila" Anulable "falso"> <Mínimo de Longitud = "5" Máximo = "5"/> </Propiedad> </Tipo en Línea> La entidad puede estar construida al utilizar los tipos de construcción y/o tipos en línea. Por ejemplo, el pseudo código siguiente demuestra la entidad: <Nombre de Tipo de Entidad = "Cliente" Clave = "Id de cliente"> <Nombre de Propiedad = "Id de cliente" Tipo = "Fila" Anulable "falso"> <Mínimo de Longitud = "10" Máximo = "10"/> </Propiedad> <No?mbre de Propiedad = "Nombre" Tipo = "Fila" Anulable = "falso"> <Máximo de Longitud = "200"/> </Propiedad> <Nombre de Propiedad = "Direcciones" Tipo = "Orden(Dirección)"> <Ocurre Mínimo = "1" Máximo = "3"/> </Propiedad> <Nombre de Propiedad de Navegación = "Ordenes" Asociación : "Cliente de Orden" del Papel = "Cliente" para el papel = "0rdenes7> </Tipo de Entidad> La entidad (excepto grupo de tabla) puede estar contenida dentro de una tabla basada al menos en parte debido a que los grupos de tabla están la unidad de organización de nivel superior y un grupo de tabla está compuesto de tabla. Dentro de un alcance de tabla, cada entidad puede tener un valor de clave único. En el alcance de amplio almacenamiento, cada entidad puede tener una entidad única, su valor de clave concatenado con su identidad de tabla, recursivamente. La entidad puede ser la unidad más pequeña en el CDM 402 de referencia por clave y/o identidad. Las operaciones de almacenamiento puede tener como objetivo la entidad, en donde las operaciones pueden ser, pero no están limitadas a persistir, almacenar, mover, copiar, eliminar, renombrar, recuperar, restaurar, etc. El caso de tipo de línea puede ser utilizado en el contexto de la entidad de contenido. El CDM 402 puede definir el concepto de un tipo de entidad abstracto, que son sustancialmente similares a clases abstractas en el CLR. En otras palabras, no pueden ser iniciados directamente; solo pueden ser derivados para crear otros tipos iniciables. Una referencia de entidad puede ser definida como una referencia durable, persistente para entidades. Los valores de referencias varían en identidades de entidad. No dirigir una entidad genera su referencia; no referenciar una referencia genera el caso de entidad. El propósito primario de las referencias es permitir la participación de entidad: por ejemplo, todos los órdenes para el mismo cliente deberían tener el valor sustancialmente similar para la propiedad de Ref(Cliente), para que las entidades de órdenes se digan que participan con la entidad de cliente (por ejemplo, la sexta línea de código en la siguiente muestra de código es un ejemplo). Los datos asociados con el CDM 402 tienen relaciones entre sus partes constituyentes. El modelo relacional no soporta explícitamente relaciones; la Integridad de PK/FK/Referencial proporciona herramientas para implementar relaciones en una forma limitada. Incluso, el CDM 402 soporta modelo conceptual explícito de relaciones que utilizan asociaciones y composiciones. El siguiente ejemplo puede ser ilustrado para entender las capacidades de asociaciones y composiciones: 1. <Nombre de Tipo de Entidad = "Orden" Clave = "Id de Orden"> 2. <Nombre de Propiedad = "Id de Orden" Tipo = "Fila" Anulable = "falso"> 3. <Mínimo de Longitud = "10" Máximo = "107> 4. </Propiedad> 5. <Nombre de Propiedad = "Fecha" Tipo = "Tiempo de Fecha" Anulable = "falso"/> 6. <Nombre de Propiedad = "Cliente" Tipo = "Ref(Cliente)" 7. Asociación = "Cliente de Orden"/> 8. <Nombre de Propiedad = "Línea" Tipo = "Tabla(Línea de Orden)" 9. Composición = "Línea de OrdenOrden"/> 10. <Nombre de Propiedad = "Dirección de Embarque" Tipo = "Dirección" Anulable = "falso"/> 11. </Tipo de Entidad> 12. <Nombre de Asociación = "Cliente de Orden"> 13. <Papei Final = "Papel de Orden" Tipo = "Orden" Multiplicidad 14. Tabla = "Datos de Venta. Cliente"/> 15. <Papel Final = "Papel de Cliente" Tipo = "Cliente" Multiplicidad = "1"/> 16. <Referencia de papel = "Papel de Orden" para Papel = "Papel de Cliente" Propiedad = "Cliente"/> 17. </Asociación> 18. <Nombre de Composición = "Línea de OrdenOrden"> 19. <Papel de Padre Final = "Orden" Tipo = "Orden" Propiedad = "Línea'7> 20. <Papel de Hijo Final = "Línea de Orden" Tipo = "Línea de Orden" Multiplicidad = "100"/> 21. </Composición> Las asociaciones pueden representar relaciones par a par entre entidades. En el ejemplo anterior, el orden está relacionado con un cliente a través de una asociación. En la muestra de código anterior, la línea 6 muestra que el orden tiene un cliente asociado (que es especificado por la propiedad de referencia Cliente). El origen de esta asociación es definido en las líneas 12-15: dice que la asociación de Cliente de Orden es desde el Orden hacia el Cliente (línea 15); es decir que para cada cliente (Multiplicidad = "1" en la línea 14), pueden existir múltiples Orden (Multiplicidad = "*" en la línea 13). El tipo de asociación ilustrado anteriormente puede ser llamado una asociación de referencia. El CDM 402 define otros dos tipos de asociaciones: Asociaciones de Valor y Asociación a través de Entidades de Asociación. Las asociaciones de valor permiten la expresión de relaciones a través de cualquier propiedad, no solo a través de referencia de identidad (por ejemplo, Propiedad de Documento. Autor se relaciona a Contacto. Nombre a través de la condición de igualdad). Las entidades de asociación permiten el modelo de relaciones en donde la misma relación transporta algunos datos (por ejemplo, la relación de empleo entre una compañía y una persona puede transportar propiedades como el periodo de empieo o la clasificación y título de la persona dentro de la compañía). Las composiciones pueden representar relaciones padre-hijo y/o relaciones de contenido. Se consideran que las Ordenes y Líneas de Orden (por ejemplo, Orden es la suma total de lo que debe de poner la carta de compra en un sitio web; Línea de Orden es cada artículo de individuo en la carta, un libro, un DVD, etc.). Cada Línea de Orden tiene sentido solo dentro del contexto de una Orden. La Línea de Orden puede no salir independientemente fuera de la primera Orden de Contenido. En otras palabras, una Línea de Orden está contenida dentro de una Orden, y su tiempo de vida es determinado por el tiempo de vida de la Orden. Las relaciones ilustradas anteriormente pueden ser modeladas utilizando Composiciones. La línea 8 muestra un ejemplo de una composición. La propiedad de línea y la composición de Línea de Orden de Orden (líneas 18-22) expresan que un orden controla sus líneas y que las líneas dependen en el orden que los aloja. Se debe apreciar que el orden es el padre y las líneas son el hijo. La diferencia principal entre las composiciones y los tipos en línea es que las composiciones involucran entidades. En otras palabras, será posible para una Línea de Orden que es el objetivo de una referencia, mientras un tipo en línea no puede estar en el ejemplo anterior. Un beneficio del CDM 402 y su modelo explícito de relaciones es que proporcionan metadatos que soportan la consulta. Una consulta de corriente arriba puede ser utilizada también. Por ejemplo, dado un cliente, encontrar todos los órdenes (sin tener que almacenar señaladores de regreso explícitos) puede ser invocado al implementar una Propiedad de Navegación dentro del CDM 402. Esto es mostrado en la línea 28 del fragmento de código visto anteriormente y reproducido más adelante para conveniencia. 28. <Nombre de Tipo de Entidad = "Cliente" Clave = "Id de Cliente"> 29. <Nombre de Propiedad de Navegación = "Ordenes" Asociación = "Cliente de Orden" del Papel = "Cliente" para el Papel = "Ordenes"/> 30. </Tipo de Entidad La máquina de persistencia 408 puede incluir delineados de objeto-relación. En otras palabras, el modelado, acceso, y abstracciones de consulta proporcionados por el CDP está basado en objetos. La tecnología de almacenamiento primario utilizada por el CDP está basado en relación (por ejemplo, SQL 2000). La máquina de persistencia 408 utiliza delineados de objetos-relación (también denominados como "delineados O-R"), en donde la máquina de persistencia 408 puede delinear las clases de lenguaje para la representación tabular importante. La máquina de persistencia 408 puede proporcionar dos clases cuando se consideran delineados O-R: 1) delineados de O-R de perspectiva; y 2) delineados O-R de no perspectiva. Los delineados O-R de perspectivas son el delineado entre tipos de CDP, en donde su representación relacional puede dar altamente codificada en CDP. El diseñador de tipo tiene poca y/o no flexibilidad al emitir el diseño de fas tablas importantes. Un ejemplo de esto puede ser un sistema de almacenamiento de archivo basado en base de datos. Los delineados O-R de no perspectiva son en donde el desarrollador tiene grados variantes de flexibilidad para elegir como delinear clases de CLR para las estructuras de almacenamiento importantes. Existen dos subclases que pueden ser consideradas. 1) Exposición de esquema relacional existente como objeto. El diseñador de tipo utiliza un lenguaje de especificación de nivel superior para diseñar tipos de CDM, herramientas para generar clases basadas en ellos, y la flexibilidad para especificar como los tipos delinean a tablas. Este escenario surge cuando las aplicaciones de CDP son desplegadas lado a lado (en el sentido de utilizar los datos sustancialmente similares) con aplicaciones relaciónales existentes. Por ejemplo, un departamento de IT de la, compañía de autos puede tener una aplicación de LOB, en donde desea escribir una aplicación de CDP que va contra los mismos datos (probablemente como parte de una estrategia de migración de pasos a pasos). Pero el requerimiento es que tanto la aplicación de LOB y la nueva aplicación de CDP corra junta contra los mismos datos. 2) La persistencia de una colección de clases en un esquema relacional. El desarrollador no utiliza clases generadas; más que eso, utilizan clases de propio diseño. El desarrollador desea delinear estas clases para un esquema relacional. Se debe apreciar que existen muchos escenarios diferentes que generan este requerimiento. El CDP además puede incluir una superficie de programación (no mostrada) que puede ser utilizada durante el tiempo de diseño. La superficie de programación puede ser hecha disponible para un diseñador(es) de aplicación de CDP y/o programador(es). La superficie de programación puede estar clasificada en tres áreas generales: 1) herramientas de programación de tiempo de diseño (por ejemplo, herramientas para permitir a los diseñadores de tipo crear tipos de CDM y coacciones de las mismas, generar clases de CLR de estos tipos, y agregar comportamientos a los tipos); 2) API (por ejemplo, clases y métodos para escribir aplicaciones de CDP); y 3) consulta (por ejemplo, lenguaje para consultar objetos de CDM tal como casos de entidad. Estos componentes de la superficie de programación trabajan sinergísticamente para proporcionar una abstracción a base de objeto fuertemente con tipo contra los datos de almacenamiento importantes. El CDP proporciona un Lenguaje de Definición de Esquema Común Declarativo (CSDL), análogo al lenguaje de definición de datos de SQL o definiciones de clase C#, para definir tipos de entidad, tablas de entidad, relaciones entre tipos de entidad y coacciones. Existen tres componentes principales de tiempo de diseño. 1. Generador de API. El diseñador de aplicación diseña tipos de CDM y relaciones utilizando CSDL y utiliza una herramienta de CDP de tiempo de diseño llamada APIG (pronunciada ay-pig), que genera clases de CLR parciales que corresponde a estos tipos y relaciones. Las clases generadas de APIG son disponibles como ensambles para programadores de aplicación y pueden ser referenciadas por sus programas de aplicación con la C# que utiliza la cláusula. Estas clases generadas por APIG son, en un sentido, clases canónicas; pueden ser una representación directa de los tipos de CDM dentro de un programa de aplicación. En un ejemplo, las clases de aplicación pueden estar limitadas en su definición, tal como, por ejemplo, cuando la aplicación está utilizando clases de una biblioteca de clase predescrita (paquetes de gráficos, paquete matemático, etc.). La aplicación puede utilizar la estructura de trabajo de persistencia de objeto de CDP para persistir de forma durable y consultar casos de estas clases en el almacenamiento. Tales objetos pueden ser denominados como Objetos de CLR Antiguos Planos, o POCO. El CDP soporta también escenarios de POCO. Delineado de relación de objeto. Este componente del CSDL ayuda a que los diseñadores de aplicación declaren delineados concretos de no perspectiva entre conceptos de almacenamiento tal como tablas y vistas, y clases de CLR. También puede especificar como una coacción definida en términos del CDM 402 debe ser delineada a una coacción declarativa de SQL, un impulsador o procedimiento almacenado. Comportamientos. El CSDL permite a los diseñadores de aplicación determinar que porción de la lógica del negocio es implementada como métodos de caso, como funciones estáticas, como procedimientos almacenados. También determina la unión en donde puede correr la lógica (por ejemplo, tiempo de funcionamiento de CDP contra almacenamiento). La superficie de programación además puede incluir una API de CDP, en donde las aplicaciones de superficie de programación pueden ser escritas en contra. La API de CDP puede tener tres subpartes. 1. Acceso de datos de CDP genérico. Esto es la porción de la API que expone almacenamientos, secciones, transacciones (por ejemplo, Contexto de Almacenamiento), Servicios de Consulta (por ejemplo, Buscador de Almacenamiento), y Servicio de CRUD (por ejemplo, Guardar Cambios). 2. Clases de datos de CDM. Esto es el grupo de ciases canónicas, independientes de aplicación que exponen conceptos de CDM tal como Entidad, Relación, Extensión, etc. 3. Clases de datos de dominio. Estas son clases de aplicación/específica de estructura de trabajo tal como Contacto, Mensaje, Ordenes de Compra que conforman el CDM 402 pero exponen propiedades y comportamientos específicos de dominio. El CDM 402 también puede definir un lenguaje de consulta, el CQL. El CQL está diseñado para permitir consultas ricas contra las estructuras de objetos con las que trabaja el programador. Lo siguientes son tres técnicas identificadas utilizando para la base de formalismo de CQL: 1. ORuta: El lenguaje de ORuta tiene sus raíces en SQL y XRuta y fue diseñado para hacer una versión de objeto de CLR de XRuta. El diseño se construye en el concepto de XRuta de expresiones de ruta para exponer un método para diferenciar propiedades de objetos en secuencia. El diseño está basado en un principio simple: los desarrolladores esperan ver colecciones de objetos como la construcción "estructural" primaria en una API orientada a objetos. La ORuta puede ser el formalismo de consulta de POR para un sistema de almacenamiento de archivo basado en base de datos. 2. SQL de objeto: Este acercamiento extiende el lenguaje de consulta de SQL a manipular gráficos y colecciones de objetos de CDM. El Lenguaje de consulta de Windows (WinQL), una variación de SQL diseñado para consultar y manipular gráfico de objeto de CLR, es un diseño de candidato para las extensiones necesarias en SQL. 3. Operador de Secuencia de C#: Este es un grupo de extensiones C# para consulta revisada de tiempo de recopilación altamente con tipo y operaciones de grupo que pueden ser aplicados a una amplia clase de colecciones transitorios o persistentes de objetos de CLR (por ejemplo, a través de delineados relaciónales de objetos). Estratégicamente, el acercamiento de Operadores de Secuencia C# hace más sensible para convertirse en la estructura de trabajo para CQL. El CQL es un lenguaje de consulta. Las creaciones, actualizaciones, eliminaciones son realizadas como operaciones de objeto (nuevo, establecedores de propiedad, etc.). El componente de delineado del O-R dentro de la máquina de persistencia 408 puede delinear estas operaciones para las operaciones de DML importantes en SQL. Una relación entre tipos de CDM y la superficie de programación es descrita más adelante. El concepto de un "tipo" en CDM 402 puede ser revisado en tres niveles diferentes: 1. Espacio de Esquema: La descripción del tipo en un esquema de CDM. Estos son tipos abstractos en el sentido que no son explícitamente materializados dentro de ningún componente del grupo de tiempo de funcionamiento (por ejemplo, de la aplicación de todas las formas hacia el almacenamiento). 2. Espacio de Aplicación: La representación de los tipos como clases de CLR dentro de la API de CDP. Puede existir una correspondencia de 1-1 entre tipos de entidad/en línea en el espacio de esquema y las clases de datos en un espacio de aplicación. En otras palabras, cada entidad y tipo en línea en el esquema de CDM puede resultar en una clase de CLR. Frecuentemente, estas clases son automáticamente generadas a través de APIG; sin embargo, en el caso de POCO, el desarrollador puede especificar explícitamente un delineado entre clases y tipos de CLR del espacio de esquema. El espacio de aplicación también puede contener clases de relación además de clases para tipos de entidad y en línea. 3. Espacio de Almacenamiento: El formato de persistencia del tipo en el almacenamiento importante. Si el almacenamiento es un almacenamiento relacional, entonces estos tipos son tipos de tablas/UDT/SQL central. El componente de delineado de O-R de CDP soporta un esquema de delineado que permite a los tipos en un espacio de esquema ser delineados a los tipos en el espacio de almacenamiento (por ejemplo, el tipo de entidad de Orden de Compra debe ser delineado a la tabla de Orden de compra en el Servidor de SQL). El lenguaje de consulta de CDP pone en el objetivo al espacio de aplicación. Esto toma sentido debido a que un desarrollador desea consultar utilizando las abstracciones sustancialmente similares que utiliza para otras operaciones (por ejemplo, objetos y colecciones). Sin embargo, los semánticos de CQL son descritos utilizando abstracciones de CDM (el espacio de esquema). El CDP también puede incluir coacciones/seguridad 112. La mayoría de todos los datos, cuando son examinados dentro de su contexto semántico más grande serán obligados en un dominio de su tipo de alguna u otra forma. De esa forma es muy importante para el CDP proporcionar una forma para que los diseñadores de tipo y aplicación expresen estas coacciones. El CSDL puede ser utilizado para crear coacciones declarativamente en el aumento del diseño de tipo. Los ejemplos de coacciones incluyen, pero no están limitados a: 1) coacciones de tipo simple tal como longitud, precisión, clasificación, por omisión y revisión; 2) coacciones de tipo de orden tal como coacciones de elemento, ocurrencias, único, y revisión; y 3) coacciones de propiedad, etc. Estas coacciones pueden ser impuestas por la máquina de coacción de CDP en el tiempo de funcionamiento. Se debe notar que el acto de conformar el CDM 402 implica un grupo de coacciones cuando se ven desde el nivel del almacenamiento relacional importante. Por ejemplo, el CDM 402 requiere que "cada entidad tenga una clave única dentro del alcance de su tabla de contenido". Esto se traduce a una coacción de clave única en un nivel de almacenamiento. Existen diferentes otros ejemplos de tales coacciones. El punto aquí es que la máquina de coacción de CDP impone dos tipos de coacciones: aquellas que están implicadas por (y requeridas para conformarse al) el CDL 402 y aquellas que son creadas por el diseñador de tipo. Además de las coacciones declarativas creadas en CSDL, las coacciones también pueden ser escritas utilizando procedimientos almacenados de servidor de SQL. Este método permite la expresión de coacciones más complicadas que son posibles en el lenguaje declarativo.

Además, las coacciones/seguridad 112 pueden proporcionar un modelo de seguridad para controlar el acceso a entidades en el CDP. El modelo de seguridad para el CDP debe satisfacer al menos uno de los siguientes escenarios: Autentificacíón: El modelo de seguridad puede soportar autentificar usuarios de sistema operativo. Este incluye usuarios en un dominio, grupo de trabajo o una máquina de cliente desconectada. También puede incluir soporte tanto para autentificación a base de NTLM como a base de Kerberos. Autorización: El modelo de seguridad de CDP puede soportar la autorización de seguridad al menos en un nivel de entidad. También debe permitir manejar permisos separados para leer y actualizar la entidad. En el mínimo, la coacción/seguridad 112 proporciona una "propiedad" y/o un grupo de propiedades de una entidad para ser declarados como el identificador de seguridad de una entidad. Los derechos de acceso de identidad son determinados por una función asociada con la tabla que toma el identificador de seguridad como un parámetro. El CDP también debe permitir la provisión separada a los usuarios que pueden cambiar el identificador de seguridad de los usuarios que pueden cambiar el resto de la entidad. Se debe apreciar que el CDP puede soportar un modelo a base de papel más general que también permite diferentes permisos que es solo leer y escribir. El tiempo de funcionamiento de CDP 110 mantiene una memoria caché 414 (por ejemplo, una memoria caché de objeto 414) de resultados de consulta (por ejemplo, cursores discutidos a detalle más adelante) y actualizaciones no comprometidas, en donde la memoria caché puede ser denominado como la memoria caché de sesión debido a que está unida a las sesiones, transacciones 404. Además, llega a la existencia cuando una sesión es creada y se aleja cuando se termina la sesión. La sesión de CDP es encapsulada dentro del objeto de contexto de almacenamiento. Una aplicación puede iniciar múltiples casos de Contexto de Almacenamiento, con ello iniciando múltiples sesiones y de ahí múltiples memorias caché de sesión. El CDP también puede exponer otro tipo de memoria caché, llamado la memoria caché explícita. La memoria caché explícita proporciona una memoria caché de datos de una o más consultas. Una vez que los datos son materializados en la memoria caché explícita, se pueden proporcionar las siguientes garantías de consistencia de datos: 1) solo de lectura, no autoritativo; 2) posible escritura, autoritativo; y 3) renovación automática a través de notificaciones exógenas. El modelo de programación y consulta contra la memoria caché explícita pueden ser sustancialmente similares que en los datos de almacenamiento. El cursor, las reglas 410 son mecanismos que permiten al grupo de entidades de datos regresadas del CQL ser procesadas de una vez. Una aplicación puede crear un cursor en el grupo de resultado al copiar simplemente el grupo de resultado completo en la memoria y superar un patrón de desplazamiento en la parte superior de esta estructura de memoria. Pero la ubicuidad de este requerimiento y la complejidad que algunas veces está involucrada al implementar un cursor (especialmente cuando se toman en cuentas las actualizaciones, paginación, etc.) significa que cualquier plataforma de datos debe proporcionar un modelo de cursor. El CDP proporciona tanto cursores solo hacia adelante como desplazables. Además de la funcionalidad básica de navegar y desplazar, los cursores de CDP proporcionan las siguientes características: 1) notificaciones y mantenimiento exógeno; 2) agrupamiento de nivel múltiple con estado expandido/colapsado; y 3) clasificación y filtrado dinámico (por ejemplo, "post-procesamiento"). Se debe apreciar y entender que los cursores no pueden ser un mecanismo diferente para especificar un grupo de resultados; los grupos de resultado son especificados por consulta, y los cursores están sobre estas consultas. El CDP también puede incluir el alojamiento de lógica de negocio 416. Cuando múltiples aplicaciones están manipulando datos sustancialmente similares, un requerimiento clave es asegurar que los datos permanezcan confiables, eso es, garantizando que los datos conformen las varias reglas de validación, reglas del negocio, y cualquier otro sistema de edificaciones y balances instituido por el diseñador de tipo y/o propietario de datos. Una buena suposición es que las aplicaciones en general no son confiables. Fuera de exigencias de torpeza, malicia, y/o las simples exigencias de patrones de uso no previstos, las aplicaciones guardan y/o intentan guardar de forma inválida. Por ejemplo, un usuario puede ingresar 292 como el código de área y la aplicación guarda tal número incluso aunque 292 sea un código de área inválido y de ahí el valor en el campo del número telefónico ya no representa un número telefónico. En otras palabras, no puede ser "confiado" para ser un número telefónico. La forma usual de prevenir esto es crear un límite confiable: algún cuerpo de código/etc. de reglas/validación declarativo (por ejemplo, comúnmente denominado como lógica del negocio) que corre un procedimiento separado e inspecciona cambios de datos hechos por la aplicación para aprobar) tal cambio. Después, puede guardar estos cambios al almacenamiento. Muchas veces, la lógica del negocio hace más que inspeccionar y aprobar; y también impone reglas del negocio, causa que suceda el flujo de trabajo, etc. (por ejemplo, cuando se inserta un nuevo cliente, el e-mail debe ser enviado al departamento de revisión de crédito para asegurar la confiabilidad de crédito). El CDP proporciona varios mecanismos para crear lógica del negocio (BL). Estos mecanismos pueden ser divididos en las siguientes 5 categorías: coacciones, controladores de evento, métodos estáticos/de caso, comportamientos unibles, y métodos de servicio estáticos cada uno de los cuales es discutido en más detalle más adelante. Las coacciones/seguridad 112, como se discutió anteriormente, pueden ser declarativos y de procedimiento. Estas coacciones pueden ser ejecutadas en ei almacenamiento, cercano en proximidad a los datos. De esa forma, las coacciones 112 son consideradas para estar dentro del límite de confianza. Además, las coacciones pueden ser creadas por el diseñado de tipo. El alojamiento de lógica de negocio 416 puede emplear un controlador de evento. La API de CDP hace surgir diferentes eventos en operaciones de cambio de datos. Los autores de BL pueden engancharse en estos eventos a través del código de controlador. Por ejemplo, cuando se considera una aplicación de manejo de orden. Cuando entra un nuevo orden, la aplicación necesita asegurar que el valor del orden es menor que el límite de crédito autorizado para el cliente. Esta lógica puede ser parte del código de controlador de evento que es corrido antes de que el orden sea insertado en el almacenamiento. Hablando ampliamente, existen los siguientes tipos de eventos: 1) validación (por ejemplo, estos eventos proporcionan una oportunidad para que la parte interesada inspeccione el valor propuesto y lo valide); 2) pre-guardado (por ejemplo, este evento surge justo antes de guardar los cambios al almacenamiento y puede ser sustancialmente similar en intento y comportamiento al impulsador "ANTES" en un servidor de SQL); y 3) post-guardado (por ejemplo, este evento surge después de guardar los cambios al almacenamiento y puede ser sustancialmente en intento y comportamiento del impulsador DESPUÉS en un servidor de SQL). Este tipo de BL corre en el CDP y de ahí puede ser corrido en cualquier unión en el que está desplegado el CDP. De esa forma, cuando corre una unión de cliente, puede ser pasado por otras aplicaciones (por ejemplo, no corre dentro del límite de confianza).

Además, el alojamiento de lógica del negocio 416 puede invocar métodos estáticos/de caso. Las clases auto-generadas para tipos de CDM son clases parciales. Un diseñador de tipo puede completar estas clases parciales al agregar métodos adicionales en ellos, típicamente para implementar lógicas que hace sentido a un tipo particular o un grupo de tipos. Se consideran los siguientes ejemplos: persona. ObtenerEstadoenLíneaQ; en donde persona es un caso de tipo de Persona; Direccióndecorreoelectrónico.EsDirecciónVálida(), en donde Direccióndecorreoelectrónico es un caso de tipo dirección de correo electrónico de SMTP; etc. Por su propio origen, este tipo de BL no es disponible; por ejemplo, está arriba de la aplicación para llamar EsDirecciónVálidaQ para asegurar validez. Es corrido en cualquier unión en la que está desplegado el CDP. De esa forma, no corre dentro del límite de confianza cuando el CDP está en unión de cliente. Los comportamientos unibles son un patrón de codificación que permite a los diseñadores de tipo crear puntos de conexión para extensiones de tercera parte. El ejemplo clásico es el tipo para un mensaje de correo electrónico. Los diferentes programas de correo electrónico pueden estar corriendo en una máquina dada. Cada programa desea utilizar el tipo de Mensaje, pero cada programa también necesita adaptar el comportamiento del método de Enviar Mensaje. El diseñador de tipo realiza esto al definir un comportamiento básico para el método de Enviar Mensaje, y permitiendo que las terceras partes proporcionen un señalador a la implementación. Los comportamientos unibles también corren en cualquier unión en la que está desplegado el CDP. De esa forma, no corre dentro del límite de confianza cuando el CDP está en la unión de cliente. Los métodos de servicio estáticos son escritos de BL y desplegados en la unión media y están lejos de la unión de cliente. En otras palabras, el BL corre como un servicio web en la unión media. Por ejemplo, se considera que un Servicio de Manejo de Calendario que proporciona servicios tal como CrearCitaQ, DesocuparseQ, etc. Estos servicios ("métodos de servicio estático") son implementados utilizando CDP y el servicio web es desplegado en la unión media. La unión de cliente tiene un apoderado de servicio web que es utilizado por la aplicación para invocar estos servicios utilizando un canal (discutidos más adelante). Este tipo de BL puede correr en la unión media, y estar dentro del límite de confianza. Se debe apreciar que la arquitectura con componentes hace posible para el CDP permanecer agnóstico del almacenamiento a cierto punto. Las características de CDP tal como memoria caché de objeto, cursores, sesiones, transacciones, etc., utilicen abstracciones del nivel de CDP. Delinear a las abstracciones de almacenamiento importantes toma lugar en el delineado O-R y diseño de persistencia. Ai reescribir la lógica de delineado, el CDP puede ser implementado en diferentes almacenamientos.

La Figura 5 ilustra el flujo de datos dentro de varios componentes del CDP. Es instructivo examinar la interacción con varios componentes y en respuesta a llamados de método por una aplicación 500 (similar a las aplicaciones 206 y aplicación de 400) utilizando el siguiente ejemplo. 1. vacío AgregarACarta (Id de cliente dila, Id de producto de fila) 2. { 3. utilizando (DatodeOrden od = nuevo DatodeOrdenQ) 4. { 5. CartadeCompra carta = od.CatasdeCompra. Buscador. Filtro( 6. "IddeCliente = {0}", lddecliente).ObtenerPrimero(); 7. si(carta = = nulo) 8. lanzar nueva Excepción("sin carta de compra"); 9. Producto producto = od. Producto. Buscador. Filtrable( 10. "IdedeProducto = {0}", lddeproducto).ObtenerPrimero(); 11. si(producto == nulo) lanzar nueva Excepción ("producto faltante); 12. carta. Productos. Agregar (producto); 13. od.GuardarCambios(); 14. } 15. } Este ejemplo agrega un artículo a una Carta de Compra persistente. Imaginar que este método es invocado como parte de procesar una página web de ASP.NET, por ejemplo. Línea 3: Crear el contexto de almacenamiento. El Contexto de Almacenamiento es encapsulado por un objeto de Datos de Orden que es creado por la aplicación 500. La clase de Datos de Orden 5 puede representar un tipo de grupo de tabla que es descrito en un esquema de CDM. El objeto de Datos de Orden crea un objeto de Contexto de Almacenamiento configurado como sea necesario para interactuar con el almacenamiento 202. El Código de Inicialización de Contexto de Almacenamiento puede ser parte de la sesión de 10 tiempo de funcionamiento y componente de transacciones 404, que abre una conexión al almacenamiento 202, y hace el trabajo necesario para indicar una sesión y crear un contexto de transacción. Un contexto de seguridad es establecido en el componente de coacciones/seguridad 112. Finalmente, un caso del 15. Contexto de Almacenamiento es regresado por la API 108 a la aplicación 500. En el caso de 2 uniones, obtener Contexto de almacenamiento resulta en una conexión al almacenamiento 202. Se debe apreciar que una conexión en un despliegue de tres uniones puede ser ligeramente diferente. 20 Línea 5: Consulta. El lado derecho de la expresión de la línea 5 es una consulta de ORuta. La persistencia y máquina de consulta 408 expone una interfase rudimentaria con métodos para recuperar objetos basándose en una consulta de CDM. La implementación de CDM en la CDM 402 llama a un método con la ORuta especificada. 25 La máquina de persistencia y consulta 408 delinea la consulta en SQL y la envía a través del cable como una carga de TDS. El componente de coacción/seguridad 112 asegura la seguridad que es aplicada adecuadamente y que la aplicación/usuario solo ve los datos que está permitido para ver. El almacenamiento ejecuta la consulta y regresa los resultados de regreso al tiempo de funcionamiento de CDP 110. El CDM 402 y la máquina persistente/de consulta 408 trabaja junto para hidratar objetos desde los resultados de TDS y estos objetos son colocados en la memoria caché del objeto 414 (por ejemplo, la memoria caché de sesión). El resultado es que la API 108 regresa un objeto de Carga de Compra a la Aplicación 500. Línea 9: Consulta. Unir esta consulta y la previa han resultado en ninguno de los cursores siendo creado (el método de Obtener Primero () esencialmente aplica a una cláusula "superior 1" para la consulta). Sin embargo, si la consulta requería que se creara un cursor, entonces el componente de cursor y/o reglas 410 realiza esta operación. Línea 12: Actualizar. El objeto de Carta de Compra en la memoria de objeto 414 es actualizado con el producto especificado. Línea 13: Cambios de Flujo. La implementación de Guardar CambiosQ en el objeto de Datos de Orden llama a Guardar Cambios() en el objeto de Contexto de Almacenamiento encapsulado. Contexto de almacenamiento. Guardar CambiosQ es parte del componente de alojamiento de lógica del negocio 416. Esto involucra los siguientes pasos. Primero, se corre la lógica de pre-guardar. Después, se corre el código de validación, seguido por procedimientos de post-guardado. Este código de validación es enganchado en un evento definido por la API de CDP 108. Se debe notar en otra ¡mplementación, que el código de validación puede ser enganchado al establecedor para el objeto. Después, se corre el código pre-guardado. Este código es enganchado en un evento definido por la API de CDP 108. Escriben cambios al almacenamiento. Primero, el componente de alojamiento 416 trabaja con la memoria caché del objeto 414 para obtener un vector de cambios que contiene todos los cambios hechos dentro de este almacenamiento. La máquina de persistencia 408 expone una interfase llamada IPersistir, que es una inferíase rudimentaria con métodos tal como Escribir (<cambiar vector>), etc. El componente de alojamiento 414 obtiene una IPersistir de la máquina de persistencia 408 y llama a IPersistir. Escribir() con el vector de cambio. La máquina de persistencia 408 delinea la solicitud de escritura en la actualización de SQL apropiada (ya sea la declaración de Actualizar real o un llamado de procedimiento almacenado) y utiliza esto para escribir los cambios al almacenamiento 202. Durante este procedimiento, el componente de coacciones/seguridad 112 asegura que la imposición de seguridad apropiada está hecha. También corre cualquier lógica de coacción. Finalmente, se corre el código de post-guardado. Este código es enganchado en un evento definido por la API de CDP 108.

Se debe notar que correr la lógica del negocio puede resultar en cambios a los objetos en la memoria caché 414. Estos cambios son persistidos en el almacenamiento 202 por un llamado a mi Contexto de Almacenamiento. Guardar Cambios(), que asegura que la lógica del negocio 416 no va a ser sobrepasada. Múltiples ISVs (Vendedores de Soporte Independiente) pueden desear correr la lógica en cambios de datos, en cuyo caso durante sus controladores al evento y los controladores llaman en orden de FIFO (Primero Dentro/Primero Fuera) a través del CLR. En este ejemplo, la lógica del negocio 416 aloja la validación de ÍSD, pre-guardado, y lógica de post-guardado. La Figura 6 ilustra varias estructuras de trabajo que pueden ser implementadas con la CDP. La CDP es una plataforma de datos que está diseñada para ser utilizable a través de varios dominios verticales especializados, tal como datos de usuario, datos de LOB, etc. El CDM proporciona un modelo de datos agnóstico de dominio que es lo suficientemente rico para expresar la estructura específica de dominio y los semánticos pero al mismo tiempo, es lo suficientemente genérico para ser utilizable a través de diferentes dominios. Varias características de CDP están basadas en CDM y de ahí están disponibles a través de aplicaciones de todos los dominios. El universo de las aplicaciones descrito contra el CDP puede estar divido en las siguientes tres clases: 1. Estructuras de trabajo: Una estructura de trabajo utiliza mecanismos de extensibilidad proporcionados por el CDP con el fin de adaptar el CDP para un dominio particular. Una estructura de trabajo agrega valor al CDP con especializaciones de tipo y servicios adicionales. Sin embargo, el modelo de programación expuesto a la aplicación es el modelo de programación de CDP; en particular, las aplicaciones incluso utilizan clases de datos, Contexto de Datos, Buscador de Almacenamiento, y el CQL. Un sistema de almacenamiento de archivo a base de base de datos puede ser un ejemplo de una estructura de trabajo en la parte superior del CDP que es adaptado para el dominio de datos de usuario. 2. Plataformas Verticales: Un diseño separado en la parte superior del CDP con sus propias APIs, abstracciones, y modelo de datos. Esconde el CDP y expone un modelo de programación completamente diferente a las aplicaciones. Por ejemplo, una aplicación utilizada en conjunto con correo electrónico puede utilizar CDP, pero exponer Modelo de Objeto de Correo Electrónico para sus usuarios. 3. Aplicaciones "Regulares": Solo una aplicación de CDP significa que realiza un grupo específico de tarea. No especializa ningún tipo de CDP, o expone un modelo de programación, o utiliza ninguna estructura de trabajo o una plataforma vertical. Las plataformas verticales y Aplicaciones "Regulares" son solo código; pueden utilizar CDP en cualquier momento que deseen sin pasión o prejuicio. Las estructuras de trabajo son un poco diferentes; ya que agregan valor al CDP sin esconderlos de la aplicación, pueden adherir las siguientes reglas: 1. El modelo de datos de estructura de trabajo es idéntico al CDM, o es una especialización simple, bien documentada del CDM. Puede definir nuevos tipos, pero estos tipos son finalmente con súper-tipos por entidad. 2. La estructura . de trabajo puede definir coacciones adicionales en tipos de CDM existentes y/o crear nuevas coacciones que utilizan el CSDL. En otras palabras, las coacciones deben ser expresadas al utilizar la metodología de CDM para definiciones de coacción. 3. Las estructuras de trabajo usualmente no exponen su propio lenguaje de consulta; incluso si lo hacen, puede ser además de, no en vez de, CQL. 4. Las estructuras de trabajo usualmente no exponen su propio modelo de programación; incluso si lo hacen, puede ser además de, no en vez de, API de CDP. 5. Las estructuras de trabajo proporcionan servicios especializados adicionales de la parte superior del CDP. Estos servicios pueden ser implementados como lógica de negocio de CDP o como clases de ayudante adicionales y métodos. Se debe apreciar y entender que todas las reglas anteriores pretenden asegurar que los datos guardados en el CDP a través de una estructura de trabajo dada pueden ser accesibles para todas las aplicaciones sin importar si una aplicación está utilizando esta estructura de trabajo o no. La Figura 6 ilustra tres (3) estructuras de trabajo en la parte superior de un diseño de CDP 602: una estructura de trabajo de aplicación de usuario (UAF) 604 (por ejemplo, un sistema de almacenamiento de archivo a base de base de datos, WinFS, etc.), una estructura de trabajo de colaboración 608 (tal como WSS), y una estructura de trabajo de negocio 610 (BF) (por ejemplo, una estructura de trabajo de LOB). Los datos que pertenecen a cada estructura de trabajo es mostrada en el mismo patrón que el cuadro de estructura de trabajo. Por ejemplo, el UAF 604 tiene datos con un contacto 618 y un artículo 620; la estructura de trabajo de colaboración 608 tiene biblioteca de documentos de datos 622; y el BF 610 tiene datos en un ordenador 624. Se debe notar que todos estos tipos son con súper-tipo final para la entidad 626. La Figura 6 también ilustra tres (3) aplicaciones en el diseño de aplicación: una aplicación de manejo de contacto 612, una aplicación de colaboración 614 (tal como una aplicación de correo electrónico), y una aplicación de manejo de relación de cliente (CRM) 616. La aplicación de manejo de contacto 612 trabaja completamente con datos dei UAF 604; la aplicación de CRM 616 trabajo con datos tanto del UAF 604 como del BF 610; y la aplicación de colaboración 614 trabaja con datos de todos las tres estructuras de trabajo (por ejemplo UAF 604, estructura de colaboración 608, y el BF 610).

La Figura 7 ilustra un escenario de sistema de almacenamiento de archivo a base de base de datos común que permite a múltiples aplicaciones compartir datos. En otras palabras, la Figura 7 ilustra múltiples aplicaciones que utilizan una estructura de trabajo individual. Un componente de CDP y componente de almacenamiento 702 (ilustrado como el CDP + almacenamiento en la Figura 7) puede ser utilizado para ser una plataforma de datos individual para un sistema operativo que es apalancado por cualquier y por todas las aplicaciones. Las ventajas (como se menciono anteriormente) son de modelo rico, transparencia de datos, y participación de datos. Estas ventajas pueden descritas en más detalle más adelante. El CDM proporciona un ambiente de modelo flexible que puede ser utilizado para describir tipos requeridos por un grupo diverso de aplicaciones y escenarios. Por ejemplo, los datos de usuario (por ejemplo, documentos, archivos, fotografías, música, ...), datos de LOB (por ejemplo, Clientes, Ordenes, Detalles de Orden, ...), datos de PIM (por ejemplo, contactos, correo electrónico, calendario, tareas, ...) pueden ser todos modelados utilizando el CDM. El tipo de modelo rico que se extiende a datos estructurados, semi-estructurados, y no estructurados y también se extiende a dominios verticales hace posible que una aplicación individual trabaje con diferentes tipos de datos utilizando abstracciones comunes y lenguaje de consulta. En otras palabras, el CDP puede ser utilizado como un almacenamiento. El CDP puede ser utilizado como una plataforma de datos individual que es apalancada a través de todas las aplicaciones. Además, los datos almacenados utilizando CDP pueden estar disponibles para todas las aplicaciones para operar (por ejemplo, sujeto a políticas de seguridad). Considerando lo siguiente: cada aplicación almacena datos en un formato que es opaco para otras aplicaciones excepto para la misma aplicación (por ejemplo, una que almacenó los datos). Para dar solo dos ejemplo: los contenidos de un buzón de correo de correo electrónico es opaco para todas las otras aplicaciones excepto la aplicación de correo electrónico; una aplicación de CRM tiene un grupo elaborado de esquemas que sobre pasa la parte superior de las tablas para crear abstracciones tal como Cliente, Caso, y así sucesivamente, de esa forma, haciendo la noción de un "cliente" opaco para todas las otras aplicaciones (por ejemplo, a menos que la aplicación conozca ei esquema utilizado por la aplicación de CRM). Claramente, existen datos en la aplicación de correo electrónico que son conceptualmente similares a los datos almacenados por una aplicación de CRM, un ejemplo es la información de contacto. Tanto como el usuario esté involucrado, un contacto es un primer Contacto es un Contacto; desde esta perspectiva, es difícil entender por que la misma información de contacto está almacenada dos veces, una vez en el CRM y una vez en el buzón de correo de correo electrónico. Las emisiones aquí no solo son de almacenamiento redundante, también lo son todas las anomalías que implica, haciendo que sucedan las actualizaciones en ambos lugares, reconciliar eliminaciones, y asegurar inserciones en ambos lugares, y así sucesivamente. Considere lo que pase cuando tanto la aplicación de correo electrónico como la aplicación de CRM están construidas en el almacenamiento de CDP 702. Al utilizar el CDM, el tipo de contacto puede estar derivado del tipo de entidad y su estructura se hace transparente tanto para la aplicación de correo electrónico como para la aplicación de CRM. De esa forma, mientras las dos aplicaciones concuerden en el sistema para un tipo, las diferentes aplicaciones pueden utilizar cada uno de los otros datos sin estar concientes de la existencia de los otros. Debido a que el CDP ofrece un modelo de consulta común, la aplicación de CRM (por ejemplo) puede consultar a los datos de contacto sin importar si un caso particular del contacto "pertenece" a él o no. La combinación del modelo rico, transparencia de datos y la arquitectura de estructura de trabajo de plataforma permite a muchos escenarios de participación/interoperación involucrar combinaciones de múltiples aplicaciones y estructuras de trabajo. Se debe apreciar que el término participación puede referirse a una aplicación que utiliza los datos tanto como estén almacenados en el CDP sin importa que aplicación almacena y/o que estructura de trabajo fue utilizada para almacenarla. En particular, la Figura 7 ilustra un escenario de UAF común en donde múltiples datos de participación de aplicaciones, que en este caso es el grupo de tipos de UAF derivado del artículo 706. El CDP y almacenamiento 792 pueden incluir un grupo de tipos de UAF relacionados con una estructura de trabajo de UAF 704. El grupo de tipos de UAF puede derivarse de un artículo 706, en donde el grupo puede incluir un correo electrónico 708, un documento 710 y un contacto 712. Además se debe apreciar que el artículo 706 puede ser derivado de una entidad 714. Una pluralidad de aplicaciones puede ser utilizada en conjunto con el CDP y la estructura de trabajo de UAF 704, como tal, pero no limitándose a una aplicación de correo electrónico 716, un cliente de evento rico 718, y un proyecto M 720. Se debe apreciar y entender que no está colocada ninguna restricción sobre la unión en la cual la aplicación, CDP, UAF residen. Por ejemplo, una de las aplicaciones en la Figura 7 puede ser ejecutada y/o correr en la unión media (por ejemplo, una aplicación de colaboración). La Figura 8 ilustra una aplicación individual que utiliza múltiples estructuras de trabajo de acuerdo con el CDP y arquitectura asociada. El CDP y almacenamiento 702 pueden proporcionar una plataforma de datos individual para un sistema operativo que es apalancado a través de todas las aplicaciones. Una aplicación de CRM 802 que puede ser primordialmente escrita en una estructura de trabajo de LOB 804, puede utilizar datos de contacto 806 asociados con una estructura de trabajo de UAF 808. Se debe apreciar que la aplicación de CRM 802 típicamente utiliza datos asociados con ellos tal como, pero no limitándose a, detalles de una orden 814, y una orden de compra 816. La aplicación de CRM 802 puede utilizar abstracciones de nivel de CDP cuando se utilizan los datos de UAF (por ejemplo, los datos de contacto 806, un artículo 810, una entidad 812, etc.). En otras palabras, la aplicación de CRM 802 no necesita utilizar los métodos de estructura de trabajo de UAF 808. Además, se debe apreciar y entender que la aplicación de CRM 802 puede residir en cualquier unión. La Figura 9 ilustra los datos de participación de CDP con múltiples aplicaciones asociadas con una pluralidad de estructuras de trabajo diferentes. La Figura 9 ilustra tres estructuras de trabajo, una estructura de trabajo de UAF 904, una estructura de trabajo de colaboración 908, y una estructura de trabajo de BF 910 en la parte superior de un CDP 902. Una pluralidad de aplicaciones puede utilizar una combinación de nivel de estructura de trabajo y programación del nivel de CDP. En particular, una aplicación de manejo de contacto 912, una aplicación de colaboración 914, y una aplicación de CRM 916 pueden utilizar una combinación de nivel de estructura de trabajo y programación de nivel de CDP. El CDP 902 proporciona la pluralidad de aplicaciones asociadas con una pluralidad de estructuras de trabajo diferentes para compartir datos dentro de un almacenamiento 928. Específicamente, existen varias formas en las cuales las pluralidades de las aplicaciones interactúan con los datos. La aplicación de manejo de contacto 912 puede utilizar CQL para consultar un contacto 918; puede utilizar métodos de UAF 904 tal como mover nivel de artículo, copiar, contacto. Obtener Mejor D irección de Correo Electrónico(), etc. La aplicación de manejo de contacto 912 además puede utilizar clases de tiempo de funcionamiento de CDP centrales tal como, pero no limitándose a, Contexto de Almacenamiento, buscadores de almacenamiento y clases de datos de CDP (por ejemplo, la clase contacto y personas que obtienen y que establecen asociado). La aplicación de colaboración 914 puede utilizar CQL para consultar los Contactos 918, cualquiera de los documentos en la biblioteca de documentos 912, y tal vez incluso a una orden 924. La aplicación de colaboración 914 no necesita saber la existencia del UAF 904 y/o el BF 910 para ser tales consultas, puede ser hecho simplemente en el nivel de CDP sin utilizar ningún código especial escrito por otras estructuras de trabajo. Utiliza operaciones específicas para la estructura de trabajo de colaboración 908 para manipular ia biblioteca del documento 922 tal como Agregar Documento a Biblioteca de Documento (<documento>, <biblioteca de documento>), etc. La aplicación de colaboración 914 además puede utilizar las clases de nivel de CDP tal como Contexto de Almacenamiento, Buscador de Almacenamiento, Contacto, Orden, Biblioteca del Documento, y establecedores y personas que tienen asociados. La aplicación de CRM 916 utiliza CQL para consultar todas las órdenes a través de un contacto dado. Se debe apreciar que la aplicación de CRM 916 puede hacer esta consulta sin ningún conocimiento que los contactos fueron realmente creados utilizando un UAF 904. Manipula Ordenes utilizando métodos y servicios proporcionados por el BF 910 (por ejemplo, Encontrar Estado de Embarque (<orden>)). Además se pueden utilizar clases de nivel de CDP tal como Contexto de Almacenamiento como Buscador de Almacenamiento, Contacto, Orden, y establecedores y personas que tienen asociados. Cuando se comparten con almacenamientos de no CDP, es importante notar que el CDP no emplea el modelo de proveedor mientras las fuentes de datos arbitrarias pueden aparecer como almacenamiento de CDP. Cuando una aplicación de CDP/estructura de trabajo desea trabajar con datos en un almacenamiento de no-CDP, puede emplear dos opciones: 1) utilizar la arquitectura de adaptador sincrónico (que es parte de UAF) para sincronizar estos datos en el almacenamiento de CDP; y 2) construir lógica de adaptación para integrarse con el almacenamiento de no-CDP. La Figura 10 ilustra un despliegue de dos uniones de CDP. Los varios componentes que comprenden el CDP son, en un sentido, móviles. Con ciertas limitaciones, pueden ser desplegados a través de diferentes procedimientos y límites de máquina, resultando en configuraciones de dos uniones, tres uniones, y N uniones (en donde N es un entero mayor o igual a 1). Se debe apreciar y entender que aunque se ilustra un despliegue de dos uniones, la innovación sujeta no está tan limitada y que cualquier número de configuraciones de unión puede ser empleado. En particular, una API de CDP 1002 y un tiempo de funcionamiento de CDP 1004 ambos pueden estar en el procedimiento de aplicación asociado con una aplicación 1006. De esa forma, los componentes de CDP (por ejemplo, el tiempo de funcionamiento de CDP 1004, la API 1002, y unas coacciones/seguridad 1008) pueden existir en varias uniones. Por ejemplo, la API 1002, el tiempo de funcionamiento de CDP 1004, y la aplicación 1006 pueden existir en una unión de cliente 1010, en donde los componentes con ellos pueden existir en su propio procedimiento/límites de máquina. Adicionalmente, un almacenamiento 1012 y las coacciones/seguridad 1008 pueden existir en una unión de servidor 1014, en donde los componentes en ellos pueden existir en su propio procedimiento/límite de máquina respectivo. Se debe apreciar que las coacciones/seguridad 1008 pueden estar alojados en el procedimiento de almacenamiento mientras el resto de los componentes de CDP pueden estar en el procedimiento de cliente. Esto es un ejemplo primario de cómo los componentes de CDP pueden ser considerados para ser móviles. La Figura 11 ilustra un despliegue de dos uniones con datos compartidos de acuerdo con un aspecto de la innovación sujeta. Una primera configuración, discutida más adelante, es cuando múltiples aplicaciones comparten los mismos datos. Esto no es decir que las aplicaciones tienen que compartir los datos; más que eso, es decir que cualquiera de los datos de aplicación está disponible para otras aplicaciones. También se debe notar que la disponibilidad de datos está en el contexto de aplicaciones, no en los usuarios, de esa forma, esto es diferente de la noción de credenciales de usuario. El módulo de coacción/seguridad de tiempo de funcionamiento de CDP puede controlar esto sin importar la aplicación. Una aplicación puede interactuar con una API y un tiempo de funcionamiento de CDP, en donde varias aplicaciones pueden existir con cada componente respectivo para que cada aplicación, API, y tiempo de funcionamiento de CDP puedan tener su propio límite de máquina/procedimiento ilustrado como límite 1102, límite 1104, y límite 1006. Para la búsqueda de brevedad, se ilustran tres aplicaciones (por ejemplo, aplicación 1, aplicación 2, y aplicación 3), incluso se entiende que cualquier número de aplicaciones puede ser empleado. Las aplicaciones pueden acceder a datos compartidos 1108 dentro de un almacenamiento 1110 dentro de su propio límite de procedimiento/máquina 1112. Se debe apreciar que las coacciones/seguridad 1114 son impuestas durante tal participación de datos entre diferentes aplicaciones. Esta configuración es muy importante en muchos escenarios de usuario; por ejemplo, es la piedra angular en la visión de almacenamiento de archivo a base de base de datos de datos de usuario esquematizados que pueden ser apalancados por ISVs para construir aplicaciones inteligentes, concientes de datos. El proyecto M puede confiar en éste para realizar su visión de ser un toldo universal para todos los datos de usuario. Esta es la configuración primaria soportada por el CDP. La Figura 12 ilustra una segunda configuración tal como una aplicación que tiene datos privados que no desean ser vistos y/o utilizado por otras aplicaciones. En otras palabras, existe un despliegue de dos uniones involucrado con datos primarios. Existen muchos usuarios y escenarios de ISV que demanda la noción de datos privados de aplicación. Por ejemplo, si una aplicación decide almacenar sus datos de configuración (por ejemplo, equivalentes de archivo ini) en un sistema de almacenamiento de archivo a base de base de datos, es deseable para esto que sea privado para la aplicación. Muchas veces, existe un requerimiento por privacidad parcial, se permiten las lecturas, pero no las escrituras. Por ejemplo, en una aplicación de correo electrónico, es deseable presentar un buzón de correo, pero reservaría el derecho así mismo para modificar el buzón de correo. En un despliegue de dos uniones, el CDP tiene el soporte limitado para esta configuración. No existe soporte razonable para la seguridad del nivel de aplicación en el almacenamiento de servidor de SQL; consecuentemente, una pieza de datos puede no ser marcada como privada para una aplicación dada en el sentido estricto de prevenir el acceso de datos. Sin embargo, esta situación puede ser parcialmente soportada en las siguientes formas: • Esta aplicación utiliza sus propios tipos, y pone sus tipos en un espacio de nombre separado y crea ensambles privados para las clases de datos que resultan de aquellos tipos. Ya que todo el acceso del nivel de CDP a los datos de caso que pertenecen a este esquema es a través de estos ensambles, otras aplicaciones no tendrán acceso a las clases correspondientes.

• La aplicación crea su propio almacenamiento de CDP privado (por ejemplo, un grupo entidades en CDP en el cual se puede crear un Contexto de Almacenamiento) cuyo nombre no es publicado a otras aplicaciones. • A través del uso de documentación Se debe apreciar que las aplicaciones pueden elegir alguno o todo de los métodos anteriores para tener datos privados. Se puede notar que la arquitectura de CDP a través de sí mismo no puede crear un impedimento hacia implementar una noción verdadera de datos privados. De esa forma es concebible que cuando la seguridad del nivel de aplicación se hace disponible en la plataforma importante, el CDP fácilmente puede exponerlo. También se debe notar que en muchos casos, el "requerimiento de datos privados" surge debido a una necesidad genuina de limitar la visibilidad sino debido a la necesidad de imponer lógica de negocio específica de aplicación en los datos. Por ejemplo, los buzones de correo locales creados a través de una aplicación de correo electrónico tienen una carpeta de calendario; la regla es que solo los artículos de calendario pueden ser colocados en esta carpeta. La aplicación de correo electrónico puede no cuidar si otra aplicación (tal como una aplicación de correo electrónico de marca separada) pueda ver/modificar su buzón de correo o no tanto si esta regla es impuesta. La arquitectura de CDP proporciona imposición de toda lógica del negocio tanto como las aplicaciones llegan a través del diseño de CDP. Se debe apreciar que los datos de aplicación privados son soportados en despliegues de tres uniones debido a que la unión media puede imponer esto. Continuando con la Figura 12, se ilustra un límite de máquina/procedimiento 1202 con una aplicación que ¡nteractúa con una API y un tiempo de funcionamiento de CDP y un límite de máquina/procedimiento 1204 con una aplicación que interactúa con una API y el tiempo de funcionamiento de CDP. Para la búsqueda de brevedad, solo se ilustran dos aplicaciones, pero se debe apreciar que cualquier número de aplicaciones puede acceder a los datos compartidos 1210 y/o acceder a los datos privados respectivos (por ejemplo, aplicación 1, datos privados 1210; y aplicación 2, datos privados 1212, dentro de un almacenamiento 1206 dentro de su propio límite de máquina/procedimiento 1208. La Figura 13 ilustra una tercera configuración de interés para que otra aplicación acceda directamente al almacenamiento. En otras palabras, existe un despliegue de dos uniones con un accedo de almacenamiento directo. Una aplicación 2 dentro de un límite de máquina/procedimiento 1302 puede acceder directamente al almacenamiento de SQL 1306, tal vez a través de ADO.NET, por ejemplo, u otra API de acceso de datos. Por ejemplo, grandes tiendas de IT (tecnología de información) que tienen aplicaciones de SQL existentes no son probables a eliminarlo y mover en masa a una aplicación a base de CDP. Más que eso, la migración para CDP en una base pieza por pieza puede ser implementada. Ya que el tiempo regresivo a cero y la estabilidad son emisiones clave en un ambiente de producción, es probable que las aplicaciones de CDP puedan continuar corriendo lado a lado con la aplicación de SQL por algún tiempo. Ya que el CDP ofrece delineados flexibles, de O-R de no perspectiva (objeto a relación), la aplicación de CDP puede ser desplegado en el esquema existente. La arquitectura de CDP permite el acceso de SQL directo, naturalmente. Esto es debido a que "datos de aplicación 1" es simplemente un grupo de tablas y no hay nada que prevenir a la aplicación 2 para accedería directamente, mientras tenga los permisos apropiados. Se deben notar las siguientes consecuencias para la aplicación 2: 1) Puede no tener acceso a servicios de CDP (o cualquiera de los servicios construidos con una estructura de trabajo en la parte superior del CDP). 2) Específicamente, no tiene el beneficio del CDM, así que tiene calcular la representación tabular y consultas/actualizaciones de emisiones directamente en este nivel. Se deben notar las siguientes consecuencias para la aplicación 1: 1) La lógica del negocio en el servicio(s) de BL es efectivamente superada por la aplicación 2. 2) Algunas coacciones, por ejemplo, aquellas que no son implementadas como impulsadores/DRI (integridad referencial declarativa) también son superados por la aplicación 2. En este despliegue particular, es la responsabilidad de los diseñadores de aplicación y/o administradores de despliegue asegurarse que la aplicación 2 tiene su propia lógica para imponer coacciones, etc., para que suceda lo correcto. La Figura 14 y 15 ilustra una configuración de despliegue de 3 uniones de los componentes de CDP. Los varios componentes de CDP pueden ser desplegados en una configuración de tres uniones. En esta configuración, el tiempo de funcionamiento de CDP 1402 está presente tanto en unión de cliente como en las uniones medias (mostradas en la Figura 15). La aplicación yace en la unión de cliente y un almacenamiento 1404 ya sea en la unión de servidor (ilustrada en la Figura 15). La lógica de aplicación puede relacionarse con dos reclamaciones en las Figuras 14 y 15: la primera es un cliente 1406. La segunda es un apoderado de servicio web 1408, un servicio web 1410 (visto en la Figura 15), y el alojamiento de lógica de negocio 1412 (visto en la Figura 15) por ejemplo, validación, lógica de pre-guardado, y lógica de post-guardado. Mientras en cliente 1406 es una aplicación y de ahí, la lógica contenida dentro puede ser legítimamente llamada como "lógica de aplicación", eso es a lo que se está refiriendo. Más que eso, la referencia es a la lógica contenida dentro del apoderado de servicio web 1408, el servicio web 1410, y el alojamiento de lógica de negocio 1412. Esto es un código escrito por el ISV y significa que esté desplegado en la unión media; de esa forma, en un sentido muy real, ésta es una aplicación de unión media. La lógica de aplicación puede residir tanto en el cliente como en las uniones medias.

Dependiendo en si la lógica de aplicación corre, existen diferentes escenarios posibles que son considerados más adelante. Antes de mover la consideración de los escenarios, se debe apreciar que el tema de despliegue de unión múltiple está cercanamente relacionado a las formas en las cuales las acciones de aplicación son alejadas a través de uniones. El término alojar puede abarcar los siguientes tres acercamientos generales a alejar el nivel de aplicación o las operaciones del nivel de servicio de CDP a través de uniones: 1. Alejar el nivel de aplicación a través de servicios web: en este escenario, la lógica de aplicación reside en la unión media y es expuesta en el cliente como métodos estáticos alejados. Esto es discutido en detalle más adelante. 2. Alejamiento de llamado de servicio de CDP implícito: llamados de API de CDP tal como Encontrar TodosQ, Encontrar Uno (), Guardar CambiosQ son enviados a la unión media implícitamente a través de la gente de alejamiento y componentes de servicios de alejamiento. Esta arquitectura es descrita más adelante. Además, las secciones subsecuentes tienen ejemplos que describen como traba esto. 3. Alejamiento explícito, desconectado: La API de CDP define un patrón de programación mientras la aplicación define explícitamente cuando deben suceder las operaciones de cruce de unión. Si está operación resulto en recuperación de datos, entonces los datos recuperados son guardados en la memoria caché en la unión de cliente. Este patrón usualmente es denominado como el "modo desconectado" (discutido más adelante). En particular, la Figura 14 y 15 ilustra la lógica de aplicación que corre en la unión media (por ejemplo, un servicio web). El escenario primario para el despliegue de unión media es el caso en donde la lógica de aplicación corre exclusivamente en la unión media; el cliente 1406 invoca esta lógica a través de un mecanismo de servicio web (por ejemplo, el apoderado de servicio web 1408 y el servicio web 1410). Se debe apreciar que la máquina de seguridad en la unión de servidor puede estar alojada en el procedimiento de CDP de unión media. En un despliegue de dos uniones, los llamados de CDP son procesados a través del tiempo de funcionamiento de CDP 1402 dentro del procedimiento de cliente; el tiempo de funcionamiento contacta al servidor cuando es necesario. En un despliegue de tres uniones, algunos llamados de CDP son procesados localmente (a través de la unión de cliente) y algunos son procesados remotamente (a través de ia unión media). Además, incluso otros casos pueden ser procesados en ambos lugares. Un despliegue de tres uniones define una metodología para alejar los llamados apropiados. Un agente de alojamiento 1414 en la unión de cliente que es un componente que puede utilizar un canal (por ejemplo, índigo) para empaquetar y enviar solicitudes al CDP es la unión media (esto es el acto real de un llamado de procedimiento remoto). En la unión media yace un servicio de alejamiento 1416 (visto en la Figura 15) que, apropiadamente suficiente, sirve a estas solicitudes. Este patrón es parte de lo que se conoce comúnmente como la Arquitectura Orientada a Servicio (SOA). Una característica de la SOA es que diferentes uniones se comunican una con otra a través de intercambio de mensaje. El CDP puede utilizar la infraestructura de índigo para este propósito. El servicio de alejamiento proporciona un grupo de servicios orientado a datos, tal como "ejecutar una consulta", "insertar", "eliminar", "actualizar", "crear", "guardar", "obtener la clave dada de objeto", "obtener la clave de raíz". Ai mantener el paradigma del SOA, estas operaciones pueden ser verbos dentro de un mensaje de SOAP. Cualquiera acción que la unión de cliente desee ejecutar en la unión media es expresada en términos de estos verbos simples. Estos verbos de envío de mensajes básico son abstraídos en métodos en dos interfaces que utilizan facilidades proporcionadas por índigo; de hecho, estas son las interfases del IPersistir y IConsutla que fueron discutidos anteriormente. De esa forma, el agente de alejamiento 1414 y el servicio de alojamiento 1416 juntos actúan como puntos finales en un canal índigo para alojar los métodos de interfase de IPersistir y IConsulta. Se debe apreciar y entender que los métodos en IConsulta y IPersistir son "grano grueso" en el siguiente sentido: pueden ser utilizadas para consulta, u operar en, un grupo grande de objeto. Por ejemplo: en respuesta al método de Guardar CambiosQ, el agente de alejamiento 1414 emite IPersistir. Escribir() una vez al servicio de alejamiento 1416 con el grupo con el grupo contacto de objetos sucio. De esa forma, las interfases entre el cliente y la unión media son orientadas en volumen y no de forma hablada. El siguiente pseudocódigo ilustrativo puede ser ilustrado para examinar flujo de datos/control a través de varios módulos mostrados en las Figuras 14 y 15, en respuesta a llamados de métodos. Se debe apreciar y entender que lo siguiente es un ejemplo y la arquitectura sujeta no está tan limitada. 1. Datos WinES wd = nuevo Datos WinFS (@\\CorpSvr01\Compartido Programado\AnilNori")) 2. Entradas Programadas = wd. Artículos. Filtrado por Topos <Entrada de Programación>().Filtro("Tiempo de lnicio>@0", nuevo Tiempo de Fecha (xxxx, 10, 29, 9, 0, 0)). Obtener Primero(); 3. s. Nombre de Presentación = s. Nombre de Presentación + "[importante, ¡por favor venga!]"; 4. Servicios de Programación ss = nuevo Servicio de Programación (wd); /* bool público Crear cita (cita de Entrada de Programación, ruta de fila)*/ 5. si (ss. Crear Cita (s. @"\\CorpSvr01 Programación Compartida\PCeiis")) 6. { 7. Consola. Escribir Línea ("¡Cita creada!"); 8. } En este ejemplo, la aplicación consulta al calendario compartido para Añil Nori en la Internet de la corporación para obtener su entrada de calendario para el 29 de octubre, xxxx a las 9 AM. Esto es representado por el objeto de entrada de programación, que es un tipo derivado de la entidad (por ejemplo, Entrada de Programación es parte del esquema de PIM y representa un artículo en la programación del usuario). Modifica la Entrada de Programación, anexa el texto "[¡importante, por favor venga!]" al titular de la cita. Después invoca al método de Crear Cita en un servicio web (llamado Servicio de Programación) para poner esta Entrada de Programación modificada en el calendario compartido de Pedro Celis. Este fragmento de código ilustra varios puntos clave en un despliegue de 3 uniones: 1. El cliente utiliza el tiempo de funcionamiento de CDP local para consultar entidades de almacenamiento. Las consultas son ejecutadas en la unión media. 2. Los resultados de consulta están en la memoria caché de sesión de CDP de la unión de cliente. La "lógica de aplicación" completa, incluyendo lógica de negocio, validación, etc., es corrida en la unión media a través del servicio web y a través de la máquina de alojamiento de BL del CDP.

Este procedimiento es impulsado a través de un llamado al método de CrearCitaQ. Lo siguiente es un examen detallada del flujo de datos entre/a través de varios módulos. Línea 1: Crear un contexto de almacenamiento. Un objeto de Contexto de Almacenamiento (por ejemplo, API 1418 en unión de cliente) es encapsulado por un objeto de datos que es creado por la aplicación y/o cliente 1406. La clase de datos representa un tipo de grupo de tabla que fue descrito en un esquema de CDM. El objeto de datos crea un objeto de Contexto de Almacenamiento configurado como sea necesario para ¡nteractuar con el almacenamiento 1404. El código de iniciación del Contexto de almacenamiento es parte de un tiempo de funcionamiento de CDP 1402 en la unión de cliente. Línea 2: Consulta. El RHS de la expresión en la Línea 2 es una consulta de ORuta. Esta consulta regresa máximo con un objeto de Entrada de Programación, la primera entrada (por ejemplo, Asumir que existe una definición precisa de "primera entrada") en 10/29/04, 9 AM. El tiempo de funcionamiento de CDP 1402 en la unión de cliente obtiene la interfase de IConsulta en el agente de alejamiento 1414 y llama a Ejecutar Consulta (<ORuta>) en él. El agente de alejamiento 1414 puede utilizar un canal índigo y envía esta consulta al servicio de alejamiento 1416 en la unión media. La consulta es delineada y ejecutada justo como en el caso de dos uniones y los resultados son regresados a la unión de cliente. Existen dos posibilidades aquí: 1. Los resultados de TDS en bruto son regresados desde la Unión Media a la Unión de Cliente sin hidratar los objetos. El tiempo de funcionamiento de CDP 1412 en la unión de cliente después hidrata los objetos. 2. Si estos objetos ya existen en la memoria caché de objeto 414, los objetos hidratados son regresados a la Unión de Cliente. Se debe apreciar que la consulta de ORuta entera es enviada a través del canal índigo. Por ejemplo, si la consulta era un "encontrar todos los objetos de Entrada de Programación de Tipo" (eso es, una invocación de método de Encontrar TodoQ), entonces esta consulta completa sería enviada (el servicio de alejamiento 1416 en la unión media) en un mensaje de SOAP, no un mensaje por objeto. Línea 3: Manipular Memoria Caché de Objeto de Unión de Cuente. Un vez que se ha regresado el objeto de Entrada de Programación a la Unión de Cliente, está disponible para otra manipulación dentro de la memoria caché de sesión del tiempo de funcionamiento de CDP 1402 en la Unión de cliente. Cuando el cliente 1406 cambia la propiedad de Presentar nombre del objeto de Entrada de Programación, esto es procesado completamente por el tiempo de funcionamiento de CDP 1402 en la Unión de Cliente. Línea 4: Nuevo-ing en una apoderado de servicio web en la Unión de Cliente. Presumiblemente, el cliente 1406 ya ha agregado una referencia asmx apropiado (o el equivalente índigo) durante el tiempo de diseño. La Línea 4 puede crear un caso del objeto de apoderado de servicio web en el cliente. Este llamado es servido completamente por el apoderado de servicio web 1408. Línea 5: Llamar al Método de Servicio Web. Crear Cita() es uno de los métodos alejado por el servicio web 1410 en la unión media. Este método toma un objeto de Entrada de Programación y una fila de conexión de CDP; utiliza esta información para crear un objeto de Entrada de Programación dentro de un Contexto de Almacenamiento definido por la fila de conexión. Inherente dentro de esta operación de escritura está el funcionamiento de lógica de negocio apropiada y la lógica de validación. Este método es empacado por el apoderado de servicio web 1408 y enviado a través de un mensaje de SOAP a través del canal de índigo al servicio web 1410 en la unión media. El servicio web 1410 implementa este método a través de llamados a una API de CDP 1420 en la unión media justo como si fuera cualquier otra aplicación. La clave para anotar aquí es que la lógica completa para Crear Cita() es corrida en la unión media. La Figura 16 y Figura 17 ilustran un diagrama de la lógica de aplicación que corre tanto en la unión de cliente como en la unión media. El flujo de datos/control a través de diferentes componentes y uniones en respuesta a llamados de método puede ser descrito en más detalle utilizando un ejemplo. El ejemplo inferior es similar al ejemplo discutido anteriormente. 1. vacío Agregar a Carta (Id de cliente de fila, id de producto de fila) 2. { 3. utilizando (Datos de Orden od = nuevos Datos de Orden()) 4. { 5. Carta de Compra carta = od. Cartas de Compra. Buscador. Filtro ( 6. "Id de Cliente = {0}", Id de cliente). Obtener PrimeroQ; 7. si(carta == nulo) 8. a través de nueva Excepción ("Sin carta de compra"); 9. Producto producto =od. Producto. Buscador. Filtro( 10. "Id de Producto = {0}", Id de producto). Obtener Primero(); 11. si(producto == nulo) a través de nueva Excepción ("Producto faltante"); 12. carta. Productos. Agregar(producto); 13. od.GuardarCambios(); 14. } 15. } 16. Como se puede ver en los ejemplos previos, la Línea 3 crea el contenido de almacenamiento, la Línea 5 y Línea 9 se relacionan a la consulta, y la Línea 12 se refiere a la actualización. Línea 13: Cambios de flujo. Se consideran las siguientes dos posibilidades: 1. BL está corriendo tanto en la unión de cliente como en la unión media: en este caso, el Alojamiento de Lógica del Negocio 416 en la unión de cliente corre la validación y la lógica de pre-guardado y llama al agente de alojamiento 1414 en la unión de cliente con IPersistir. Escribir (<vector de cambio>). El agente de alejamiento 1414 envía el llamado al servicio de alejamiento 1416 (como se ve en la Figura 17) en la Unión Media. El servicio de alejamiento 1416 ensucia la memoria caché de objeto 414 en la Unión Media y llama Guardar CambiosQ. Esto corre el BL y los pasos de persistencia como se describen anteriormente y regresa al servicio de alejamiento 1416, en donde el servicio de alejamiento 1416 después regresa al agente de alejamiento 1414 en la Unión de Cliente, que a su vez regresa al alojamiento de lógica del negocio 416. La lógica de post-guardado lateral de cliente puede no correr a través del alojamiento de lógica del negocio 416. 2. BL solo es corrido en la unión media. En este caso, el alojamiento de lógica del negocio 416 inmediatamente pasa el llamado al agente de alejamiento 1414 que a su vez lo envía al servicio remoto 1416. El procedimiento sucede en la unión media como se describió anteriormente. Una ventaja de correr BL en ambas uniones es que en el caso de errores en validación de lógica de pre-guardado, pueden ser atrapados en la unión de cliente sin tener que ir a través del costo de conectarse a la unión media. Una experiencia fuera de línea uniforme es una de las metas del sistema de almacenamiento de archivo a base de base de datos. Esto puede requerir un almacenamiento local 1602 que sincroniza datos con el almacenamiento remoto. El almacenamiento local 1602 además puede incluir coacciones/seguridad 1604. En este caso, el almacenamiento local 1602 está en la máquina sustancialmente similar, pero en un procedimiento diferente (que, en nuestra definición, aún es un despliegue de dos uniones). Ya que el modelo de programación para despliegues de tres uniones y dos. uniones son simétricos, es fácil para un servicio tal como sincronización operar entre el almacenamiento local 1602 y la unión media y mantener los datos en sincronía. Considere la Línea 2 del código ejemplar mostrado anteriormente. La consulta resultó en una operación de cruce de unión. En este ejemplo particular, había un objeto regresado (el objeto de Entrada de Programación). Sin embargo en general, esto potencialmente puede regresar un grupo de resultado muy grande. Comentarios similares aplican en Línea 5 del código previamente presentado ilustrativo. Existen dos emisiones que pueden ser consideradas, y que son pertinentes en un despliegue de tres uniones: • El cruce de unión es potencialmente costoso y de ahí puede no suceder implícitamente: no hay una indicación explícita en la línea 2 que esto resultará en una operación de cruce de unión, en otras palabras, se involucra "magia". La "magia" es utilizada aquí en el sentido que algo sucede sin que la aplicación sepa sobre él o que tenga la habilidad para controlar su ocurrencia. Muchas veces, la magia es buena; de hecho, es la meta de gran parte del software esconder la complejidad importante y hacer que las cosas sucedan "como si fuera magia". Sin embargo, en este caso particular, la gran experiencia ha mostrado que los escritorios de aplicación envían grandes consultas quiera o no quiera, asumiendo que el código inferior de alguna forma regresa gran parte de datos sin sofocar la red o estresar al servidor. Esto es un paradigma de diseño probado que cualquier magia de cruce de unión puede ser hecho explícito a la aplicación, con ello las prácticas de codificación con juicio alentadoras (es "seleccionar * necesario de <millón-incompleto-tabla>" o tal vez una cláusula DONDE puede ser empleada). Guardar en memoria caché lateral de cliente y operación sin estado: sin importar los intentos en la codificación con juicio, algunas veces cuando la aplicación necesita trabajar con un grupo de datos (potencialmente grande); frecuentemente, sabe lo que es este grupo de datos. Para optimizar el acceso de datos en tales casos, la aplicación debe tener la capacidad de correr la consulta, buscar el grupo de datos (potencialmente grande) y alojarlos localmente en la memoria caché. Otras consultas/clasificación/filtrado/cambios son hechos a la copia local de los datos. Finalmente una operación de flujo escribe los cambios de regreso al almacenamiento. Trabajar en la memoria caché significa que la unión media mantiene estado muy mínimo (o ninguno), de esa forma haciéndolo más clasif ¡cable. La solución es proporcionar un modelo desconectado explícito. Esto está caracterizado por el siguiente patrón: 1. La aplicación realiza una memoria caché de la siguiente forma: Contexto Local le = nuevo Contexto LocalQ; 2. La memoria caché local contendrá los resultados de una o más consultas, especificado como lo siguiente: le. Colección de Consulta. Agregar ("<consulta 1>"); le. Colección de Consulta. Agregar ("<consulta 2>"); //etc. 3. La aplicación "llena" el contexto local Ic.LlenarQ; 4. Trabaja en el contexto local justo como si lo hiciera con cualquier contexto de almacenamiento. Por ejemplo: Entradas de Programación = le. Entidades. Filtro por Tipo<Entrada de Programación>().Filtro( "Tiempo de lnicio>@0", nuevo Tiempo de Fecha( 2004, 10, 29, 9, 0, 0)). Obtener PrimeroQ; s. Presentar Nombre = s. Presentar Nombre + "[¡importante, por favor venga!]"; 5. Finalmente, envía cambios en masa al almacenamiento, especificado como lo siguiente: //se es el Contexto de Almacenamiento le. Guardar Cambios (se); Se debe notar como la aplicación puede ser explícita cuando desea que ocurra una operación de cruce de unión, el lc.llenar() en el paso 3, así que no hay magia impulsada por el código inocente. También se debe notar que todas las operaciones subsecuentes pueden ocurrir en la memoria caché local y de ahí el cruce de unión es minimizado (junto con el mantenimiento concomitante del estado de la unión media). Se debe apreciar el modelo implicado por fragmentos de código anteriormente es un poco similar al modelo de grupo de datos en ADO.NET. El CDP también puede proporcionar un modelo desconectado. Una aplicación de dos uniones no debe ser desplegada en un ambiente de tres uniones a menos que una de lo siguiente sea verdadero: (a) utiliza solo el modelo de programación desconectado o (b) está reescrito para utilizar el modelo de programación desconectado. El CDP toma un acercamiento tanto de los modelos de programación conectados como desconectados en despliegues de tres uniones. Las aplicaciones serán proporcionadas con una línea de guía que si "espera que sean desplegadas en un ambiente de tres uniones, entonces deben utilizar la memoria caché desconectada". Para establecer el contexto para la siguiente sección que discute almacenamientos de CDP, se debe notar que el universo de todos los datos de servidor de SQL está dividido en la siguiente jerarquía de 4 niveles: caso, base de datos, esquema, y tabla. La unidad conectable es un caso; una base de datos es un contenedor en el cual se definen la recuperación, restauración, y contestación. La combinación de una base de datos y un esquema proporcionan el contexto para consultas. El CDP utiliza una jerarquía de tres niveles: almacenamiento, esquema, y tipo. Un almacenamiento de CDP es la unidad conectable; un esquema proporciona contexto para consultas. Un esquema dado puede ser alojado por múltiples almacenamientos de CDP (por ejemplo, un grupo de tipos (esquema de CRM) puede ser desplegado en dos casos diferentes de CDP. Si se desea "similitud", entonces los mecanismos fuera del CDP (contestación, copiado en volumen) deben ser utilizados. Un almacenamiento de CDP dado puede tener múltiples esquemas desplegados en él, tal como un esquema de HR, esquema de contabilidad, etc. El nombrado y descubrimiento es discutido aquí. Considere la Línea 3 del siguiente código, discutido anteriormente.

Utilizando (Contexto de Almacenamiento se = nuevo Contexto de Almacenamiento(@\\corp001\a!macenamiento predeterminado)) Lo siguiente se dirige al nombrado de un almacenamiento de CDP y descubrimiento de almacenamiento disponibles. Un almacenamiento de CDP es definido más claramente. Existen dos posibilidades: 1. Es el almacenamiento real, físico, base de datos en un servidor real. 2. Es el almacenamiento lógico, el argumento para el ctor identifique un contenedor lógico de casos de entidad. En realidad, esto sería desplegado como una granja de almacenamientos físicos contestados y un servidor final frontal trabaja con un balanceador de carga para recoger el almacenamiento físico real que forma el contexto para esta sesión particular. En el modelo de CDP, un contexto de almacenamiento identifica un almacenamiento lógico no un almacenamiento físico. El CDP no especifica cómo los mecanismos de contestación, recuperación/restauración trabajan en el nivel dei almacenamiento físico.

Con respecto a un formato de un argumento de ctor, la fila de conexión es un identificador de recurso uniforme, o URI. Las estructuras de trabajo individuales pueden decidir un formato de nombrado alternativo para utilizar sus aplicaciones. Por ejemplo, el UAF puede elegir dejar que sus aplicaciones establezcan un contexto de almacenamiento al especificar un nombre de UNC (por ejemplo, \\servidor\compartir). Sin embargo, siempre debe ser posible conectarse a un almacenamiento de CDP a través de un URI; en otras palabras, cualquiera de los nombres alternativos utilizados por una estructura de trabajo deben tener un delineado bien definido para el URI de nivel de CDP correspondiente. El CDP no especifica cómo pueden ser descubiertos los almacenamientos. Se espera que las aplicaciones puedan utilizar mecanismos y depósitos existentes (UDDI, por ejemplo) para sus propósitos. Además, una estructura de trabajo puede especificar sus propios métodos para descubrimiento. En esta sección ios - servicios de CDP adicionales que las aplicaciones pueden apalancar son descritos. Estos servicios incluyen: • Servicios de observador/notificación • Servicios de sincronización • Servicios de memoria caché explícitos • Operaciones de utilidad Esta sección debe ser considerada descriptiva, no de arquitectura. Servicio de Observador/Notificación. Las notificaciones (Observadores de aka) proporcionan la capacidad de hacer surgir notificaciones asincrónicas de cambios a entidades (dato) persistidas en el almacenamiento importante. Una aplicación (o cualquier otro componente) pueden utilizar este servicio para observar los cambios en entidades persistidas. Una aplicación tendrá el control completo de lo que está observando y que tan frecuentemente desea ser notificado. Por ejemplo, las Notificaciones de Vistas de Aplicación Ricas (RAV) son construidas utilizando observadores; una aplicación de navegación lateral de cliente puede utilizar RAVs para reaccionar activamente a cambios de datos que utilizan estas notificaciones. El modelo de programación de CDP soporta una clase de Observador que es capaz de observar cambios en entidades. El mecanismo de observador de entidad es suficiente para estructuras de trabajo y aplicaciones para construir abstracciones de observador de nivel superior. Por ejemplo, un sistema de almacenamiento de archivo a base de base de datos puede construir Artículo, Extensión de Artículo y abstracciones de observador de enlace en la abstracción de observador de entidad (por ejemplo, se debe notar que una entidad es la pieza más granular de datos que puede ser observada). Servicios de Sincronización. Las aplicaciones descritas para el CDP así como estructuras de trabajo en la parte superior del mismo se beneficiarán de los siguientes servicios relacionados con sincronización: 1) Anotación de esquema para rastreo de cambio. Los diseñadores de esquema pueden designar límites de unidad de cambio para sus tipos de entidad. Las especificaciones de unidad de cambios controla el funcionamiento del servicio de Rastreo de Cambio. 2) Rastreo de cambio. De amplia forma invisible para las aplicaciones, mantiene versiones para unidades de cambio durante todas las operaciones de CDP, así como registros de operaciones críticas tal como eliminaciones de entidad. El rastreo de cambio funciona correctamente incluso si las aplicaciones de legado continúan haciendo cambios sobrepasando el tiempo de funcionamiento de CDP. 3) Enumeración de Cambio. Permite que una aplicación de CDP recupere el grupo de entidades y sus unidades de cambio que han sido modificadas desde cierta marca de agua. Los cambios son regresados como entidades de CDP y Grupos Incompletos. Un grupo de servicios es proporcionado para mantenimiento de marca de agua enfrente de fallas, recuperaciones y restauraciones, y topologías de sincronización complejas. 4) Detección de Conflicto. Permite a una aplicación de CDP determinar si una operación de CDP (tal como una actualización) tendrá un conflicto con las operaciones que ya han sido realizadas (otra vez, basándose en una marca de agua). Utilizando esta funcionalidad central, las estructuras de trabajo pueden construir servicios de sincronización adicionales, de nivel superior. Servicios de Memoria Caché Explícitos. El servicio de memoria caché explícito en el CDP proporciona desempeño/clasificación mejorada de aplicaciones, soporta modelo de programación desconectado (por ejemplo, se nota que un modelo de programación desconectado puede ser implementado sin el beneficio de una memoria caché explícita caracterizada completa), y soporta datos transitorios. Lo siguiente puede ser caracterizado en la memoria caché explícita: • Tipos diferentes de memoria caché de datos (por ejemplo, entidades, datos no estructurados, y datos de XML). • Diferentes modos de acceso de memoria caché (por ejemplo, Solo de Lectura, Lectura y Escritura, Compartidos, etc.). • Coherencia de memoria caché con los datos almacenados (por ejemplo, para datos almacenados en servidor de SQL) • Memoria caché (cierto tipo de datos, por ejemplo, datos de contexto de sesión) coherencia a través de múltiples memorias caché de CDP para falla de aplicación. La superficie de programación para la memoria caché explícita puede exponer: • Creación de memorias caché; • Población de memorias caché; • Memorias caché persistentes (o parte de datos) para los almacenamientos importantes; • Consulta y actualización en datos guardados en memoria caché. Operaciones de Utilidad. El CDP proporciona soporte para variedad de operaciones administrativas y de utilidad en entidades y colecciones de entidades. Un muestreo de tales operaciones incluye: Copiar, Mover, Serializar/Deserializar, y Recuperar/Restaurar. Cambiando ahora a la Figura 18, el modelo de artículo que utiliza entidades es ilustrado. La implementación de sistema de almacenamiento de archivo a base de base de datos (por ejemplo, WINFS) abarca aspectos tanto de CDP como de la Estructura de Trabajo de Aplicación de Usuario (UAF). Se debe notar que la arquitectura de CDP no significa una reescripción del sistema de almacenamiento de archivo a base de base de datos, sino simplemente una resegmentación de los componentes del mismo. En esta sección, la UAF es definida y después examinada con respecto a cómo los varios componentes del sistema de almacenamiento de archivo a base de base de datos pueden ser segmentados en UAF y CDP. El UAF es una estructura de trabajo de CDP que está relacionada con los datos de "usuario" de moldeo. Los datos de usuario se refieren a los datos comunes, de todos los días que son pertinentes a un usuario final típico, tal como documento, fotografía, música, contacto, etc. Para la infraestructura de CDP básica, el UAF agrega: • Tipo de artículo base (y tipos relacionados) • Tipos reales para modelar los datos de usuario • Coacciones tal como manejo de tiempo de vida, contenido etc.

• Cosas que un usuario puede hacer con los artículos: Mover, copiar, Renombrar, Serializar... • Construcciones de organización para artículos: contenedores, listas, autopista, anotaciones, categorías. • Abstracciones de programación de usuario final en artículos (tal como creación de reglas). Se debe apreciar y entender que para los desarrolladores de aplicación, el CDP es el modelo de programación de UAF. Específicamente, la Figura 18 ilustra la noción de un artículo en UAF y como está realmente "derivado de diferentes entidades. Un artículo de documento 1802 puede, estar derivado de diferentes entidades tal como, pero no limitándose a, un documento 1804, una pluralidad de enlaces 1806 y una extensión de documento 1808. Un artículo de autor 1810 puede estar derivado de diferentes entidades tal como, pero no limitándose a, un autor 1812, y una extensión de autor 1814. Cambiando a la Figura 19, los mecanismos extensibles son ilustrados para implementar varias funcionalidades al implementar la UAF en la parte superior del CDP. Ya que el UAF está construido en la parte superior de CDP puede utilizar mecanismos de extensibilidad de CDP para implementar la funcionalidad adicional. La construcción del UAF en el CDP puede incluir varios diseños y/o componentes. Un almacenamiento 1902 puede incluir una máquina de coacción de CDP 1904, en donde la máquina de coacción de CDP 1904 incluye al menos una coacción de UAF 1906. Un tiempo de funcionamiento de CDP 1908 puede incluir un alojamiento de BL 1912 que puede incluir un comportamiento de artículo de UAF 1910. El comportamiento de artículo de UAF 1910 además puede incluir un comportamiento unible UAF 1914. En la parte superior del tiempo de funcionamiento del CDP 1908, puede existir cualquier otro de los servicios de UAF 1916.

El UAF utiliza máquina de coacción de CDP para impulsar semánticos de artículo (y otros semánticos de tipo). Estos son creados utilizando CSDL y el generador de esquema crea coacciones del nivel de almacenamiento para ellos. Los comportamientos de artículo, tal como Mover, Serializar, etc., son implementados utilizando mecanismos de BL de CDP. Los tipos de UAF pueden tener comportamientos unibles asociados con ellos. Estos comportamientos son creados a través de un desarrollador de aplicación de UAF después de que los tipos han sido diseñados y desplegados. Otros servicios de UAF tal como sincronización, control de metadatos, etc., son implementados como códigos de CDP regular. Tomados en conjunto, estas piezas separas de lógica, corren en varios diseños del CDP, del UAF. La descripción más delante es aplicable para dividir el sistema de almacenamiento de archivo a base de base datos entre CDP y UAF. Las siguientes capacidades en el sistema de almacenamiento de archivo a base de base de datos pertenecen en el diseño de CDP: 1. Delineado O-R, delineado de entidades para tabla. El CDP soporta delineados de no perspectiva para controlar escenarios de POCO y escenarios de servidos de sistema de almacenamiento de archivo a base de base de datos. Esto también incluye actualizar delineado, proporcionar operaciones de CUD básicas contra tipos de entidad (y derivados). 2. Delineado de consulta de ORuta. 3. Implementación de Entidad y otros tipos centrales de CDM. 4. Contexto de Almacenamiento y Buscador de Almacenamiento, junto con sesión y manejo de transacción. 5. Memoria caché de sesión, lógica de flujo de memoria caché (Guardar Cambio). 6. Rastreo de Cambio. 7. Observadores de tipos de entidad. 8. Servios de cursor, incluyendo RAV. 9. Mecanismos de imposición de seguridad del nivel de artículo (seguridad de nivel incompleto, los predicados de seguridad se incluyen en vistas de tipo). Las siguientes capacidades en un sistema de almacenamiento de archivo a base de base de datos pertenecen a diseño de UAF: 1. Comportamiento unible, por caso. 2. Metadatos de API de sistema de almacenamiento de archivo a base de base de datos (clases de clientes y comportamientos expresados como metadatos de CLR). 3. Métodos de nivel de artículo (copiar, mover, serializar, renombrar). 4. Sincronización, alcances de sincronización enumeración de cambio. 5. Observadores en contenedores. 6. Tabla de ruta por cálculo de nombre de ruta eficiente y dominios de artículo. 7. Controladores de metadatos. 8. Espacio de nombre de sistema de almacenamiento de archivo a base de base de datos. 9. Código para impulsar integridad de artículo (contenedor, partes de artículo, enlaces, corrientes de archivo, manejo de tiempo de vida, etc.). La Figura 20 ilustra un ejemplo de una aplicación de LOB siendo implementa en el CDP. Más adelante, los requerimientos de estructura de trabajo de LOB son descritos y cómo pueden ser soportados por ei CDP. Una aplicación de estructura de trabajo del negocio puede ser considerada una aplicación de LOB. El grupo de característica central para aplicación de negocio es empaquetada como componentes del negocio compartido. Los grupos de estos componentes manejan diferentes funciones del negocio tal como anzuelo general en finanzas para servicios de automatización de fuerza de ventas en CRM. La característica clave es que estos componentes son desconocidas, extensibles, y pueden ser utilizados para servir las necesidades de múltiples mercados dependiendo en que nivel de funcionalidad y complejidad es utilizado. La Estructura de trabajo de negocio (BF) puede consistir de las Estructura de Trabajo de Soluciones del Negocio y la Estructura de Trabajo de Aplicación del Negocio. La Estructura de Trabajo de Soluciones del Negocio proporciona funcionalidad útil para construir la mayoría de aplicación en el negocio. Esto incluye tipos de datos de negocio fundamentales, tal como Dinero y Cantidad; las entidades del negocio amplios de familia de aplicación, tal como cliente, unidad de negocio, información de moneda corriente múltiple y términos de pago; los bloques de construcción para implementar patrones de negocio comunes, tal como Transacción del Negocio y Cuenta; y patrones de procedimiento del negocio comunes, tal como para colocar una transacción del negocio. La Estructura de trabajo de solución es escrita utilizando la Estructura de Aplicación del Negocio, que soporta componentes de escritura al ofrecer servicios ricos para acceso de datos, seguridad, interfase de usuario, flujo de trabajo, modelo de programación de componente y mucho más. Si el modelo del negocio y las reglas definidas por la Estructura de Trabajo de Soluciones no son apropiadas para una aplicación, entonces puede ser basada y el desarrollador de la aplicación directamente puede utilizar la Estructura de Trabajo de Aplicación. La Estructura de Trabajo de Aplicación de negocio proporciona un modelo de programación preescriptivo que toma la estructura de trabajo de .NET y enfoca sus capacidades hacia aplicaciones del negocio. Mientras es poco extensible, hace un número de decisiones para el desarrollador de aplicación que una solución más general no lo haría, aumentando la productividad de consistencia en implementación y estructura para todas la aplicaciones en el ecosistema que las utiliza. La Estructura del Trabajo de Aplicación del Negocio proporciona un modelo de programación y servicios para escribir aplicaciones a base de web, de OLTP distribuidas. Puede contener lógica de no negocio particular para cualquier producto y de esa forma es adecuada no solo para acceder a aplicaciones del negocio sino también cualquier otra aplicación que se ajusta a su perfil básico. Proporciona un grupo de servicios que proporciona soporte para acceso de datos, envío de mensajes (tal como el uso de SOAP y otros protocolos), flujo de trabajo, comisiones de evento, activación de caso, diagnósticos, configuración, manejo de metadatos (reflexión), seguridad de componente de aplicación, globalizacíón, una cubierta de escritorio de negocio y más. Estos requerimientos en CDP principalmente vienen de la porción de Estructura de Trabajo de Aplicación del Negocio de BF, particularmente en las áreas de acceso de datos y alojamiento de lógica de datos. La Persistencia de Entidad (EP), el subsistema de acceso de datos en la Estructura de Trabajo del Negocio soporta un modelo de datos rico basado en una estructura de trabajo de delineado relacional de objeto pragmático. El desarrollador tapa con la relación de objeto con objetos (C#) que son delineados a filas relaciónales. Los conceptos de moldeado de dato central son entidades y relaciones entre entidades. El modelo de datos común (CDM) esencialmente soporta los requerimientos de modelo de datos de acceso de datos de BF. MBF EP requiere soporte para las siguientes acciones de acceso de datos: • Crear, leer, actualizar y eliminar entidad. • Consultas ad hoc que regresan un grupo de datos. • Operaciones a base de grupos que se ejecutan en la base de datos. BF prescribe una estructura de trabajo de agente/servicio para soportar configuraciones distribuidas, orientadas a servicio. Dado algunas piezas de funcionalidad del negocio, el agente corre tan cerca del usuario de la funcionalidad como sea posible y el servicio corre tan cerca de los datos como sea posible. "Tan cerca como sea posible" difiere con cada escenario de despliegue y tipo de usuario. El patrón de agente/servicio proporciona flexibilidad de despliegue de despliegue de dos uniones (cliente-servidor) a uniones múltiples. En tales despliegues, los servicios proporcionan interfases que pueden ser invocadas a través de límites de servicio; los agentes típicamente buscan datos cerca del cliente (usuarios), los operan en ellos mismos, y propagan los cambios al servicio. En particular, la Figura 20 ¡lustra como una estructura de trabajo de LOB y/o aplicación pueden utilizar el CDP. La estructura de trabajo y aplicación construida que utilizan la estructura de trabajo pueden estar alojadas en un servidor de ultra aplicación 2002 en la unión media. Puede proporcionar servicios de LOB estándares tal como, pero no limitándose a, flujo de trabajo, envío de mensaje, procedimientos del negocio, etc., en la forma de una interfase de servicios web para una aplicación de cliente 2004. El servidor de ultra aplicación 2002 puede utilizar el CDP para crear coacciones de almacenamiento 2006 (a través de una máquina de coacción de CDP 2014) y lógica de negocio céntrico de datos 2008. La aplicación de cliente 2004 puede invocar el método de servicios web (por ejemplo, utilizando un apoderado de servicio web 2010 y una interfase de servicio web 2012) en un canal Índigo. Adicionalmente, puede hacer uso del CDP en la unión de cliente para sus necesidades de acceso de persistencia/datos de objeto. Lo siguiente puede ser satisfecho por el CDP: 1) Manejo de Sesión; 2) CRUD; 3) Soporte (por ejemplo, abstracción de entidad, extensión de entidad) de Modelo de Datos Común (CDM); 4) Consulta (por ejemplo, ad hoc, entidad); 5) Memoria Caché de Objeto Funcionando (implícito); 6) Manejo de Concurrencia (por ejemplo, optimista, niveles de aislamiento, detección de conflicto, etc.); 7) Lógica del Negocio (por ejemplo, en método, validación/predeterminado, patrones de propiedad, eventos); 8) Extensión de Seguridad; 9) Delineado (consulta, esquema) con proveedores (por ejemplo, relacional, sistemas de almacenamiento de archivo a base de base de datos); 10) Capacidad para extender metadatos (soporta otros usos de entidad); 11) Establecer Operaciones; 12) Capacidad para llamar procedimientos almacenados; y 13) despliegues de N uniones. La presencia de entidad de BF es un ajuste natural para el CDP. La mayoría de los requerimientos de persistencia de BF son completamente soportados por el CDP. Algunos de los requerimientos de SOA también son dirigidos por el CDP. Sin embargo, el soporte completo para el modelo de agente/servicio, operaciones y procedimiento de negocio de BF pueden ser construidos en el CDP como estructura de trabajo de LOB. La Estructura de Trabajo de Soluciones de Negocio de MBF también son diseñadas en la parte superior del CDP.

Las Figuras 21 y 22 ilustran metodologías de acuerdo con la innovación sujeta. Para simplicidad de explicación, las metodologías son ilustradas y descritas como una serie de datos. Se debe entender y apreciar que la innovación sujeta no está limitada por los actos ¡lustrados y/o por el orden de actos, por ejemplo los actos pueden ocurrir en varias órdenes y/o concurrentemente, y con otros actos no presentadas y descritas aquí. Además, no todos los actos ¡lustrados pueden ser requeridos para implementar las metodologías de acuerdo con la innovación sujeta. Además, aquellos expertos en la técnica entenderán y apreciarán que las metodologías alternativamente pueden ser representadas como una serie de estados interrelacionados a través de un diagrama de estado o eventos. La Figura 21 ilustra una metodología 2100 que facilita manejar el flujo de datos dentro de varios componentes de CDP. En el número de referencia 2102, una aplicación crea un objeto de datos de orden, la clase de datos de orden puede representar un tipo de grupo de tabla que fue descrito en un esquema de CDM. El objeto de datos de orden crea un objeto de contexto de almacenamiento que puede ser configurado como sea necesario para interactuar con el almacenamiento. En el número de referencia 2104, se abre una conexión para el almacenamiento al iniciar una sesión y crear un contexto de transacción en donde se establece un contexto de seguridad. En el número de referencia 2106, se regresa un caso del contexto de almacenamiento a la aplicación.

En el número de referencia 21 08, se expone una interfase para recuperar objetos basados en una consulta de CDM. En el número de referencia 21 10, se delinea una consulta en SQL mientras se aplica la seguridad apropiadamente. Además, la aplicación/usuario solo puede ver datos que están permitidos a ver. En el número de referencia 21 12, los resultados de la consulta son regresados * al tiempo de funcionamiento de CDP y reg resados a la aplicación. En el número de referencia 21 14, la función de g uardar cambios puede ser llamada en el objeto de contexto de almacenamiento encapsu lado con ei fin de fluir cambios. La Figura 22 ¡ lustra una metodolog ía q ue facilita desplegar el CDP a través de mú ltiples estructuras de trabajo diferentes, en donde las aplicaciones pueden estar relacionadas con cada estructura de trabajo. En el n úmero de referencia 2202, un almacenamiento es creado y puede almacenar datos estructurados, semi-estructurados, y no estructurados. En el número de referencia 2204, se crea un CDP y se cu bren en el almacenamiento de datos. Continuando en el n úmero de referencia 2206, mú ltiples diferentes estructuras de trabajo con aplicaciones asociadas pueden acceder al almacenamiento de datos. En el número de referencia 2208 , se proporciona datos compartidos para aplicaciones diferentes en estructuras de trabajo diferentes. En otras palabras, los datos dentro del almacenamiento de datos pueden ser compartidos entre una pluralidad de diferentes aplicaciones sin importar la estructura de trabajo respectiva . En el número de referencia 2210, los datos privados pueden ser utilizados para que los datos privados puedan ser específicos para una aplicación particular en una estructura de trabajo particular. Haciendo referencia ahora a la Figura 23, se ¡lustra un diagrama de bloque de una computadora operable para ejecutar la arquitectura descrita del CDP y componentes y/o procedimientos asociados. Con el fin de proporcionar contexto adicional para varios aspectos de la arquitectura sujeta, la Figura 23 y la siguiente discusión pretenden proporcionar una breve descripción general de un ambiente de cómputo adecuado 2300 en el cual varios aspectos de la innovación pueden ser implementados. Mientras la arquitectura ha sido descrita anteriormente en el contexto general de instrucciones ejecutables por computadora que pueden correr en una o más computadoras, aquellos expertos en la técnica reconocerán que la arquitectura también puede ser implementada en combinación con otros módulos de programa y/o como una combinación de hardware y software. Generalmente, los módulos de programa incluyen rutinas, programas, componentes, estructuras de datos, etc., que realizan tareas particulares o implementan tipos de datos abstractos particulares. Además, aquellos expertos en la técnica apreciarán que los métodos inventivos pueden ser practicados con otras configuraciones de sistema de computadora, incluyendo sistemas de computadora de procesador individual o multiprocesador, minicomputadoras, macrocomputadoras, así como computadoras personales, dispositivos de cómputo portátiles, electrónica a base de microprocesador o programable para el consumidor, y similares, cada uno de los cuales puede ser operativamente acoplado a uno o más dispositivos asociados. Los aspectos ilustrados también pueden ser practicados en ambientes de cómputo distribuidos en donde ciertas tareas son realizadas a través de dispositivos de procesamiento remotos y están enlazados a través de una red de comunicaciones. En un ambiente de cómputo distribuido, los módulos de programa pueden estar localizados tanto en dispositivos de almacenamiento de memoria locales como remotos. Una computadora típicamente incluye una variedad de medios legibles por computadora. Los medios legibles por computadora pueden ser cualquier medio disponible que puede ser accedido por la computadora e incluye tanto medios volátiles como no volátiles, medios removibles y no removibles. A manera de ejemplo, y no de limitación, los medios legibles por computadora pueden comprender medios de almacenamiento de computadora y medios de comunicación. Los medios de almacenamiento de computadora incluyen tanto medios volátiles como no volátiles, removibles y no removibles implementados en cualquier método o tecnología para almacenamiento de información tal como instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos. Los medios de almacenamiento de computadora incluyen, pero no están limitados a, RAM, ROM, EEPROM, memoria instantánea u otra tecnología de memoria, CD-ROM, discos de vídeo digital (DVD) u otro almacenamiento de disco óptico, casetes magnéticos, cinta magnética, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que pueda ser utilizado para almacenar la información deseada y que pueda ser accedido por la computadora. Los medios de comunicación típicamente representan instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada tal como una onda portadora u otro mecanismo de transporte, e incluyen cualquiera medio de suministro de información. El término "señal de datos modulada" significa una señal que tiene una o más de sus características fijadas o cambiadas de tal manera que codifica la información en la señal. A manera de ejemplo, y no de limitación, los medios d.e comunicación incluyen medios mediante cables, tales como una red con cables o una conexión de cable directo, medios inalámbricos tales como medios acústicos, RF, infrarrojos y otros medios inalámbricos. También se deben incluir dentro del alcance de medios legibles por computadora, combinaciones de cualquiera de los anteriores. Con referencia de nuevo a la Figura 23, el ambiente ilustrativo 2300 para implementar varios aspectos incluye una computadora 2302, ia computadora 2302 incluyendo una unidad de procesamiento 2304, una memoria de sistema 2306 y un conductor común de sistema 2308. El conductor común de sistema 2308 acopla componentes de sistema incluyendo, pero no limitándose a, la memoria de sistema 2306 a la unidad de procesamiento 2304. La unidad de procesamiento 2304 puede ser cualquiera de varios procesadores comercialmente disponibles. Los microprocesadores dobles y otras arquitecturas de procesador múltiple también pueden ser empleados como la unidad de procesamiento 2304. El conducto común de sistema 2308 puede ser cualquiera de varios tipos de estructura de conductor común que además pueden interconectarse a un conductor común de memoria (con o sin un controlador de memoria), un conductor común periférico, y un conductor común local que utiliza cualquiera de una variedad de arquitecturas de conductor común comercialmente disponibles. La memoria de sistema 2306 incluye memorias solo de lectura (ROM) 2310 y memoria de acceso aleatorio (RAM) 2312. Un sistema de entrada/salida básico (BIOS) es almacenado en una memoria no volátil 2310 tal como RAM, ROM, EEPROM, cuyo BIOS contiene las rutinas básicas que ayudan a transferir información entre elementos dentro de la computadora 2302, tal como durante el arranque. La RAM 2312 también puede incluir una RAM de alta velocidad tal como, RAM estática para guardar en memoria caché datos. La computadora 2302 además incluye una unidad de disco duro interna (HDD) 2314 (por ejemplo, EIDE, SATA), cuya unidad de disco duro interno 2314 también puede estar configurada para uso externo en una cubierta adecuada (no mostrada), una unidad de disco flexible magnético (FDD) 2316, (por ejemplo, para leer de o escribir a un disquete removible 2310) y una unidad de disco óptico 2320, por ejemplo, que lee un disco CD-ROM 2322 o, para leer de o escribir a otros medios ópticos de alta capacidad tal como el DVD). La unidad de disco duro 2314, unidad de disco magnético 2316 y unidad de disco óptico 2320 también están conectadas al conductor común de sistema 2308 a través de una ¡nterfase de unidad de disco duro 2324, una interfase de unidad de disco magnético 2326 y una interfase de unidad óptica 2328, respectivamente. La interfase 2324 para implementaciones de unidad externa incluye al menos uno o ambos de las tecnologías de interfase de Conductor Común en Serie Universal (USB) y IEEE 1394. Otras tecnologías de conexión de unidad externas están dentro de la contemplación. Las unidades y sus medios legibles por computadora asociados proporcionan almacenamiento no volátil de datos, estructuras de datos, instrucciones ejecutables por computadora, y así sucesivamente. Para la computadora 2302, las unidades y sus medios acomodan el almacenamiento de cualquiera de los datos en un formato digital adecuado. Aunque la descripción de medios legibles por computadora anterior se refiere a un HDD, un disquete magnético removible, y un medio óptico removible tal como un CD o DVD, se debe apreciar por aquellos expertos en la técnica que otros tipos de medios que son legibles por una computadora, tal como unidades zip, casetes magnéticos, tarjetas de memoria instantánea, cartuchos, y similares, también pueden ser utilizados en el ambiente operativo ilustrativo, y además, que cualquiera de tales medios puede contener instrucciones ejecutables por computadora para realizar los métodos de la arquitectura. Un número de módulos de programa puede estar almacenado en las unidades y RAM 2312, incluyendo un sistema operativo 2330, uno o más programas de aplicación 2332, otros módulos de programa 2334 y datos de programa 2336. Todos o porciones del sistema operativo, aplicaciones, módulos, y/o datos pueden estar guardados en memoria caché en la RAM 2312. Se debe apreciar que los varios sistemas operativos comercialmente disponibles y combinaciones de sistemas operativos pueden ser implementados con la arquitectura sujeta. Un usuario puede ingresar comandos e información en la computadora 2302 a través de uno o más dispositivos de entrada alámbricos/inalámbricos, por ejemplo, un teclado 2338 y un dispositivo de señalamiento, tal como un ratón 2340. Otros dispositivos de entrada (no mostrados) pueden incluir un micrófono, un control remoto de IR, una palanca de mandos, una almohadilla de juegos, una pluma de aguja, una pantalla sensible al tacto, o similares. Estos y otros dispositivos de entrada están frecuentemente conectados a la unidad de procesamiento 2304 a través de una interfase de dispositivo de entrada 2342 que está acoplada al conductor común de sistema 2308, pero pueden estar conectados a través de otras interfases, tal como un puerto paralelo, un puerto en serie de IEEE 1394, un puerto de juego, un puerto de USB, una interfase de IR, etc.

Un monitor 2344 u otro tipo de dispositivo de presentación también está conectado al conductor común de sistema 2308 a través de una interfase, tal como un adaptador de vídeo 2346. Además del monitor 2344, una computadora típicamente incluye otros dispositivos de salida periféricos (no mostrados), tal como bocinas, impresoras, etc. La computadora 2302 puede operar en un ambiente en red que utiliza conexiones lógicas a través de comunicaciones alámbricas y/o inalámbricas a una o más computadoras remotas, tal como una computadora(s) remota 2348. La computadora(s) remota 2348 puede ser una estación de trabajo, una computadora de servidor, un enrutador, una computadora personal, computadora portátil, aplicación de entretenimiento a base de microprocesador, un dispositivo par u otro nodo de red común, y típicamente incluye muchos o todos los elementos descritos relativos a la computadora 2302, aunque, para propósitos de brevedad, solo se ilustra un dispositivo de memoria/almacenamiento 2350. Las conexiones lógicas ilustradas incluyen conectividad alámbrica/inalámbrica para una red de área local (LAN) 2352 y/o redes más grandes, por ejemplo, una red de área amplia (WAN) 2354. Tales ambientes en red de LAN y WAN están comúnmente ubicados en oficinas y compañías, y facilitan redes de computadora extendidas en empresa, tal como intranets, todas pueden estar conectadas a una red de comunicaciones global, por ejemplo, Internet. Cuando se utiliza en un ambiente de red de LAN, la computadora 2302 está conectada a la red local 2352 a través de una interfase o adaptador de red de comunicación alámbrica y/o inalámbrico 2356. El adaptador 2356 puede facilitar comunicación alámbrica o inalámbrica al LAN 2352, que también puede incluir un punto de acceso inalámbrico dispuesto en él para comunicarse con el adaptador inalámbrico 2356. Cuando se utiliza en un ambiente en red de WAN, la computadora 2302 puede incluir un módem 2358, o está conectado a un servidor de comunicaciones en la WAN 2354, o tiene otros medios para establecer comunicaciones en la WAN 2354, tal como a través de Internet. El módem 2358, que puede ser interno o externo y un dispositivo alámbrico o inalámbrico, está conectado al conductor común de sistema 2308 a través de la interfase de puerto en serie 2342. En un ambiente en red, los módulos de programa ilustrados relativos a la computadora 2302, o porciones de la misma, pueden estar almacenados en el dispositivo de memoria/almacenamiento remoto 2350. Se debe apreciar que las conexiones en red mostradas son ilustrativas y se pueden utilizar otros medios para establecer un enlace de comunicaciones entre las computadoras. La computadora 2302 es operable para comunicarse con cualquiera de los dispositivos inalámbricos o entidades operativamente dispuestas en la comunicación inalámbrica, por ejemplo, una impresora, escáner, computadora de escritos y/o portátil, asistente de datos portátil, satélite de comunicaciones, cualquier pieza de equipo o ubicación asociada con una etiqueta detectable inalámbricamente (por ejemplo, un quiosco, puesto de revistas, recámaras) y teléfono. Esto incluye al menos tecnologías inalámbricas Wi-Fi y Bluetooth™. De esa forma, la comunicación puede ser una estructura predefinida como con una red convencional o simplemente una comunicación ad hoc entre al menos dos dispositivos. La Wi-Fi, o Fidelidad Inalámbrica, permite la conexión a Internet desde un sillón en casa, una cama en un cuarto de hotel, o un cuarto de conferencias en el trabajo, sin cable. La Wi-Fi es una tecnología inalámbrica similar a esa utilizada en un teléfono celular que permite a tales dispositivos, por ejemplo, computadoras, enviar y recibir entradas y salidas de datos; en cualquier parte dentro del rango de una estación base. Las redes de Wi-Fi utilizan tecnologías de radio llamadas IEEE 802.11 (a, b, g, etc.) para proporcionar conectividad inalámbrica segura, confiable, rápida. Una red Wi-Fi puede ser utilizada para conectar computadoras una con otra, a Internet, y a redes alámbricas (que utilizan IEEE 802.3 o Ethernet). Las redes Wi-Fi operan en bandas de radio 2.4 y 5 GHz sin licencia, en una tasa de datos de 11 Mpbs (802.11a) o 54 Mbps (802.11b), por ejemplo, o con productos que contienen ambas bandas (bandas dobles), para que las redes puedan proporcionar desempeño en mundo real similar a las redes de Ethernet alámbricas del 10BaseT básicas utilizadas en muchas oficinas. Haciendo referencia a la Figura 24, se ilustra un diagrama de bloque esquemático de un ambiente de cómputo ilustrativo 2400 que puede ser utilizado por el CDP y componentes respectivos y/o procedimientos para proporcionar manejo de datos. El sistema 2400 incluye uno o más cliente(s) 2402. El cliente(s) 2402 puede ser hardware y/o software (por ejemplo, argumento, procedimientos, y dispositivos de cómputo). El cliente(s) 2402 puede alojar galletas (cookies) y/o información contextúa! asociada al emplear la arquitectura, por ejemplo. El sistema 2400 también incluye uno o más servidor(es) 2404. El servidor(es) 2404 también puede ser hardware y/o software (por ejemplo, argumentos, procedimientos, dispositivos de cómputo). Los servidores 2404 pueden alojar argumentos para realizar transformaciones al emplear la arquitectura, por ejemplo. Una comunicación posible entre un cliente 2402 y un servidor 2404 puede estar en la forma de un paquete de datos adaptado para ser transmitido entre dos o más procedimientos de computadora. El paquete de datos puede incluir una galleta y/o información contextual asociada, por ejemplo. El sistema 2400 incluye una estructura de trabajo de comunicación 2406 (por ejemplo, una red de comunicación global tal como Internet) que puede ser empleada para facilitar comunicaciones entre el cliente(s) 2402 y el servidor(es) 2404. Las comunicaciones pueden ser facilitadas a través de una tecnología alámbrica (incluyendo fibra óptica) y/o inalámbrica. El cliente(s) 2402 está operativamente conectado a uno o más almacenamientos(s) de datos de cliente 2408 que puede ser empleado para almacenar información local para el cliente(s) 2402 (por ejemplo, galleta(s) y/o información contextual asociada). Similarmente, el servidor(es) 2404 está operativamente conectado a uno o más almacenamiento(s) de datos de servidor 2410 que puede ser empleado para almacenar información local para los servidores 2404. Lo que se ha descrito anteriormente incluye ejemplos. Por supuesto, no es posible describir toda combinación concebible de componentes o metodologías para propósito de describir ia arquitectura sujeta, pero un experto ordinario en la técnica puede reconocer que son posibles muchas otras combinaciones y cambios de la arquitectura. Por consiguiente, la arquitectura pretende abarcas todas tales alteraciones, modificaciones y variaciones que caen dentro del espíritu y alcance de las reivindicaciones anexas. Además, hasta el punto que el término "incluye" es utilizada ya sea en la descripción detalla o las reivindicaciones, tal término pretende ser inclusivo en una forma similar al término "que comprende" como "comprendiendo" es interpretado cuando se emplea como una palabra de transición en una reivindicación.

Claims

REIVINDICACIONES

1.- Una plataforma de datos que facilita el manejo de datos al proporcionar servicios de datos accesibles a través de una pluralidad de diferentes estructuras de trabajo de aplicación que permiten el acceso uniforme a datos, que comprende: una interfase de programa de aplicación (API) que facilita comunicarse a aplicaciones en la forma de al menos uno de una clase pública, una interfase, y una función de ayudante estático; un componente de tiempo de funcionamiento que se conecta a la API y proporciona al menos uno del delineado de relación de acceso, delineado de consulta, e imposición de coacciones; y un modelo de datos común que divide a una interfase de datos que es común para la pluralidad de diferentes estructuras de trabajo de aplicación.

2.- La plataforma de acuerdo con la reivindicación 1, en donde el modelo de datos común facilita la creación de al menos de un tipo específico de dominio, una coacción y una relación.

3.- La plataforma de acuerdo con la reivindicación 2, en donde el tipo específico de domino es un tipo de entidad que es una especificación para un agrupamiento de al menos uno de propiedad y un método, cuyo tipo específico de dominio emplea al menos uno de una entidad, una tabla, un grupo de tabla, y una relación.

4.- La plataforma de acuerdo con la reivindicación 3, en donde un esquema define al menos uno de la entidad, la relación, el grupo de tabla para que un espacio de nombre está asociado con él.

5.- La plataforma de acuerdo con la reivindicación 2, en donde el modelo de datos común define un lenguaje de consulta en el sistema de tipo de dominio específico, en don'de el lenguaje de consulta permite consultas ricas contra una estructura de objeto que proporciona una abstracción a base de objeto con un tipo fuerte contra datos almacenados.

6.- La plataforma de acuerdo con la reivindicación 5, en donde el lenguaje de consulta es al menos uno de ORuta y OSQL (lenguaje de consulta estructurado orientado a objeto).

7.- La plataforma de acuerdo con la reivindicación 1, que además comprende una máquina de coacción/seguridad que facilita creación declarativa de coacciones y controla el acceso a al menos una entidad de la plataforma de datos.

8.- La plataforma de acuerdo con la reivindicación 1, que además comprende una máquina de persistencia que invoca el dominado de relación de objeto que delinea una clase de lenguaje para una representación tabular importante al invocar al menos un delineado de relación de objeto perspectivo y un delineado de relación de objeto no perspectivo.

9.- La plataforma de acuerdo con la reivindicación 8, en donde el delineado es de un espacio de aplicación para el modelo de datos común, e independiente del modelo de datos común para un almacenamiento.

10.- La plataforma de acuerdo con la reivindicación 1, en donde la pluralidad de diferentes estructuras de aplicación incluye al menos uno de una línea de estructura del negocio, una estructura de trabajo de usuario final, una estructura de trabajo de manejo de sistema, una estructura de trabajo de aplicación de usuario, una estructura de trabajo de colaboración, una estructura de trabajo del negocio, y una estructura de trabajo de información personal.

11.- La plataforma de acuerdo con la reivindicación 1, en donde la aplicación es al menos una de una aplicación de usuario final, una aplicación de trabajador de conocimiento, una aplicación de línea de negocio, un aplicación web, una aplicación de manejo de contacto, una aplicación de manejo de documento, una aplicación de colaboración, una aplicación de correo electrónico, una aplicación de manejo de relación de cliente, una aplicación de planeación de recurso de empresa, y una aplicación de manejo de sistema.

12.- La plataforma de acuerdo con la reivindicación 1, en donde el componente de tiempo de funcionamiento proporciona manejo de un estado de entidad que incluye al menos uno de un delineado de identificación, un rastreo de cambio de objeto, y un valor original.

13.- La plataforma de acuerdo con la reivindicación 1, en donde la plataforma de datos y componentes respectivos son agnósticos de unión y pueden existir en ai menos una unión de cliente, una unión media, una unión de servidor, y una unión de servicio web.

14.- La plataforma de acuerdo con la reivindicación 1, en donde el modelo de datos común proporciona datos compartidos dentro del componente de almacenamiento de datos para que las diferentes aplicaciones asociadas con estructuras de trabajo correspondientes puedan acceder a los datos compartidos.

15.- La plataforma de acuerdo con la reivindicación 1, en donde el modelo de datos común proporciona datos privados dentro del componente de almacenamiento de datos para que los datos privados sean accedidos únicamente a través de una aplicación particular asociada con una estructura de trabajo particular.

16.- La plataforma de acuerdo con la reivindicación 1, que además comprende al menos uno de un servicio de regla, un servicio de rastreo de cambio, un servicio de detección de conflicto, un servicio de evento y un servicio de notificación.

17.- Un método implementado por computadora para manejar de datos, que comprende: cubrir una plataforma de datos en un almacenamiento que modela y almacena tipos de datos estructurados, semi-estructurados, y no estructurados para proporcionar un servicio de datos que soporta al menos un modelo de datos rico, un delineado, una consulta, y un mecanismo de acceso de datos para diferentes estructuras de trabajo de aplicación; cubrir una o más estructuras de trabajo de aplicación en la plataforma de datos para permitir al' menos una aplicación dentro de cada estructura de datos para acceder al almacenamiento de datos; comunicarse a la aplicación en la forma de al menos una clase pública, una ¡nterfase, y una función de ayudante estático; proporcionar al menos un delineado de relación de objeto, un delineado de consulta, y una imposición de coacciones; y factorizar un concepto de moldeado que es común para una pluralidad de las diferentes estructuras de trabajo de aplicación.

18.- El método de acuerdo con la reivindicación 17, que además comprende: crear un objeto; abrir una conexión para el almacenamiento con una sesión y establecer un contexto de seguridad; regresar un caso de un contexto de almacenamiento a la aplicación; exponer una interfase para recuperar objetos; delinear una consulta en SQL mientras se aplica la seguridad; regresar un resultado a un tiempo de funcionamiento de plataforma de datos y la aplicación; y guardar los cambios en el objeto de contexto de almacenamiento encapsulado.

19.- El método de acuerdo con la reivindicación 17, que además comprende: proporcionar datos compartidos a diferentes aplicaciones en las diferentes estructuras de trabajo de aplicación; y utilizar datos privados específicos a aplicaciones en diferentes estructuras de trabajo de aplicación particulares.

20.- Un sistema implementado por computadora que facilita el manejo de datos, que comprende: medios para comunicarse a aplicaciones en la forma de al menos una de una clase pública, una interfase, una función de ayudante estático; medios para proporcionar al menos un delineado de relación de objeto, delineado de consulta, e imposición de coacciones; y medios para factorizar un concepto de moldeado que es común para una pluralidad de diferentes estructuras de trabajo de aplicación.